Comment by lucasyvas | Hacker News Reader

Comment by lucasyvas | Hacker News Reader

Parent Full thread

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.

> 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.

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.

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.

> 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.

Sitting on the C++ committee, we actually demand a lot of proof-of-concept implementation of proposals before they'll be accepted.

That list of bullet points (except the compiler one) is also applicable to the whole async ecosystem in Rust :)

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.

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.

Agreed. The classic claim about C++ is that everyone wants to remove half of its features, but no one can agree on which half.

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.

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

> 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.

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.

Reply on news.ycombinator.com