[Aurornis]

Lots of tortured logic in this post.

1. You shouldn't pick a programming language the team doesn't know. That's common sense, not an argument against Rust.

2. Rust ranks lower on the most used languages list because it's newer than Java, Python, C, and all of the others higher on the list.

3. You don't need to use async Rust. If you do, I disagree that it's as hard as this is implying, but I would agree that it's not as easy as writing sync code.

4. Rust projects don't decay like this is saying. Rust has editions and you can stay on an older edition until you're ready to port it forward. My experience with jumping to a new Rust edition has been easy across all projects so far. It's funny that they argue that adding new features to the language leads to unmanageable complexity, because the very next topic argues that the standard library doesn't have enough features.

5. If you want a batteries-included standard library I agree that you should pick Python or Go instead.

Most of the blog is an ad for the author's book. I was hoping this post had some substance but I think they chose the title first to attract clicks for the book ad and then tried really hard to find some content for the article second.

[tialaramex]

> You shouldn't pick a programming language the team doesn't know. That's common sense, not an argument against Rust.

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.

[pointlessone]

> 3. You don't need to use async Rust.

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.

[bryanlarsen]

And all the popular ones include a synchronous interface you can use instead of the async one. If if they don't, you can wrap your calls in spawn_blocking.

You might complain about it pulling in tokio, but that's a very different complaint than having to learn/use async.

[simon_void]

Is the inclusion of synchronous interfaces a new thing? When I learned actix_web 2-3 years ago for some webservices at work, the documentation surely (at least) started of with async functions everywhere. Did that change? Were synchronous interfaces introduced later in the actix_web documentation? Or did everybody switch over to axum in the meantime and axum has synchrounous interfaces!? (I just checked and according to crates.io axum seems to have 8x the recent downloads of actix_web.) background: actix_web is still the only Rust webframework I have experience with

[saghm]

You seem to have picked the framework where the selling point is literally providing an async actor model, so yes, it's probably going to be async. If you don't like async, you probably should be spending time getting experience with one of the frameworks that's less opinionated.

[danhau]

Dependencies having to pull in tokio is an even larger issue, indicating that async‘s promise of „bring your own runtime“ is a bit of a lie. Lovely, lovely dependency hell.

[andriy_koval]

> Want to build a web app, every more or less popular framework is async.

I think its the same as Java, Tomcat has some async threadpool inside, they just hide it from you, and your favorite rust framework doesn't, you need manually move your sync logic to Tokio spawn_blocking

[traderj0e]

Java is different. Tomcat's thread pool is the older way. A lot of newer stuff was using something promises-related instead with an event loop. But then recently Java added virtual threads which should obviate the need for that, similar to Go. Rust considered virtual threads but chose against that because it requires a more abstracted runtime like Java and Go have. Great preso on this https://www.youtube.com/watch?v=lJ3NC-R3gSI

All the "async" stuff is super poorly named. They mean cooperative multitasking, or I guess "async within a single kernel thread." Yeah multiple kernel threads are asynchronous but "async" doesn't mean that :S

[nextaccountic]

There's an API to call async code in a sync context, it's called block_on. You can just spawn threads and do your block_on on every async API you encounter and go on about your life. Pair it with a good mpsc library for inter thread channels (or just use the stdlib mpsc - even though it's slower and strictly worse than libs, it doesn't matter) and you are good to go

Likewise there's an API to call sync code in async context, it's spawn_blocking (or sometimes block_in_place but, stick with spawn_blocking)

[traderj0e]

For the use cases the author is alluding to, you do need to use async. Non-cooperative threaded multitasking isn't a real choice for backends, and Rust doesn't have virtual threads.

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.

[tracker1]

For that matter, even if you do use async, if you're writing a service based app (such as web services), IMO, you'd probably just want to center on tokio and axum, then stick to the tokio ecosystem. The main reason it's not a blessed standard library thing, is that Rust can scale down into embedded systems usage, and you aren't going to use something like Tokio there... that doesn't mean you shouldn't just use what everyone else does at a higher level application.

Also, in regards to OP's reference to changes to Rust, it's not changes/additions or bug fixes that should be a concern, it's the number of breaking changes. For a contemporary counter example, look at how much C# has changed since the .Net Core fork started out... They're on version 11 now (skipped v4), and that doesn't count the library sub-version shifts along the way. And a lot of critical banking infrastructure is written in and running on it (as well as Java). Your money is literally relying on it.

[SkiFire13]

> And a lot of critical banking infrastructure is written in and running on it

How much of that critical infrastructure runs on .NET Framework as opposed to the latest .NET Core though?

