14 ms·

I don't see how rust will manage to fix async await, unless making a v2 of the language. While working with sync rust is often a very pleasant experience, every

I don't see how rust will manage to fix async await, unless making a v2 of the language. While working with sync rust is often a very pleasant experience, everytime I used async await was awful. To the point that I avoid using rust for web /networking stuff, any other option is better. It's also very discouraging to read some people telling there's no issue with async await. Of course if you use a thousands of libraries (that are more or less hacks), and never use trait and generics, it's probably a decent experience half of the time I'd say. It's something I've only encountered with rust community, in Java when a feature sucks, we just say it sucks. Even the architect that approved it will say it sucks.

mleonhard 4y ago
You can use Servlin to make an HTTP server with sync Rust. I made it. https://crates.io/crates/servlin https://crates.io/crates/servlin
nynx 4y ago
Could you be more specific about what’s bad about it?
- dnsco 4y ago
  Yesterday it took me and my pair like 3 hours to figure out how to iterate over a vector of things asynchronously. Eventually we found collect'ing into a FuturesUnordered, after already implementing a repeated collect into vector of futures and then futures::join_all them. The error messages we encountered while going through this were not the amazing one's we're used to from sync rust, these were... cryptic, to say the least.
  - estebank 4y ago
    > The error messages we encountered while going through this were not the amazing one's we're used to from sync rust, these were... cryptic, to say the least. Please file tickets when you encounter these. A lot of the "great errors in rustc" are by their nature reactive: we need to see what people try when they hit corners that haven't gotten as much love. async/await uses multiple somewhat advanced features under the covers that have a tendency to provide either verbose or confusing errors. We're slowly improving them, but having good examples of real world cases is incredibly useful to speed up that process. This is what allows us to have extra information with recommendations.
- nbittich 4y ago
  It's been 7 months since I didn't write async code so it will be difficult for me to give u a proper answer but I'll try. the learning curve, the cryptic lifetime compiler errors, the lack of async trait, no async Fn but async block instead, differents libraries using different runtimes, spending hours to compile a trivial code, the box pin Dyn boxfuture thingy, the compile time, issues with analyzer etc. But most important the fact that you couldn't write code just as you would in sync rust. Most of the features of sync rust don't compose well with async rust. At every step, async rust feels like it's a proof of concept, an half baked feature that should never had reached stable in that state. Rushing it was a mistake to me. You shouldn't need a PhD in async await to use it properly. It should feel like writing normal rust code. Unfortunately, it's not.
  - oxff 4y ago
    Different libraries using different runtimes is quite unfair criticism, the actual criticism could be "no abstraction over the runtimes". > Most of the features of sync rust don't compose well with async rust True, but what do you suggest? Adding an effect system? Removing async?
  - ArrayBoundCheck 4y ago
    So you wouldn't say you feel fearless about concurrent code?
    - deleted 4y ago
      [deleted]
  - afdbcreid 4y ago
    Async Rust is still considered MVP, perhaps surprisingly. > Most of the features of sync rust don't compose well with async rust. There are two parts to that. Missing features that are required to compose the features (GATs are a good example), and bugs/incoherencies/just inconveniences. The latter will eventually get fixed hopefully, although some of them are really hard the recent work on a-mir-formality is going to help this. The former are probably going to be solved too, but it'll be harder and perhaps require more time. As far as I can tell, nothing is impossible by the design of the async/await MVP (it was designed for that, so this is not really surprising). FWIW, both happen in non-async code too. It's just that async code takes the type system to its extreme, and so it has more surprises.
