Comment by ithkuil | Hacker News Reader

Comment by ithkuil | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com