Comment by lpapez | Hacker News Reader

Comment by lpapez | Hacker News Reader

Parent Full thread

Thankfully I no longer work with C++, but such proposals were my main problem with the language.

I had the impression that the vast majority of us regular users just wanted quality of life improvements: better error messages, networking library, a standard package manager etc. Literally most of what C++ code styles are concerned with is about picking what features are banned in that particular style.

But instead of doing something pratical, the commitee always went with the route of adding increasingly niche features citing that useful things are "out of scope" or "implementation defined" or "userspace".

So what you get is incompatible ecosystems and cultures for an extremely complicated language.

Very happy working with Go presently, where exactly the opposite approach is being taken by maintainers. Eg: There was huge pushback regarding generics introduction (a genuinely useful language feature IMO), but they introduced very good vulnerability scanning (govulncheck) without me even hearing about it being under development.

People want better error messages, networking, a package manager, etc. But they also want compile time reflection. Sometimes it is even the same people!

Sure, I get that.

But my point is that niche (in my opinion) features seem to be getting into the standard much more often than things that are broadly useful (in my opinion).

To the contrary, these features should have been in C++ for decades, whereas standardizing networking at any point in time is a mistake because APIs and best practices for high performance networking constantly evolve ; if any kind of networking had been standardized in C++ 15 years ago, then today the only thing we could say is "don't use it" just like you mustn't use the standard network APIs of other languages if you remotely care about writing good software, just like you mustn't use std::regex or other things that were mistakenly standardized in C++.

With C++26 we're barely getting to where python was already in 2001 with the introduction of decorators or Java in 2004 with annotations. C# had these features from the very beginning (albeit at runtime, not compile-time like C++).

"The useful addition might become deprecated in a few years" is a poor excuse considering that all the time niche language features are being added which either take forever to implement, or end up getting banned in real codebases.

How is it okay that newly added language features end up unused/deprecated/discouraged, but it's a problem for libraries?

I never got to try exceptions and modules in C++.

Exceptions because every place I worked at banned them, and modules because they were not implemented by the time I left the language.

I'm 100% sure that people got (and will keep getting) much more value out of unfortunate std::regex and std::fstream than they will ever get from reflection (in the few places that will even allow using it at all).

Everywhere I worked we had our custom network stack, on top of posix or even lower level. We wouldn't replace it with something from the standard.

Everywhere I worked we also had custom ad-hoc reflection/code synthesis, usually via preprocessing. We would have replaced with a builtin solution in an heartbeat.

> all the time niche language features are being added which either take forever to implement, or end up getting banned in real codebases.

you work likely in a very specific niche as no language feature has ever been entirely banned in the places I've been to. There are hundreds of thousands of codebases happily using exceptions in C++. https://github.com/search?q=%22throw+std%3A%3Aruntime_error%... as well as any other feature you can imagine.

Reply on news.ycombinator.com