blacksmithgu 4y ago
The core problem I see is Rust tried too hard to avoid allocations/copies and a heavy async runtime. The result is confusing and difficult types and very unclear errors due to apis producing ridiculous types like Future<Arc<Box<dyn Thing>>>. The language should have defined a consistent async model (like coroutines with message passing) and kept "raw async" confined to high performance special libraries and embedded use cases.
- pkolaczk 4y ago
  That's not Rust's fault but library creators / programmers fault who often paint themselves into corner by refusing to use a heap allocation or clone here and there. Once you are ok with occasional boxing, you can easily do a lot of stuff that's otherwise hard - e.g. async traits or storing/passing/moving futures like any other value. It is quite unfair to complain on convenience of Rust async used with no heap allocations to other languages which don't offer an option to avoid boxing at all. In e.g. Java when you return a Future it is always on the heap. In Golang, you don't even have a Future concept. So you basically can't do the same thing in other languages at all.
  - oxff 4y ago
    One thing which I am afraid of, is that people who make Rust applications or libraries aren't really responsible with its advanced features (which are great!). Like I am positive we'll be getting GAT misuse / abuse just by sheer accident because people don't understand them (they're a complex language feature), just like we have libraries going async needlessly.
    - afdbcreid 4y ago
      Funnily enough, this is discussed in length in the GAT stabilization thread.
- oxff 4y ago
  There's only the ``type Future`` mess because GATs aren't exposed (they're currently compiler internal) so that's easy to fix. They could stabilize it already, but they're listening to community feedback in the respective issue (which is a fantastic read btw)
pkolaczk 4y ago
> To the point that I avoid using rust for web /networking stuff, any other option is better How can you write networking concurrent code in Golang then? It doesn't support async traits either. Well, it doesn't support async at all, only green threads ;) And somehow people are ok with it, and say it is simple. Hint: you can use the same style of concurrency in Rust. Don't use futures. Spawn frequently and communicate with channels.
- rastignack 4y ago
  All the ecosystem is using Tokio and async for web stuff. I agree for those cases go is much saner.
  - pkolaczk 4y ago
    My point was that you can program in Rust in the exactly same style as Go, not hitting any of the problems mentioned in the linked article. Just use tokio::spawn and tokio channels and you get all the stuff you have in go. And btw, I just did that recently - I ported a proxy written in Go to Rust and actually it turned out to be simpler than the original thanks to things like join!, select!, RAII, being able to return a value from an async call easily.
    - paskozdilar 4y ago
      If you have any pieces of code you can share, I'd be interested in seeing what Go code looks like in equivalent Rust with tokio.
- paskozdilar 4y ago
  Async/await is syntactic burden. In golang, everything is async so there is no need to differentiate between async/sync methods. Goroutines = coroutines with implicit await on every function call > And somehow people are ok with it, and say it is simple. Threads and queues are (IMHO) fairly easy to understand and work with. If you know how you'd write an application with threads and queues, goroutines and channels work pretty much the same way.
oxff 4y ago
What's so wrong with Rust's async / await?
- rapsey 4y ago
  It is much more complex to use compared to GC languages.
davidkunz 4y ago
I can confirm this behaviour. I once made a video about the downside of Rust[1] where I also talk about the problems you encounter when using `async`. Even though it's clear that there are fundamental problems (e.g. missing support for async traits), people usually comment that I "should've used a higher-level library" to overcome this problem. [1]: https://www.youtube.com/watch?v=pmt0aaquh4o https://www.youtube.com/watch?v=pmt0aaquh4o
baby 4y ago
> in Java when a feature sucks, we just say it sucks. Even the architect that approved it will say it sucks. I mean, in my opinion the whole language Java sucks. Why anyone keep using it is beyond me.
- kaba0 4y ago
  Just to put your opinion in perspective: Java is unique in being huge in both academia and the industry, which bred very novel tooling around the language much more than in any other’s case (JML, many many static analyzers, etc). Java is also unique in being far the best in the tuple of performance, observability and maintainability. Its ecosystem is one of the top 3 in size, and in many niches there is simply no alternative library for other platforms. The language itself underwent huge changes while it remained basically fully backwards compatible. The same is true of the bytecode format. All these make the language and platform the backbone of basically all Fortune 500 companies.
  - baby 4y ago
    True, but I will always refuse to work with it, there's no amount of money you can pay me in to work with Java. I get that it became the labour programming language, but I would expect people on HN to be in it for the love of computer science. I really don't think there's pleasure in writing Java.
