Long ago C++ made C a little bit more complex. Because there were already lots of C programmers that wasn't a big deal.
But then it didn't stop. Little by little C++ grew into a monstrosity. A lot of people went along. I gave up.
For new programmers to climb in 2-3 years a mountain that seasoned programmers took 15-20 years to climb is asking too much.
If you read the whole spec, it looks super complicated. But getting to a mental model that works in 99% of cases is not _that_ hard.
Rust was by far easier.
That said - that’s an extremely biased statement and I recognize that. I think it was largely the compiler that helped make it easier.
That said code in C++ would just vomit cryptic messages about templates and SEGFAULT nearly all the time.
What I'm trying to say skill floor - minimum skill/time needed to learn something to do it however in Rust is higher than C++. Although not in the sense of you must be this smart to enter, but you need this much time to learn it. If I can learn it, and I'm a mediocre programmer it's not an issue of skill.
That said skill ceiling - skill needed to do it efficiently and without error is much higher in C++ than in Rust.
Things that Rust does that makes things easy for me as a less-experienced non-systems programmer:
- very good documentation and compiler errors
- cargo makes dependency management and distribution a breeze (big plus over python)
- footguns are easily recognizable and avoided (unsafe)
- strong typing allows me to express more invariants in the type system which makes my code easier to reason about (another big plus over python)
The borrow checker can be an impediment at times and I'm probably leaving some performance at the door by generally avoiding references in data structures. I've found that this is less of a problem over time. It can also be way more verbose. But I have way more confidence that things will work at the end of the day, which makes it worthwhile for me, even if on the surface it is take longer and be harder to write than python.
It doesn't actually make for a good argument.
C++ makes more sense to me than Go or PHP. And probably Python.
You can get comfortable with some idioms of C++, that's fine. Can you understand what any valid C++ code means? No. Such person does not exist, not even Bjarne.
C++ is a mine field. You need to learn where all the mines are and spend your day carefully walking around them.
Some languages (like C) are easy but using them is hard.
Time to be reasonably sure your multi-threaded code won't crash randomly: Takes ages longer in C++, even if you're experienced.
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.
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."
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.
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.
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!
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.
Amusingly, this was always the criticism I've seen leveled at Lisps over the years. It's just as true in C++ for sure.
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.
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.