I am mostly a fan of Rust, but it's made some missteps in its evolution imo.

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.

>async was somewhat rushed into [Rust]

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

I don't know if that's FUD or not, but personally async turns rust in a language within a language: core rust is interoperable with everything via C FFI, you can build on top of existing stuff. But if you let async rust lure you with its (well deserved) appeal, you end up in a parallel universe, where everything is pure rust.

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 think async creates a mini-language within _any_ language, i.e. the whole what-color-is-your-function problem. It's turtles all the way down or nothing.

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.

Does async rust prevent the use of C FFI? A quick google shows me nothing there.

It doesn't. You can call non-async Rust and C from async Rust just fine. You just have to be beware of calling blocking things if you're not in a context where blocking is ok (i.e. in a CPU work pool thread).

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.

Sure, you can technically call other rust code from async rust and thus you can also technically call C code via FFI, but if that code blocks you have a problem. There are ways around it but they are hard to use and create the pressure towards just rewriting the whole thing in rust.

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

If you need to call blocking code from an async code just use spawn_blocking.

https://docs.rs/tokio/latest/tokio/task/fn.spawn_blocking.ht...

Yes you can. And this will create threads on demand as needed.

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.

I think you're right that async Rust isn't quite done yet (improvements on this front look to be a major focus for 2022). But I think the fact they were able to get an MVP released that so far looks like it can be built upon without too much technical debt is positive rather than a negative. Rust would be far less useful without the async feature.

async is a good example! I agree it is fine for the time, but of less quality than the rest of the language.

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.

The recent post[^1] about the roadmap for Async Rust shows promise for the coming years.

[^1]: https://blog.rust-lang.org/inside-rust/2022/02/03/async-in-2...

I neither expect Rust to go off the rails, but the Core developer team drama lately and Mozilla stepping away makes it that I will neither be surprised in the even that it does.

The Mozilla/Facebook partnership makes me glad they have distanced themselves from the Rust. Obviously not a lot of good judgement happening at Mozilla.

Kind of, I lost count of how many extensions exist currently, and some of them are incompatible.

Fair. What remains to be seen is whether the political will to delete outmoded extensions exists.

> E.g. I don't expect Rust to go off the rails.

Unless the rails are too rusty :-)