The limits of Rust, or why you should probably not follow Amazon and Cloudflare (opens in new tab)

Actually if your team doesn't know any suitable languages it could make sense to pick Rust because they will cause far fewer accidental fires in Rust.

(Safe) Rust is much more forgiving of "I didn't know that's how computers work" than a language like C or C++ yet it's as close to the metal as they are which may matter for your application.

If you're hiring programmers they probably already know some suitable languages which should strongly influence your choice, but if the team's main expertise is not programming they may take to Rust much easier than you'd expect.

Technically correct, but… Want to build a web app, every more or less popular framework is async. Want to make a web request? High change of async. Database? Very likely async, too. A huge fraction of crates are async. Right now crates.io says there are "54172 reverse dependencies of tokio”. And the page that lists them struggles mightily to load. And that’s only direct dependencies of tokio, no indirect ones, no dependencies on other runtimes, no generic dependents.

Before Java got virtual threads in Project Loom, people were typically using some promises equivalent even though it mangled the heck out of all your code, cause they didn't want to be doing blocking stuff with a thread pool. That was a big motivator for Go and Kotlin coroutines, and why Rust and Python put so much effort into adding event loops after the fact.

But then you should be warned that, among the various http clients Python has in their stdlib, none should be used. Or the many datetime libs in the Python stdlib, they should not be used. LLMs know this by the way and will reach for actual best practices

This is like saying you don't need to use a Smartphone. Technically, correct, but then you need to live like a caveman.

In my experience the "oh god I have to compile a 10 year old program" dread hierarchy (from least to most dread) is:

1. Go. Very reliable.

2. Rust. Also very reliable.

3. C++. Sometimes stuff breaks, e.g. when they change the default C/C++ version and dependencies don't specify it. That happened to me recently.

4. Python. They deprecate stuff all the time that is often actually used (e.g. a load of stuff in pkgutil recently).

5. JavaScript. Good fucking luck.

We have absolutely no need for it at work. We're writing micro services that run in K8s with no extreme performance requirements. Nobody on the team knows the language (I know it better than the people arguing for it, and I don't know more then the basics). And yet, every couple of weeks, I'm having to talk someone out of switching certain services over to it. It's like a damn disease.

I think the sort of person who figures they don't need to read the book because the title told them there was a Murder on the Orient Express believes Brooks says that it's just all irreducible complexity, too bad, stop looking. In fact "No Silver Bullet" says nothing of the sort and we would be astonished if, after so much time, literally none were discovered.

There are plenty of domains where Rust makes sense if you could just choose Rust, but probably doesn't make enough sense that you should retrain or even re-hire a whole team. Google spends money training devs who don't know Rust, because it's getting enough value out that it makes sense to do that, your web slinging business running on razor thin margins is probably fine in PHP or whatever and should not buy Rust training.

AtomicPtr::update which is a nicer way to write one of those "Get the pointer, do some stuff to calculate a new value from the old one, then try to swap its old value for the new one, if the pointer changed meanwhile repeat each time with the changed value until we succeed" stanzas some low-level people will have written a hundred times. This library feature does all that boring boilerplate for you, you just write that "calculate a new value" code as a lambda (or function, Rust doesn't mind) and you're done.

That's the sort of feature where if it didn't exist when you wrote your code, you go "That's nice" and move on, no change needed, but now that it does exist you might use it in future software you write. If you have a team writing Rust it probably makes sense to have somebody read these changelogs, but that's about it.

No, it's not. It works. Perfect? No, absolutely not. There is plenty you could improve, plenty of rough edges you could smooth out. Stuff that caused us problems at the job I had writing low-ish level machine control services. But it's totally workable and we were able to ship working devices, especially compared to doing async stuff in other most other languages, especially the memory-unmanaged ones.

Kind of like Rust itself, a ton of people have tried it and bounced off it because they couldn't get it working in 10 minutes, and in doing so have declared it impossible/for geniuses only/broken/ecosystem-destroying. The narrative around async Rust is probably 70% meme/bad PR, 30% real, actual issues that could be improved.

I hope this comes off as fair. I don't want to excuse any of the shortcomings, but it's a working, useful tool.

This makes it suitable for a much wider variety of tasks than other languages with similar features, but does mean that there are more details that you need to care about than in other languages that are higher level.

This means it is controversial: some people would prefer a higher level experience, but for those who do use it for its full range of tasks, it’s great.

There are some rough edges, but it’s just a feature that, even outside of Rust, some people just fundamentally dislike. So it draws a lot of heat from all sides.

It is also probably the single largest driver of adoption of the language. Rust started truly taking off once it landed.

I don't think it's friendly to Rust beginners but I also think the complaints about if have been overblown

If your reference is JS or C#, then Rust's async has more friction and annoying details. But Rust is generally harder due to being low-level and picky about memory management and thread-safety details. In a way it's a compliment that Rust's usability even gets compared to GC languages.

If you compare it to hand-rolling state machines in C, or even callbacks in pre-async Rust, then it's an amazing simplification and a very sweet syntax sugar. Especially when you want async code composable, supporting control flow and cancellation.

If you compare it to naive sync Rust while ignoring the extra capabilities that async adds, then async is more complicated and less feature-complete (Streams have more moving parts than Iterators, generic async closures have trickier syntax than generic sync closures, there are scoped threads but no scoped multi-threaded futures, etc). IMHO the difference isn't large and it's reasonable for what you get.

There's also a view that async/await syntax is fundamentally misguided and shouldn't exist at all. From Rust's perspective that's an agree-to-disagree. Rust tried having green threads first (before 1.0) and decided it was too intrusive and magic for a low-level systems language. Rust tried to make do with just threads, callbacks and macros, but it didn't work well either (user code can't make futures compose and optimize as well without compiler's help, especially when you want borrow checker to work with it).

The other 5% matters a lot.

> but pretty much all async libraries will work with tokio,

"pretty much" is useful until it's not. When it's not it is a special type of hell

Eventually

The learning curve is unfun