> Julia is a JIT language. Whatever edge you get in pretty code is going to be paid for in speed.

That is incorrect. This nonsense that JIT is slow is an old belief that's hung around because it sounds nice. The fact is that the numbers don't line up [0].

> Rust is a nice language, but all of its numerical computing is experimental 0.x stuff. You'll probably end up wrapping another library to do your number crunching. It's probably written in Fortran

It's new and it's growing. It's also a single example for a single case.

But it even still have a comprehensive numeric library [1].

> C++ has pointer aliasing shenanigans, so it's hard to make it as efficient as Fortran

I don't know how this could be the case (especially with the addition of shared pointer) but you shouldn't be writing code with huge shared memory dependencies. Use constexpr, use inline, and use functions. There's no need for 20 functions to have shared memory access to a piece of data (which I have seen scientists do).

> I have seen a couple of projects that tried to port Fortran libraries to C++. They came out slower, buggier, and less readable.

That is on the programmers who wrote it, not the language's fault. There's no magical reason that Fortran should be faster then other programming languages. That's like me saying "Some of my friends tried to design a new car engine. Their car came out slower and buggier then my Ford Model T which still runs perfectly". It's anecdotal evidence that doesn't say anything about C++.

> The only reason you'd want to do that is a specific hatred for Fortran -- which you are not the only one to have

I don't have a hatred for Fortran. I just don't see any job where I'd prefer using Fortran over a more-sane alternative. Fortran was great for 77 but isn't great for 17.

> over the decades it hasn't proven to be a good motivation for redesigning software.

Comparability with modern software, improved performance from modern language features, pool of developers, further abstraction of your implementation to remove cruft from the code base using modern language features, and easier deployment are the reasons why we shouldn't be using Fortran.

I mean... when people use Fortran they usually don't even make use of Fortran 90's abstraction features. It's insane.

> Of course people like to use Python, but you don't get to use Python instead of Fortran. That would be incredibly slow. You use Python and Fortran. For example, you use NumPy and SciPy, which make Python a great high-level platform for numerical computing because they wrap large amounts of Fortran code.

You are mistaken. NumPy does not contain Fortran in it's code base. SciPy does but it only makes up 25% of the SciPy code base. I have no doubt that within the next 20-50 years that will slowly be removed bit by bit.

Wrapping a legacy library is the first step to replacing it. Once you remove the hard dependancy you will remove

> If you use Python for numerical computing, you are not "moving away from Fortran", you're embracing its success.

No you are definitely moving away from Fortran and towards better tools. The old cruft may still be there but as time moves it will slowly be replaced. You'd never need to use Fortran to get Fortran style speeds with modern software architecture using just python and C [2]. I've seen some crazy projects use this approach and outperform some native C applications.

[0] - https://julialang.org/benchmarks/
[1] - http://rust-num.github.io/num/num/index.html
[2] - http://cython.org/