5 ms·

This is consistent with the author's assessment - the incomplete implementation of async makes it very challenging to advocate for, despite the fact that it was

This is consistent with the author's assessment - the incomplete implementation of async makes it very challenging to advocate for, despite the fact that it was the only logical choice given Rust's design goals. I will say that the notion that you must make your whole project async is largely true (except that you can block on futures with all runtimes), but this is more symptomatic of the fact that Rust has hitched its horse to two wagons that don't have clean overlap. It is effectively two languages trying to converge in the middle. It's equally desired at "web server and above" and "operating system and below", which probably makes it one of the hardest languages on the planet to design (lets not forget it deliberately has no runtime, which makes things even more difficult). Whether or not this is a good idea remains to be seen over time, but they are in largely uncharted territory so I'm prepared to give them some slack on it while they figure it out. That said, holy has it taken such a long time to round out the async story to make it feel better. I don't blame users not wanting to wait it out because it has felt like an eternity.

Verdex 3y ago
> It's equally desired at "web server and above" and "operating system and below", which probably makes it one of the hardest languages on the planet to design. My theory as to why C++ has become as a problematic language as it has is because it is able to do it all. And "all" doesn't fit nicely into a single package or paradigm. I don't like async (in any language), so your post immediately piqued my interest. I'm not that interested in 'webserver and above' so of course that would be where people find async useful. It is possible that there is no way to unify these two domains into a single language (at least without becoming c++). Although, then again, it might be that if you think about it long enough then the unification mechanism becomes apparent.
- zozbot234 3y ago
  C++ is problematic in that it's a memory-unsafe language with a lot of cruft dating back to the 1980s. Its generality has made it more not less successful, since that makes it a lot easier to reuse library and support code across domains.
