arendjr

Oh, I agree, they both have their use cases. But that doesn’t mean there’s not plenty of situations where the performance is effectively irrelevant, but where people tend to default to using a hash map because they heard it’s faster (probably because lookups are O(1) indeed). So that’s where I would say, as long as performance doesn’t matter it’s better to default to B-Tree maps than to hash maps, because the chance of avoiding bugs is more valuable than immeasurable performance benefits (not to mention that for smaller data sets B-Tree maps can often outperform hash maps due to better cache locality, but again that’s hardly relevant since the data set is small anyway).

Hehe, yeah, I actually agree in principle, although in the context of web tooling I think it’s at least understandable. For many years, web tooling was almost exclusively written in JavaScript itself, which was hailed as a feature, since it allowed JS developers to easily jump in and help improve their own tooling. And it made the stack relatively simple: All you needed was Node.js and you were good to go.

Something like the Google Closure Compiler, written in Java, was for many years better than comparable tooling written in JS, but remained in obscurity, partially because it was cumbersome to setup and people didn’t want to deal with Java.

Then the JS ecosystem ran into a wall. JS projects were becoming bigger and bigger, and the performance overhead of their homegrown tooling started frustrating more and more. That just happened to be the time that Rust came around, and it happened to tick all the boxes:

• It showed that it can solve the performance bottlenecks.
• It has great support for WASM, which many web developers were having an interest in.
• Its syntax is familiar enough for TypeScript developers.
• It has a good story around interior mutability, which is a common frustration among TypeScript developers, especially those familiar with React.

I think these things combined helped the language to quickly win the hearts and minds of many in the web community. So now we’re in a position where just name dropping “Rust” can be a way to quickly resonate with those developers, because they associate it with fast and reliable and portable. In principle you’re right, it should just be an implementation detail. But through circumstance it seems to have also become an expression of mindshare – ie. a marketing tool.

Finding a Webpack replacement that doesn’t use NPM at all is going to be hard, but there are certainly alternatives that don’t require the 1000+ NPM dependencies required to use Webpack.

Some alternatives you can consider are Rsbuild and Farm. Part of the reason they use so much fewer NPM dependencies is because they’re written in Rust, so they’ll have Cargo dependencies instead, but you shouldn’t notice anything of that. Of course if you want to audit everything it’s not that much easier, but at least the Cargo ecosystem seems to have avoided quite some of the mistakes that NPM made. But yes, in the end it still comes down to the extent that you trust your dependencies.

Apart from all the interesting performance characteristics and their use in databases, the reason I tend to recommend B-Tree maps over hash maps for ordinary programming is consistent iteration order. It is simply too easy to run into a situation where you think iteration order doesn’t matter, but then it turns out it does in some subtle unforeseen way.

Of course it’s the way of our trade that unforeseen things cause bugs. But if there’s one kind of bug that is particularly annoying, it’s the hard-to-reproduce ones: those introduced by timing issues or (semi-)randomness. The moment you start iterating over a hash map you risk falling prey to the second one. So I’ll just prefer to default to a B-Tree map or set instead.

No sorry, we follow Prettier’s philosophy there.

Is this the rule you might be looking for? https://biomejs.dev/linter/rules/use-sorted-classes/

I’m one of the core contributors to Biome, btw, so feel free to ask questions!

Yeah, I mix them too, although I apply quite a bit of functional techniques especially at the architectural level as well. OO I use mostly for dealing with I/O and other areas where statefulness cannot be avoided.

If you’re interested, I also wrote an in-depth blog where I touch on these topics: https://arendjr.nl/blog/2024/07/post-architecture-premature-abstraction-is-the-root-of-all-evil/

Just keep in mind that inheritance is nowadays a very contested feature. Even most people still invested in object oriented programming recognise that in hindsight inheritance was mostly a mistake. The industry as a whole is also making a shift to move more towards functional programming, in which object orientation as a whole is taking more of a backseat and inheritance specifically is not even supported anymore. So yeah, take the chance to learn, but be cautious before going into any one direction too deeply.

Between Rsbuild, Farm and Mako, I wonder which one will emerge victorious. It seems Rsbuild is the most well-known at this point, but also the slowest of the three (though it could be argued at this point they're all fast enough). Farm has compatibility with Vite plugins as its ace, while Mako is supposedly the fastest of them all.

Meanwhile, Vite itself is apparently not sitting still either, investing in Rolldown to speed up and improve its own bundling. I encourage their friendly competition. It seems the main winners are the users :) (unless you bet on the wrong horse, in which case you may grumble and hope for a better pick with your next project :p)

and that burden is as far as I’ve seen being forced on those long term contributors.

This is not what is happening. The current long term contributors were asked to clarify semantics about C APIs, so the Rust maintainers could take it from there. At no point were the C maintainers asked to help maintain the Rust bindings.

I think I would put the emphasis slightly differently: I don’t feel the confusion is around the word “spawn”, but it spawns futures rather than tasks. For tasks you might indeed expect them to be picked up in the background (which is what work-stealing does), but futures only execute when polled.