Hacker News Reader

Comment by Verdex | Hacker News Reader

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

View on HN

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.

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

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.

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.

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.

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.

Reply on news.ycombinator.com