That assumes a whole lot about their goals. If everyone sticks with C++ we would never have nice things like Zig/Nim/Rust that are advancing the conversation about how we should be doing systems programming tasks with code. C++ is quite influences by a lot of this. Like, let emm hack and learn. Also I think Nim is a very productive language to be hacking in and much easier to get going with than C++.

As they say, let people enjoy things

That take detracts from the amazing work people have done over the decades to research and implement improvements to C and C++. We can innovate without throwing things away, even if it may seem boring to the uninitiated.

People have done (and are still doing) amazing work in Fortran too. Why should we use C or C++ when Fortran was already perfectly fine?

Fortran us better than C and even C++ for its domain, high-performance numerical code. The guaranteed lack if aliasing allows for optimizations not always possible in C code. Built-in handling of stuff like complex numbers and even range types in modern Fortran (that is, supported for last 25-30 years), along support for parallelization, and with robust structured / procedural programming, is just the right tool for some jobs.

BTW if you run fancy modern stuff like numpy, you run quite some Fortran, because it includes, for instance, BLAS.

None of this is true or very important anymore.

For aliasing, in C, there's the restrict keyword, although it isn't used that often. If you take a look at BLIS or even BLAS, restrict isn't used. C++ doesn't have restrict, but that hasn't stopped the development of great numerical linear algebra libraries like Eigen or Armadillo.

C++ has had std::complex for... forever. And C99 has support for complex numbers.

Range types are handy, but not having them typically isn't a show stopper when designing libraries of numerical kernels. They are more useful for high-level prototyping, a la MATLAB. Nevertheless, it's not that hard to emulate the behavior using a well-designed API in C, or operator overloading in C++.

The only parallelism that Fortran has that C or C++ lack is co-array Fortran. I haven't used it myself, so can't speak to how useful it is. Both C and C++ have many options for parallelism: pthreads, OpenMP, MPI, C++'s parallel stuff, and tons of other libraries.

I'm not sure what "robust structured/procedural programming" is. I think Fortran is at a clear disadvantage compared to C and C++, here. The amount of boilerplate needed to define a function in Fortran is pretty painful. Fortran's control flow is a subset of C and C++'s, so any style of structured or procedural programming you would do in Fortran can obviously be done in C and C++.

And of course, numpy (and similar) call out to Fortran, but they call out to loads of C and C++, too!

This isn't to say Fortran is a bad language. I work with people who use it and prefer it. But the reasons you pointed out simply aren't valid. A good reason to use Fortran: you work in a group where Fortran is the language that's used and you want to be able to contribute to what's going on!

Exactly. They are just arbitrarily drawing the line of which language is sensible based upon what was hot when they made their choice.

It doesn't detract from that at all, chief. What a weird thing to say. Particularly in the case of Nim -- it doesn't "throw away" C or C++, it compiles to them!

...decades of research dedicated to handling problems introduced by C and amplified by C++.

Sometimes it makes sense to simply reset things.

Sure. But we can also innovate with throwing things away, which has its own set of advantages.

I have been learning Rust so it is top of mind for me. Rust started with some really tough constraints:

1.) How can we eliminate undefined behavior?

2.) without sacrificing any performance

From there, they built a powerful programming language that has always honored zero cost abstractions and elimination of undefined behavior. This is like a 15 year development and the result is a little hard to understand at first but one of the most innovative things in the realm of systems programming [that people are actually using at scale]. I know Rust borrows a lot and is built on the shoulders of giants and is not a singular invention, but it is slowly winning hearts and minds in places where languages like Ocaml and Haskell never could. You really could not do something like this by saying "Hey, how could we eliminate UB in C++?" Starting anew was the solution :)

> That take detracts from the amazing work people have done over the decades to research and implement improvements to C and C++.

What kind of argument is that?

> We can innovate without throwing things away, even if it may seem boring to the uninitiated.

You can’t innovate without breaking backwards compatibility. C++ is an evolutionary dead end that collapses under its own complexity, deal with it.

Ugh, as a C++ programmer - for the love of god don't choose the language for career stability. Both the language and the ecosystem is horrible. Choose it if you need it work in the domain of your choosing. For me it happens to be the case. If you want to choose a career language go for any of the other TIOBE usual suspects.

I completely agree that if you want to be a career programmer, focus on solving problems for business. But it can be done in any language nowadays.

I perhaps used words in a confused combination. There are two connotations to stability here - 1. language and ecosystem standardization and 2. having a stable and predictable career. C++ has both a plenty (2. if you find your niche and then you are nigh irreplaceable, but not perhaps at FAANG rates).

Your knowledge never gets old, basically in C++.

The problem with C++ is that it is a horrible language in several ways. I guess the root cause is that it's basically a sugared C preprocessor with an infinite amount of special rules and special cases, that attempts to retain backward compatibility while adding new features. If my domain did not need it I would not write it. But it does, so I do.

My advice not to choose C++ because of career stability meant - "It's a bloody awful thing! Don't choose it if you have options unless you absolutely want to!"

> You think things are looking better in JS/Python world?

Yes.

Let's face it: C++ is pain. Even with all the improvements of the last 15 years.

Choosing something which us not C++ may be a long-term goal by itself.

Have you considered there may be a reason why so many large tech companies are so eager to move away from C++?

Perhaps they care more about exploration and learning rather than career growth and solving business problems.