- samus 3y ago
  The problem with C++ is that every feature - attempts to solve too many problems, - has significant papercuts that have to be considered, - has significant runtime cost, - interacts poorly with other features, or at least leaves significant edge cases open, - has non-uniform compiler support (although in OSS land only GCC and LLVM matter), and - creates arcane error messages that are anything but fun to analyze. Especially when templates are involved. Above everything the fundamental problem that the unsafe parts of C are everywhere, and to master C++ you have to become really proficient at diagnosing problems with them because you will run into them. Only then can you start thinking about fun things like software architecture. Always use a linter/static analyzer.
  - kroltan 3y ago
    That list of bullet points (except the compiler one) is also applicable to the whole async ecosystem in Rust :)
    - samus 3y ago
      I for sure hope that Rust gets at least the safety aspect right :) I could endure a lot of suffering if I knew that concern to be taken care of.
    - mplanchard 3y ago
      Agree on papercuts and interaction with other features to some degree. Absolutely disagree on runtime cost. The design of async has as minimal a runtime cost as seems theoretically possible, and avoids a lot of the runtime cost of async in other languages. It's really an impressive engineering feat given the constraints and I think there's a real case for it being a "zero-cost" abstraction (i.e. you couldn't implement a faster version by hand). IME the bad compiler messages tend to come more often from the `async-trait` macro than from anything fundamental to asyc itself. Hoping the stabilization of async-trait helps with that. Backtraces with async are definitely a bit nasty though.
  - Kranar 3y ago
    Don't forget that C++ features are also often rolled out before anyone even really understands them, and then after they are rolled out people find all kinds of footguns and issues with them. The C++ committee basically evaluates features almost entirely in the abstract, writing papers and discussing privately among a small group of people about things instead of working on proof of concept implementations, getting actual real world feedback on it, or having something along the lines of Rust's nightly where experimental features can be tried out.
- munificent 3y ago
  Agreed. The classic claim about C++ is that everyone wants to remove half of its features, but no one can agree on which half.
kllrnohj 3y ago
I think async is still in the more just trendy camp than being a proven asset. After all, thread per connection is perfectly viable for the vast majority of servers. Most people aren't re-writing NGINX, after all (hopefully...). It's a shame Rust let itself be distracted by it instead of focusing on refining its strengths and developer experience
- riku_iki 3y ago
  > Most people aren't re-writing NGINX, after all (hopefully...). those people probably may use another language (java, go, c#) if absolute performance is not critical for them.
  - kllrnohj 3y ago
    That's a false equivalence. I can have a performance limited server that is not limited on concurrent connection count in which case thread-per-connect is both simpler and scales great compared to async. async doesn't optimize performance in general rather it optimizes for number of open concurrent connections specifically. Which primarily only helps if you aren't doing much of anything in terms of compute per connection.

Verdex 3y ago

> It's equally desired at "web server and above" and "operating system and below", which probably makes it one of the hardest languages on the planet to design. My theory as to why C++ has become as a problematic language as it has is because it is able to do it all. And "all" doesn't fit nicely into a single package or paradigm. I don't like async (in any language), so your post immediately piqued my interest. I'm not that interested in 'webserver and above' so of course that would be where people find async useful. It is possible that there is no way to unify these two domains into a single language (at least without becoming c++). Although, then again, it might be that if you think about it long enough then the unification mechanism becomes apparent.

zozbot234 3y ago
C++ is problematic in that it's a memory-unsafe language with a lot of cruft dating back to the 1980s. Its generality has made it more not less successful, since that makes it a lot easier to reuse library and support code across domains.
samus 3y ago
The problem with C++ is that every feature - attempts to solve too many problems, - has significant papercuts that have to be considered, - has significant runtime cost, - interacts poorly with other features, or at least leaves significant edge cases open, - has non-uniform compiler support (although in OSS land only GCC and LLVM matter), and - creates arcane error messages that are anything but fun to analyze. Especially when templates are involved. Above everything the fundamental problem that the unsafe parts of C are everywhere, and to master C++ you have to become really proficient at diagnosing problems with them because you will run into them. Only then can you start thinking about fun things like software architecture. Always use a linter/static analyzer.
- kroltan 3y ago
  That list of bullet points (except the compiler one) is also applicable to the whole async ecosystem in Rust :)
  - samus 3y ago
    I for sure hope that Rust gets at least the safety aspect right :) I could endure a lot of suffering if I knew that concern to be taken care of.
  - mplanchard 3y ago
    Agree on papercuts and interaction with other features to some degree. Absolutely disagree on runtime cost. The design of async has as minimal a runtime cost as seems theoretically possible, and avoids a lot of the runtime cost of async in other languages. It's really an impressive engineering feat given the constraints and I think there's a real case for it being a "zero-cost" abstraction (i.e. you couldn't implement a faster version by hand). IME the bad compiler messages tend to come more often from the `async-trait` macro than from anything fundamental to asyc itself. Hoping the stabilization of async-trait helps with that. Backtraces with async are definitely a bit nasty though.
- Kranar 3y ago
  Don't forget that C++ features are also often rolled out before anyone even really understands them, and then after they are rolled out people find all kinds of footguns and issues with them. The C++ committee basically evaluates features almost entirely in the abstract, writing papers and discussing privately among a small group of people about things instead of working on proof of concept implementations, getting actual real world feedback on it, or having something along the lines of Rust's nightly where experimental features can be tried out.
munificent 3y ago
Agreed. The classic claim about C++ is that everyone wants to remove half of its features, but no one can agree on which half.

kllrnohj 3y ago

I think async is still in the more just trendy camp than being a proven asset. After all, thread per connection is perfectly viable for the vast majority of servers. Most people aren't re-writing NGINX, after all (hopefully...). It's a shame Rust let itself be distracted by it instead of focusing on refining its strengths and developer experience

riku_iki 3y ago
> Most people aren't re-writing NGINX, after all (hopefully...). those people probably may use another language (java, go, c#) if absolute performance is not critical for them.
- kllrnohj 3y ago
  That's a false equivalence. I can have a performance limited server that is not limited on concurrent connection count in which case thread-per-connect is both simpler and scales great compared to async. async doesn't optimize performance in general rather it optimizes for number of open concurrent connections specifically. Which primarily only helps if you aren't doing much of anything in terms of compute per connection.