Just cus they add a feature to a language doesnt mean u have to use it. Though it does seem very few programmers are smart enough to stick to the most basic features whenever possible.
One problem here is that everyone ends up with their own little niches of the language that they like, and nobody's code looks like anyone else's, and suddenly to read a codebase you do need to know huge swathes of the sprawling language.
At lastjob, we did a lot of C++, and I could tell whose code I was reading without checking blame because I knew who liked what idioms and features.
1. I got a couple of downvotes a few days ago because I commented that I don't like the &s of Elixir (kind of shortcuts for 'fn x ->') and I prefer to write the full form as it's easier to read for everyone no matter how proficient in the language (zero to expert.) I also don't like and almost don't use the & shortcuts in Ruby (positional arguments.)
2. I got a customer recently with the lead developer fond of each_with_object. I never saw that in 17 years of Ruby and I had to check the reference. It's probably faster than the naive implementation (more time inside the C implementation doing real work vs inside the C parser?) but the naive one is immediately readable by anyone.
> Just cus they add a feature to a language doesnt mean u have to use it
While I absolutely agree with this in general, in practice with C++ if you're trying to use it safely you do in fact need to use those new features. But the old features are all still around too. It's a very, very large language in terms of mental space required these days.
C++ the "language culture" unfortunately has a lot of gatekeeping as well. The fact that the gatekeeping generally revolves around "replace feature from n-5 years with the newer feature in the latest 0x00x release" is a bit tiresome.
Yes, I'm exaggerating, a bit.
As for the Microsoft whomever-he-is: I agree in theory, I disagree in practice. If there are a lot of C++ devs writing important code, then let them continue to do so in their prime language that they've invested decades of hard work keeping up with the feature treadmill. New devs? Only if you have to.
> "replace feature from n-5 years with the newer feature in the latest 0x00x release"
Let me put a more pro-C++ spin on that sentiment.
C++ is a language that's under long-term development. It might sound weird, but only with C++20 Bjarne Stroustrup felt that his vision for the language was now mostly-realized - and he had worked on it since the 1980s. With other languages, there's a lot of clearing-of-the-desk and starting things anew, while C++ has opted for incremental changes with backwards compatibility to before it existed (i.e. C).
But, looking back, we get the sentiment you describe. Which, rephrased, sounds like this:
"Remember that annoying and ugly hack you had to use so far to get [complex thing] to work? Well, that finally got fixed. Now there's a shiny new language feature / standard library construct which does that more nicely. But your existing code will also work."
Agree 100%. The C++ language and ecosystem shouldn't feel dynamic, given its age and the installed base, and yet it really does. I remember when c++11 came out and all the crazy typedefs I had to type out just disappeared overnight, and I was able to write statements like "using Elem = uint64_t; using Node = MyClass::Node<Elem>;" which were so much more straightforward. Function pointers disappeared too and were replaced by lambdas so I could write my own "each_node" functions and actually have them be really useful.
Then we had concurrency primitives, and now apparently there's a module system in c++20 which should be interesting. C++ clearly has no plans to bow out gracefully or otherwise go quietly into the night, which is fine by me since I still think it's the language which gives me, as a developer, the most freedom and control over the system.
"but only with C++20 Bjarne Stroustrup felt that his vision for the language was now mostly-realized"
So... let me ask you given this statement. Let's say there is an uber smart super productive programmer who states: I can rewrite the entirety of the ecosystem of one language in 1 year....
Would you tell them to rewrite all C/C++ in C++20
or
Rewrite it in Rust?
C++'s only real advantage in the current language marketplace is an installed library base. But how much of that is C++0x2020? Is the barrier to entry of a new programmer in C++ not just 40 years of language revisions, but a massive massive map of libraries where JSON library uses features from v2016, while XML library uses v2005, while some multithreading thing uses v2020...
And then there's the STL, and mixed-in-C standard library, ye gods.
Will Rust turn into that? Well, I think it kind of will to some degree as they try to find dialects that perfectly describe borrower checker semantics. Rust is a syntax soup almost on par with C++, but I guess we'll see.
> Would you tell them to rewrite all C/C++ in C++20 or Rewrite it in Rust?
Neither.
1. I wouldn't trust a person who says something like that. It takes a programming luminary several years to write a good (non-trivial, not-tiny) library the community can get behind, and even that usually involves iterations of use, feedback and partial rewriting/redesign.
2. Why would we want a "rewrite of the entire ecosystem" (whatever that ecosystem may be) all at once? That's a fiasco waiting to happen.
3. An "ecosystem" very often needs to be at least somewhat backwards-compatible, so I wouldn't want it written in something that's just out of the nylons.
Probably best to let that smart programmer write some decent foundational libraries which we can adopt one at a time, with increasing benefit of synergy.
> C++'s only real advantage in the current language marketplace is an installed library base
That seems untrue. C++ has various capabilities in different usage scenarios which other languages do not. But more importantly - programming languages don't all compete: They typically have different combinations of design goals. That's specifically true of C++ vs Rust.
> But how much of that is C++0x2020?
That doesn't matter much. For you, anything that's not written in the latest version of a language may be irrelevant/unusable. Not for the users of backwards (and forwards-) compatible languages like C, C++ and various others.
> Is the barrier to entry of a new programmer in C++ not just 40 years of language revisions
No, 40 years of revisions is not a barrier to entry. Your saying that makes it sound like you are not very familiar with the language.
> mixed-in-C standard library, ye gods.
double x = sqrt(x_squared);
... oh, the humanity! Who would ever write something like this? It's a non-polymorphic function and its symbol doesn't get mangled! Ye gods!
A vision that ironically is only fulfilled by Visual C++, and who knows when GCC and clang will manage to reach it, specially in what concerns modules.
