[ilovecaching]

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.

[Herbstluft]

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?

[nine_k]

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.

[sfpotter]

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!

[ParetoOptimal]

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

[sekao]

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!

[vkazanov]

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

Sometimes it makes sense to simply reset things.

[solarkraft]

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

[bitexploder]

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 :)

[wiseowise]

> 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.