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 4 hours ago | parent | next [-]

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.

▲

andriy_koval 3 hours ago | parent | prev | next [-]

> 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 4 hours ago | parent | prev | next [-]

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 3 hours ago | parent [-]

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 3 hours ago | parent [-]

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

	▲	2 hours ago \| parent [-]
		[deleted]

▲

jen20 5 hours ago | parent | prev [-]

> 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 4 hours ago | parent [-]

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 4 hours ago \| parent [-]
		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.