Hacker News new | ask | show | jobs
by rosshemsley 2999 days ago
This could be a joke. Or not.

It is very much in keeping with the current direction of C++, which appears to be:

"Oh no, C++ cannot keep pace with modern systems languages, let's repair it by whatever means possible"

Their heart is in the right place, but perhaps this accelerated process of mutating the language will ultimately be what kills it.

Personally, after having deep expertise in C++(11/14) I jumped ship to Go and will _never_ look back...

3 comments

There is nothing in C++ 11 and later that is forced on you. Everything that was added is optional. For personal projects I depend on some alternate implementations for things that are now in the STL because these not complete enough for my needs.
C++17 removed exception specifications from the language, and parts of the standard library, including std::auto_ptr and a lot of the <functional> header.

https://isocpp.org/files/papers/p0636r0.html

That only works if you are working alone. In a real world team environment you can’t always enforce your preferences on your teammates
I did not wrote these things for fun. I had a real need for each one. The STL is fine for the average case, but it is also limited. I hit these limitations.
>this accelerated process of mutating the language

Oh we can't be talking about the same language x) C++ moves fast? They took until 2017 to remove trigraphs for crying out loud! Absolutely nothing in C++>=11 breaks anything in the language.

Fair point. My feeling has been that the committee is trying to make the language safe (as is now the fashion) by adding increasingly more features, with the intention of deprecating old workflows aggressively.

But the language complexity is now so significant that a new dev would take years to fully understand both "old" C++ and new C++, and how to make them work well together

Except if you can use Go for your usecase then you probably didn't even really need C++ in the first case
Nah, plenty of overlap :) building networked services that deal with lots of data.
And why couldn't you do it in another language? If Go is performant enough, then I'm sure for example Java would be as well.