For instance sync rust is mostly nice to work with, but async is another story entirely. I have the impression that it was somewhat rushed into the language due to community demand, but it's not really a fully solved problem.
My understanding is this is a FUD meme that has been passed around. Async isn't finished yet, but was debated for years and considered with incredible care and input from the community.
more context in the comments here: https://news.ycombinator.com/item?id=26406989
specifically https://news.ycombinator.com/item?id=26407565
Surely you want to use the pure rust async aware postgres client and the pure rust grpc implementation, but with async that's not a free choice.
You now have to deal with the fact that these (actually often quite well written) reimplementations often lag quite a bit in functionality.
For example you think you can just use some boring technology like a RDBMS but then you discover that pgbouncer doesn't really work well with sqlx. Similar stories for gRPC and other stuff.
Don't get me wrong, I'm not saying that's because async implementation is bad or it hasn't been well thought out. Other languages make other tradeoffs (e.g. Go detects blocking syscalls and increases the size of the thread pool, which makes it a bit easier to accomodate blocking FFI with the core async model, but that comes with a price).
What I'm saying is that in practice async rust feels like another language, a language built on top of rust, that looks like rust, that can call rust, but effectively creates its own ecosystem. The problem is compounded by the fact that it's still called rust, and often you can write libraries that can do a bit of async or not based on optional features.
It's probably all unavoidable and for the better, but it does add a source of fatigue that must be acknowledged and not dismissed as FUD.
I'm not sure what the GP meant, to be honest. Async "colored" code does have an tendency to "infect" more and more of your codebase, but you can still write and integrate big chunks of non-async code (e.g. a parser or a network protocol) if you're mindful about your design.
I could be wrong though. The reason I like to discuss these things here is the opportunity to be proven wrong by someone who knows more and offers a counter-example
https://docs.rs/tokio/latest/tokio/task/fn.spawn_blocking.ht...
But you need to know when you must call this and when it's ok to not call it.
The type system won't help you with that. But if you forget to call it you can cause starvation and if you call it too often you may create too many threads.
What I see in the ecosystem is that such tricks are perceived as hacks and that it would be just better if one could just write a pure rust reimpl.
Surely there are enough reasons that drive people to reimplements stuff in rust. I think this aspect of async nudges people even further into that though.
In return, of course, you get a style of concurrency that tends to be much easier to reason about and much less prone to subtle bugs than traditional preemptive multitasking.
Whether that tradeoff is worth it is obviously very dependent on the particular situation.
Still, the fact that Rust has MIR I think very much limits the damage premature async can do. If we get something better, it should be quite possible to extra "Rust - today's async" to recreate it.
Conversely, I wouldn't be surprised if many of the misfeatures in Switch are in impossible to extricate.
[^1]: https://blog.rust-lang.org/inside-rust/2022/02/03/async-in-2...