- jjav 4y ago
  > I mean, in my opinion the whole language Java sucks. Why anyone keep using it is beyond me. That's a hip opinion to hold, I know, but difficult to back up with facts. If you don't need|want C|Rust and want to write code that is extremely high performance in a language that has excellent tooling (debuggers, profilers, code analysis, etc) and top-shelf libraries and is broadly known and understood (so you can actually hire people), what are your options? Basically just one: Java.
surrTurr 4y ago
I recently built a little Rust project, which I wanted to integrate into a Web App using Web-assembly (wasm-binden). Writing the Rust code was super fun, however, when I execute one of my functions (which takes around 10 seconds to complete), the whole Web App freezes. Well, this should be an easy fix, just make the Rust function async - right? Nope. Making the Rust function async to return a Promise: Web App freezes. Wrapping the call of the Rust code in Promises: Web App freezes. Using Web Workers to run any Rust code in a separate thread: Great, now you can’t share ANY state whatsoever with the UI thread (and no, you can’t pass any Rust objects to another Web Worker thread, because any wasm objects only consist of _binding_ which need an initialised WASM instance in their own thread. To fix this problem, people on GitHub redirected me to a parallel retracer example, which requires nightly Rust and some other tacky tricks to get running. Maybe I will figure out how to integrate this into my project, maybe I won’t. All I wanted to do, is to run one simple async function using WASM. But as it turned out I will have to implement a frikin raytracer first.
- j-pb 4y ago
  I think your issue has nothing to do with rust, and is all about WASM being executed on the main event loop thread. Rust can't magically create parallelism (this is not even an concurrency thing which is what async provides) where there is none.
  - est31 4y ago
    Yeah you'd have the same issue if you ran the expensive computation in Javascript. What you need is worker threads, and yes, you can't share objects with worker threads easily.
mountainriver 4y ago
> in Java when a feature sucks, we just say it sucks. Even the architect that approved it will say it sucks. Yup isn’t that the truth. I like Rust but this aspect is very off putting, the author is one of the worst offenders. It reminds me a lot of the Scala community where the detractor was always just not smart enough to understand their perfect abstraction.
- dymk 4y ago
  > the author is one of the worst offenders. Please explain? The author labors the point that all of this is way past what anyone should be expected to do to diagnose a compiler performance bug.
  - deleted 4y ago
    [deleted]
estebank 4y ago
You might want to look at the work the Async Foundations Working Group[1] is doing, there are indeed lots of things in flight to make the "shiny future" experience[2] better than it is today. When async/await landed in 2018, it was an MVP. Some things have improved since, but it is incomplete. I believe the pushback you see is not "denial that it sucks", but rather an attempt to add nuance to critiques. Claiming that it is unusable or useless, like some do, is hyperbolic. There are plenty of things to fix, and people are working on some of them[3]. I also believe that landing the feature in 2018 was the right call. The parts that are pain points are features that are missing, but nothing in the currently stabilized version of the feature preclude filling those gaps. If it hadn't stabilized, what you would see is 1) many more people on nightly (which isn't ideal) and 2) a less battle tested language feature and crate ecosystem around this. The developer experience of using async/await isn't as good as sync Rust, but it'll get better. I can point at a ton of merged PRs over the past four years as historical evidence to back that claim. And any improvement done for the underlying features that async/await uses, the result is much better experience in sync Rust too! I remember back in 2017 I spent a ton of time on improving trait bound diagnostics because until then I saw them as an "advanced feature" which didn't need immediate focus, but async/await put them front and center. The resulting work improved things for everyone, and is still ongoing to this day. [1]: https://rust-lang.github.io/wg-async/welcome.html https://rust-lang.github.io/wg-async/welcome.html [2]: https://rust-lang.github.io/wg-async/vision/shiny_future/users_manual.html https://rust-lang.github.io/wg-async/vision/shiny_future/use... [3]: https://rust-lang.github.io/wg-async/vision/roadmap.html https://rust-lang.github.io/wg-async/vision/roadmap.html

