8 ms·

> I’m happy with how Rust turned out. I agree, with the possible exception of perplexing async stuff.

vablings 10mo ago
I feel async is in a very good place now (apart from async trait :[ ) As a regular user who isn't developing libraries async is super simple to use. Your function is async = it must be .await and must be in an async runtime. Probably as simple and straightforward as possible. There are no super annoying anti-patterns to deal with. The ecosystem being tokio centric is a little strange though
- leshow 10mo ago
  I love Rust and async Rust, but it's not true that there aren't annoying things to deal with. Anyone who's written async Rust enough has run into cancel-safety issues, the lack of async Drop and the interaction of async and traits. It's still very good, but there are some issues that don't feel very rust-y.
  - pornel 10mo ago
    I've been writing async Rust for as long as it existed, and never ran into any cancel-safety issue. However, I also never used tokio's select macro.
  - junon 10mo ago
    I don't really appreciate the superlative here as I too have not run into cancel safety issues in practice.
bryanlarsen 10mo ago
I was really hoping that there'd be movement on a comment without-boats made in https://without.boats/blog/why-async-rust/ https://without.boats/blog/why-async-rust/ to bring a pollster like API into the standard library. Rust has very good reasons for not wanting to bless an executor by bringing it into the standard library. But most of those would be moot if pollster was brought in. It wouldn't stifle experimentation and refinement of other approaches because it's so limited in scope and useless to all but the simplest of use cases. But it does in practice solve what many mislabel as the function coloring problem. Powerful rust libraries tend to be async because that's maximally useful. Many provide an alternate synchronous interface but they all do it differently and it forces selection of an executor even if the library wouldn't otherwise force such a selection. (Although to be clear such libraries do often depend on I/O in a manner that also forces a specific executor selection). Pollster or similar in standard library would allow external crates to be async with essentially no impact on synchronous users.
- nicoburns 10mo ago
  `pollster` in the stdlib would probably make sense. But of course there's nothing stopping anyone from using the `pollster` crate today.
  - bryanlarsen 10mo ago
    Pollster in the standard library provides several major benefits outside of just using it yourself. - it provides an incentive for libraries to be pollster compatible, rather than requiring tokio. And pollster compatible means executor agnostic. - libraries would document their library with pollster usage
- iknowstuff 10mo ago
  Not quite yet. Crates like reqwest and hyper tend to use tokio's io types internally to set up the sockets correctly and send/receive data at the right time. Those might have different APIs than the thread-pausing sync APIs. Sans-IO crates exist but are kind of annoying to schedule correctly on an IO runtime of choice. Maybe lending iterators could help idk
echelon 10mo ago
I write and use mostly async code, and I cannot for the life of me understand the async hate. What do you want Rust to do differently? What language does async right? How did Rust not reach its async goals? Rust even lets you choose the runtime you want. And most big libraries work with several runtimes.
- mkornaukhov 10mo ago
  I do write mostly async code, too. There are several ~~problems~~ subtleties that make usage of Rust async hindered IMHO. - BoxFuture. It's used almost everywhere. It means there are no chances for heap elision optimization. - Verbosity. Look at this BoxFuture definition: `BoxFuture<'a, T> = Pin<Box<dyn Future<Output = T> + Send + 'a>>;`. It's awful. I do understand what's Pin trait, what is Future trait, what's Send, lifetimes and dynamic dispatching. I *have to* know all these not obvious things just to operate with coroutines in my (possibly single threaded!) program =( - No async drop and async trait in stdlib (fixed not so long ago) I am *not* a hater of Rust async system. It's a little simpler and less tunable than in C++, but more complex than in Golang. Just I cannot say Rust's async approach is a good enough trade-off while a plethora of the decisions made in the design of the language are closest to the silver bullet.
- ori_b 10mo ago
  > What do you want Rust to do differently? Lean into being synchronous. Why should I have to manually schedule my context switches as a programmer?
  - simonask 10mo ago
    Because async and sync programming are two fundamentally different registers. There are things you can do in one that you can’t with the other, or which have dramatically different tradeoffs. As an example: Call N functions to see which one finishes first. With async this is trivial and cheap, without it it’s extremely expensive and error-prone.
    - ori_b 10mo ago
treyd 10mo ago
The system Rust has is a lot better than that of Python or JavaScript. Cleanly separating construction from running/polling makes it a lot more predictable and easier to understand what's happening, and to conveniently compose things together using it.
- phplovesong 10mo ago
  Thats putting the bar pretty damn low.

I feel async is in a very good place now (apart from async trait :[ ) As a regular user who isn't developing libraries async is super simple to use. Your function is async = it must be .await and must be in an async runtime. Probably as simple and straightforward as possible. There are no super annoying anti-patterns to deal with. The ecosystem being tokio centric is a little strange though

leshow 10mo ago
I love Rust and async Rust, but it's not true that there aren't annoying things to deal with. Anyone who's written async Rust enough has run into cancel-safety issues, the lack of async Drop and the interaction of async and traits. It's still very good, but there are some issues that don't feel very rust-y.
- pornel 10mo ago
  I've been writing async Rust for as long as it existed, and never ran into any cancel-safety issue. However, I also never used tokio's select macro.
- junon 10mo ago
  I don't really appreciate the superlative here as I too have not run into cancel safety issues in practice.

bryanlarsen 10mo ago

I was really hoping that there'd be movement on a comment without-boats made in https://without.boats/blog/why-async-rust/ https://without.boats/blog/why-async-rust/ to bring a pollster like API into the standard library. Rust has very good reasons for not wanting to bless an executor by bringing it into the standard library. But most of those would be moot if pollster was brought in. It wouldn't stifle experimentation and refinement of other approaches because it's so limited in scope and useless to all but the simplest of use cases. But it does in practice solve what many mislabel as the function coloring problem. Powerful rust libraries tend to be async because that's maximally useful. Many provide an alternate synchronous interface but they all do it differently and it forces selection of an executor even if the library wouldn't otherwise force such a selection. (Although to be clear such libraries do often depend on I/O in a manner that also forces a specific executor selection). Pollster or similar in standard library would allow external crates to be async with essentially no impact on synchronous users.

nicoburns 10mo ago
`pollster` in the stdlib would probably make sense. But of course there's nothing stopping anyone from using the `pollster` crate today.
- bryanlarsen 10mo ago
  Pollster in the standard library provides several major benefits outside of just using it yourself. - it provides an incentive for libraries to be pollster compatible, rather than requiring tokio. And pollster compatible means executor agnostic. - libraries would document their library with pollster usage
iknowstuff 10mo ago
Not quite yet. Crates like reqwest and hyper tend to use tokio's io types internally to set up the sockets correctly and send/receive data at the right time. Those might have different APIs than the thread-pausing sync APIs. Sans-IO crates exist but are kind of annoying to schedule correctly on an IO runtime of choice. Maybe lending iterators could help idk

echelon 10mo ago

I write and use mostly async code, and I cannot for the life of me understand the async hate. What do you want Rust to do differently? What language does async right? How did Rust not reach its async goals? Rust even lets you choose the runtime you want. And most big libraries work with several runtimes.

mkornaukhov 10mo ago
I do write mostly async code, too. There are several ~~problems~~ subtleties that make usage of Rust async hindered IMHO. - BoxFuture. It's used almost everywhere. It means there are no chances for heap elision optimization. - Verbosity. Look at this BoxFuture definition: `BoxFuture<'a, T> = Pin<Box<dyn Future<Output = T> + Send + 'a>>;`. It's awful. I do understand what's Pin trait, what is Future trait, what's Send, lifetimes and dynamic dispatching. I *have to* know all these not obvious things just to operate with coroutines in my (possibly single threaded!) program =( - No async drop and async trait in stdlib (fixed not so long ago) I am *not* a hater of Rust async system. It's a little simpler and less tunable than in C++, but more complex than in Golang. Just I cannot say Rust's async approach is a good enough trade-off while a plethora of the decisions made in the design of the language are closest to the silver bullet.
ori_b 10mo ago
> What do you want Rust to do differently? Lean into being synchronous. Why should I have to manually schedule my context switches as a programmer?
- simonask 10mo ago
  Because async and sync programming are two fundamentally different registers. There are things you can do in one that you can’t with the other, or which have dramatically different tradeoffs. As an example: Call N functions to see which one finishes first. With async this is trivial and cheap, without it it’s extremely expensive and error-prone.
  - ori_b 10mo ago

treyd 10mo ago

The system Rust has is a lot better than that of Python or JavaScript. Cleanly separating construction from running/polling makes it a lot more predictable and easier to understand what's happening, and to conveniently compose things together using it.

phplovesong 10mo ago
Thats putting the bar pretty damn low.