[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.