I’ve heard it as a word, “Rustles”. Not sure how canonical that is though.

I mean, the simple proof is that Rust has been growing by leaps and bounds in the embedded world, which is the closest to bare metal you get. It’s also being used in the Linux kernel and Windows, and there are several projects building new kernels in pure Rust. So yeah, it’s safe to say that it’s as close to the metal as C.

Also, the comparison to Java is understandable if you’ve only been exposed to Rust by the memes, but it doesn’t hold up in practice. Rust has a lot more syntax than C (although that’s not saying much), but it’s one of the most expressive languages on the market today.

My preferred variation of this is to make it an open question that leaves them in the position of authority, and assumes that they made a deliberate decision.

For example, instead of “Why aren’t you using StandardLib that does 90% of this?”, I would try “Could this be achieved with StandardLib? Seems like it would cover 90% of this”.

For anyone interested in learning more about bloom filters, this is a technical but extremely accessible and easy to follow introduction to them, including some excellent interactive visualizations: https://samwho.dev/bloom-filters/

More specifically, he argued (and the recent and upcoming releases of most major frameworks agree) that rendering most content on the server with islands of client-side interactivity is the future.

That’s not necessarily a huge revelation, but the big difference from what people have been doing with PHP for decades is the level of integration and simplicity in mixing server-side and client-side code seamlessly so that a dev can choose the appropriate thing in each context and not have to go through a lot of effort when requirements change or scaling becomes an issue. I would say that this represents a new level of maturity in the “modern” web frameworks where devs can choose the right technology for every problem to serve their users best.

I think you would be pleasantly surprised by the direction web dev is moving if you gave it a chance.

For example, I suspect that you think one of the ways the web has gotten shittier is because sites are too bloated and JavaScript frameworks are too heavy and slow.

One of the key takeaways is that, across almost all frameworks and stacks, web dev is moving back to doing as much work on the server-side as possible, while retaining the minimum necessary interactivity via Islands of Interactivity with much lighter JavaScript than what was pushed for the last decade.

I mean yes, but also the idea is that the user of serverless doesn’t have to configure, provision, maintain, etc. any server. You as the user just provide the code, and their platform handles running it on a server when needed.

If I had to guess the motivation, it would probably be that:

• Rust is a systems language known for performance and correctness, which makes it a good candidate for their stated goal of having a competitor to encourage performance and correctness within Prettier
• Rust is popular and relatively well-known among open source developers, more so than any comparable language except maybe Go
• Rust is a hip language that probably added some free publicity to their announcement

It’s not just a proposal, it’s already fully defined and almost completely implemented - I believe they’re just waiting on a standards update from ISO for time zone stuff.

This is an interesting artifact because most of these pain points have been effectively solved. Not that there aren’t any difficulties left in cutting edge web dev. For example, we’re still wrangling the frontiers of mixed rendering modes. But between Vite and now Bun, the average dev never has to worry about bundling or module syntax compatibility. Things Just Work. Thanks for the reminder of how quickly the web is continuing to advance GUIs and DX.

I already knew most of this, but only after painfully crawling MS docs for many hours until my eyes were crossed and the word configuration lost all meaning. This is such an excellent summary with extremely useful and operable details. It’s very clearly written and it has a perfect mix of enlightening diagrams.

I’m definitely making this mandatory reading for new team members from now on.