mleonhard 4y ago

You can use Servlin to make an HTTP server with sync Rust. I made it. https://crates.io/crates/servlin https://crates.io/crates/servlin

nynx 4y ago

Could you be more specific about what’s bad about it?

dnsco 4y ago
Yesterday it took me and my pair like 3 hours to figure out how to iterate over a vector of things asynchronously. Eventually we found collect'ing into a FuturesUnordered, after already implementing a repeated collect into vector of futures and then futures::join_all them. The error messages we encountered while going through this were not the amazing one's we're used to from sync rust, these were... cryptic, to say the least.
- estebank 4y ago
  > The error messages we encountered while going through this were not the amazing one's we're used to from sync rust, these were... cryptic, to say the least. Please file tickets when you encounter these. A lot of the "great errors in rustc" are by their nature reactive: we need to see what people try when they hit corners that haven't gotten as much love. async/await uses multiple somewhat advanced features under the covers that have a tendency to provide either verbose or confusing errors. We're slowly improving them, but having good examples of real world cases is incredibly useful to speed up that process. This is what allows us to have extra information with recommendations.
nbittich 4y ago
It's been 7 months since I didn't write async code so it will be difficult for me to give u a proper answer but I'll try. the learning curve, the cryptic lifetime compiler errors, the lack of async trait, no async Fn but async block instead, differents libraries using different runtimes, spending hours to compile a trivial code, the box pin Dyn boxfuture thingy, the compile time, issues with analyzer etc. But most important the fact that you couldn't write code just as you would in sync rust. Most of the features of sync rust don't compose well with async rust. At every step, async rust feels like it's a proof of concept, an half baked feature that should never had reached stable in that state. Rushing it was a mistake to me. You shouldn't need a PhD in async await to use it properly. It should feel like writing normal rust code. Unfortunately, it's not.
- oxff 4y ago
  Different libraries using different runtimes is quite unfair criticism, the actual criticism could be "no abstraction over the runtimes". > Most of the features of sync rust don't compose well with async rust True, but what do you suggest? Adding an effect system? Removing async?
- ArrayBoundCheck 4y ago
  So you wouldn't say you feel fearless about concurrent code?
  - deleted 4y ago
    [deleted]
- afdbcreid 4y ago
  Async Rust is still considered MVP, perhaps surprisingly. > Most of the features of sync rust don't compose well with async rust. There are two parts to that. Missing features that are required to compose the features (GATs are a good example), and bugs/incoherencies/just inconveniences. The latter will eventually get fixed hopefully, although some of them are really hard the recent work on a-mir-formality is going to help this. The former are probably going to be solved too, but it'll be harder and perhaps require more time. As far as I can tell, nothing is impossible by the design of the async/await MVP (it was designed for that, so this is not really surprising). FWIW, both happen in non-async code too. It's just that async code takes the type system to its extreme, and so it has more surprises.

blacksmithgu 4y ago

The core problem I see is Rust tried too hard to avoid allocations/copies and a heavy async runtime. The result is confusing and difficult types and very unclear errors due to apis producing ridiculous types like Future<Arc<Box<dyn Thing>>>. The language should have defined a consistent async model (like coroutines with message passing) and kept "raw async" confined to high performance special libraries and embedded use cases.