[moomin]

IME: less than you’d think. I know one major C# project that’s only half completed its migration and that huge (both in terms of what’s been achieved and what still needs doing). There’s another that keeps it for the front end because it runs on >10,000 client machines. All the others, big or small, have migrated with small carve-outs for stuff .NET Core doesn’t and probably never will support.

[tracker1]

From recent experience I'd put it slightly higher on the old framework, but plenty of new dev on v5+ and I think sticking on framework is worse at this point.

Though I would say that breaking changes since Core 3 have been pretty limited. V5 unified .net under the new core as the path forward for framework users as well.

[andriy_koval]

> 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

I think majority Java code is just sequential blocking code, and it works just fine.

[ViewTrick1002]

Rust had that, but decided it wasn’t a good enough fit. Which was the motivation to keep exploring and land on the current async implementation which scales from embedded to servers with minimal overhead.

History:

This RFC proposes to remove the runtime system that is currently part of the standard library, which currently allows the standard library to support both native and green threading.

https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...

[sysguest]

well rust async is 'still evolving' right now

it's better than being stuck, but it's not '100% polished' right now (though some crates do make the experience somewhat more polished: especially dtolnay's crates)

[ViewTrick1002]

Agree. There's stuff missing, and there are problems which likely are "multiple Phd theses" level to solve cohesively. Either in Rust or a successor language when the problem space has been explored.

For me the most annoying part are the footguns async Rust introduces, which Rust generally is blessedly empty of compared to e.g. Go or other languages.

Like for example, cancellation safety, dealing with "long running" futures, cleanly terminating a program, deadlocks at a distance [1] and others I'm forgetting now.

[1]: https://rfd.shared.oxide.computer/rfd/0609

[fulafel]

This take on native threads sounds overly pessimistic. 99% of backends do fine with the nr of native threads you can easily run in a single process at least on Linux. Not sure what the practical limit is now but 10k used to be no problem many years ago.

(eg 100k threads in 2002: https://lkml.iu.edu/hypermail/linux/kernel/0209.2/1153.html .. where the 32-bit 4 GB limit seemed to be the main obstacle)

[traderj0e]

I believe it's fine when you're tuning it. Nowadays people are more likely to have multiple services waiting on each other to handle a user request, each running in containers on random hardware. Even if it's "monolithic," it's probably not really cause they're waiting on external APIs. They don't want to think about tuning for thread pools too.

[fulafel]

I can believe some people have implemented misconfigured thread pools, being worse off than with no thread pool at all. But this not an argument that justifies a "multitasking isn't a real choice for backends" position.

(Then there's bugs that happen in both asyncio and threaded programs, that stem from various queuing problems in the system, manifesting as work getting backed up in the concurrency layer. You end up needing backpressure in both worlds, thread pool limits are the wrong layer to do it.)

[jen20]

> why Rust and Python put so much effort into adding event loops after the fact.

Perhaps Python, but Rust went the other way - it had all that stuff built and it was removed.

[traderj0e]

Er yeah technically the event loop isn't part of Rust, just the async/await syntax. But it's implied that you're going to use some event loop with it.

[tracker1]

No, it's implied that you're going to use some sort of async runtime with it... said runtime can be simple real threads, a thread pool or virtual threads and there are implementations for all of them. And even then, it's super easy to start a new real thread in rust, around any async runtime.

[jen20]

While true, this isn’t what I’m talking about: Rust had _built in_ green threads at one point, the same as Go [1].

[1]: https://rust-lang.github.io/rfcs/0230-remove-runtime.html

[jen20]

True now, but there was a time when async/await was _not_ part of Rust, and a runtime was.

[nextaccountic]

> 5. If you want a batteries-included standard library I agree that you should pick Python or Go instead.

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

[lenkite]

> 3. You don't need to use async Rust.

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

[worik]

I do a lot of real-time audio programming in Rust because it is so expressive and the compiler so helpful

But I disagree. I do not use asyc/await for my asynchronous programming in Rust if I get the choice. I have used it extensively in other languages, and when I've had to in Rust, but there are many problems

The paradigm itself is not suited to hard real-time programming. An explicit event loop is unbeatable in that case

The model does not fit properly in the Rust memory model, and quite often you find yourself using pretzel logic and "magic incantations" to get around that

It is synchronous in style, and a footgun as CPU bound operations can block it.

The threading support in Rust is superb and for the vast majority of cases a perfect fit

Async/await in Rust is a very impressive technical achievement, I am very impressed by how much gets done so efficiently and how well the runtime perform