4 ms·

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 ent

by skohan 5y ago

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.

tiddles 5y ago
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-2022.html https://blog.rust-lang.org/inside-rust/2022/02/03/async-in-2...
pshc 5y ago
>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 https://news.ycombinator.com/item?id=26406989 specifically https://news.ycombinator.com/item?id=26407565 https://news.ycombinator.com/item?id=26407565
- ithkuil 5y ago
  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.
  - TheFlyingFish 5y ago
    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.
  - deleted 5y ago
    [deleted]
  - maxthegeek1 5y ago
    Does async rust prevent the use of C FFI? A quick google shows me nothing there.
    - boardwaalk 5y ago
      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.
    - ithkuil 5y ago
      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
      - maxthegeek1 5y ago
        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.html https://docs.rs/tokio/latest/tokio/task/fn.spawn_blocking.ht...
nicoburns 5y ago
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.
Ericson2314 5y ago
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.

by skohan 5y ago

tiddles 5y ago

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-2022.html https://blog.rust-lang.org/inside-rust/2022/02/03/async-in-2...

pshc 5y ago

>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 https://news.ycombinator.com/item?id=26406989 specifically https://news.ycombinator.com/item?id=26407565 https://news.ycombinator.com/item?id=26407565

ithkuil 5y ago
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.
- TheFlyingFish 5y ago
  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.
- deleted 5y ago
  [deleted]
- maxthegeek1 5y ago
  Does async rust prevent the use of C FFI? A quick google shows me nothing there.
  - boardwaalk 5y ago
    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.
  - ithkuil 5y ago
    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
    - maxthegeek1 5y ago
      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.html https://docs.rs/tokio/latest/tokio/task/fn.spawn_blocking.ht...

nicoburns 5y ago

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.

Ericson2314 5y ago

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.