pkolaczk 4y ago
That's not Rust's fault but library creators / programmers fault who often paint themselves into corner by refusing to use a heap allocation or clone here and there. Once you are ok with occasional boxing, you can easily do a lot of stuff that's otherwise hard - e.g. async traits or storing/passing/moving futures like any other value. It is quite unfair to complain on convenience of Rust async used with no heap allocations to other languages which don't offer an option to avoid boxing at all. In e.g. Java when you return a Future it is always on the heap. In Golang, you don't even have a Future concept. So you basically can't do the same thing in other languages at all.
- oxff 4y ago
  One thing which I am afraid of, is that people who make Rust applications or libraries aren't really responsible with its advanced features (which are great!). Like I am positive we'll be getting GAT misuse / abuse just by sheer accident because people don't understand them (they're a complex language feature), just like we have libraries going async needlessly.
  - afdbcreid 4y ago
    Funnily enough, this is discussed in length in the GAT stabilization thread.
oxff 4y ago
There's only the ``type Future`` mess because GATs aren't exposed (they're currently compiler internal) so that's easy to fix. They could stabilize it already, but they're listening to community feedback in the respective issue (which is a fantastic read btw)

pkolaczk 4y ago

> To the point that I avoid using rust for web /networking stuff, any other option is better How can you write networking concurrent code in Golang then? It doesn't support async traits either. Well, it doesn't support async at all, only green threads ;) And somehow people are ok with it, and say it is simple. Hint: you can use the same style of concurrency in Rust. Don't use futures. Spawn frequently and communicate with channels.

rastignack 4y ago
All the ecosystem is using Tokio and async for web stuff. I agree for those cases go is much saner.
- pkolaczk 4y ago
  My point was that you can program in Rust in the exactly same style as Go, not hitting any of the problems mentioned in the linked article. Just use tokio::spawn and tokio channels and you get all the stuff you have in go. And btw, I just did that recently - I ported a proxy written in Go to Rust and actually it turned out to be simpler than the original thanks to things like join!, select!, RAII, being able to return a value from an async call easily.
  - paskozdilar 4y ago
    If you have any pieces of code you can share, I'd be interested in seeing what Go code looks like in equivalent Rust with tokio.
paskozdilar 4y ago
Async/await is syntactic burden. In golang, everything is async so there is no need to differentiate between async/sync methods. Goroutines = coroutines with implicit await on every function call > And somehow people are ok with it, and say it is simple. Threads and queues are (IMHO) fairly easy to understand and work with. If you know how you'd write an application with threads and queues, goroutines and channels work pretty much the same way.

oxff 4y ago

What's so wrong with Rust's async / await?

rapsey 4y ago
It is much more complex to use compared to GC languages.

davidkunz 4y ago

I can confirm this behaviour. I once made a video about the downside of Rust[1] where I also talk about the problems you encounter when using `async`. Even though it's clear that there are fundamental problems (e.g. missing support for async traits), people usually comment that I "should've used a higher-level library" to overcome this problem. [1]: https://www.youtube.com/watch?v=pmt0aaquh4o https://www.youtube.com/watch?v=pmt0aaquh4o

baby 4y ago

> in Java when a feature sucks, we just say it sucks. Even the architect that approved it will say it sucks. I mean, in my opinion the whole language Java sucks. Why anyone keep using it is beyond me.

kaba0 4y ago
Just to put your opinion in perspective: Java is unique in being huge in both academia and the industry, which bred very novel tooling around the language much more than in any other’s case (JML, many many static analyzers, etc). Java is also unique in being far the best in the tuple of performance, observability and maintainability. Its ecosystem is one of the top 3 in size, and in many niches there is simply no alternative library for other platforms. The language itself underwent huge changes while it remained basically fully backwards compatible. The same is true of the bytecode format. All these make the language and platform the backbone of basically all Fortune 500 companies.
- baby 4y ago
  True, but I will always refuse to work with it, there's no amount of money you can pay me in to work with Java. I get that it became the labour programming language, but I would expect people on HN to be in it for the love of computer science. I really don't think there's pleasure in writing Java.
jjav 4y ago
> I mean, in my opinion the whole language Java sucks. Why anyone keep using it is beyond me. That's a hip opinion to hold, I know, but difficult to back up with facts. If you don't need|want C|Rust and want to write code that is extremely high performance in a language that has excellent tooling (debuggers, profilers, code analysis, etc) and top-shelf libraries and is broadly known and understood (so you can actually hire people), what are your options? Basically just one: Java.

surrTurr 4y ago

I recently built a little Rust project, which I wanted to integrate into a Web App using Web-assembly (wasm-binden). Writing the Rust code was super fun, however, when I execute one of my functions (which takes around 10 seconds to complete), the whole Web App freezes. Well, this should be an easy fix, just make the Rust function async - right? Nope. Making the Rust function async to return a Promise: Web App freezes. Wrapping the call of the Rust code in Promises: Web App freezes. Using Web Workers to run any Rust code in a separate thread: Great, now you can’t share ANY state whatsoever with the UI thread (and no, you can’t pass any Rust objects to another Web Worker thread, because any wasm objects only consist of _binding_ which need an initialised WASM instance in their own thread. To fix this problem, people on GitHub redirected me to a parallel retracer example, which requires nightly Rust and some other tacky tricks to get running. Maybe I will figure out how to integrate this into my project, maybe I won’t. All I wanted to do, is to run one simple async function using WASM. But as it turned out I will have to implement a frikin raytracer first.

j-pb 4y ago
I think your issue has nothing to do with rust, and is all about WASM being executed on the main event loop thread. Rust can't magically create parallelism (this is not even an concurrency thing which is what async provides) where there is none.
- est31 4y ago
  Yeah you'd have the same issue if you ran the expensive computation in Javascript. What you need is worker threads, and yes, you can't share objects with worker threads easily.

mountainriver 4y ago

> in Java when a feature sucks, we just say it sucks. Even the architect that approved it will say it sucks. Yup isn’t that the truth. I like Rust but this aspect is very off putting, the author is one of the worst offenders. It reminds me a lot of the Scala community where the detractor was always just not smart enough to understand their perfect abstraction.

dymk 4y ago
> the author is one of the worst offenders. Please explain? The author labors the point that all of this is way past what anyone should be expected to do to diagnose a compiler performance bug.
- deleted 4y ago
  [deleted]

estebank 4y ago

You might want to look at the work the Async Foundations Working Group[1] is doing, there are indeed lots of things in flight to make the "shiny future" experience[2] better than it is today. When async/await landed in 2018, it was an MVP. Some things have improved since, but it is incomplete. I believe the pushback you see is not "denial that it sucks", but rather an attempt to add nuance to critiques. Claiming that it is unusable or useless, like some do, is hyperbolic. There are plenty of things to fix, and people are working on some of them[3]. I also believe that landing the feature in 2018 was the right call. The parts that are pain points are features that are missing, but nothing in the currently stabilized version of the feature preclude filling those gaps. If it hadn't stabilized, what you would see is 1) many more people on nightly (which isn't ideal) and 2) a less battle tested language feature and crate ecosystem around this. The developer experience of using async/await isn't as good as sync Rust, but it'll get better. I can point at a ton of merged PRs over the past four years as historical evidence to back that claim. And any improvement done for the underlying features that async/await uses, the result is much better experience in sync Rust too! I remember back in 2017 I spent a ton of time on improving trait bound diagnostics because until then I saw them as an "advanced feature" which didn't need immediate focus, but async/await put them front and center. The resulting work improved things for everyone, and is still ongoing to this day. [1]: https://rust-lang.github.io/wg-async/welcome.html https://rust-lang.github.io/wg-async/welcome.html [2]: https://rust-lang.github.io/wg-async/vision/shiny_future/users_manual.html https://rust-lang.github.io/wg-async/vision/shiny_future/use... [3]: https://rust-lang.github.io/wg-async/vision/roadmap.html https://rust-lang.github.io/wg-async/vision/roadmap.html