You're assuming wrong. Feel free to join us in scientific computing and make your case. Many have, and yet we still use fortran alongside the newer stuff.
Perhaps people who disagree with you do so out of something other than ignorance. Just a thought.
If there are reasons that are beyond "I already know Fortran" then please share. As my comment has pointed out the reasons mentioned above are incorrect. Modern C++ compilers, Rust, and Julia all have the edge on Fortran in their use case.
Also, people are now moving away from Fortran. There's a huge push in my field to use python and many students (like me) are't using Fortran.
These are some pretty naive suggestions for how to uproot an entire domain of computing.
Julia is a JIT language. Whatever edge you get in pretty code is going to be paid for in speed. Also, it's pre-1.0 and breaks compatibility frequently. 40-year-old Fortran code runs fine; 2-year-old Julia code is a syntax error.
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.
C++ has pointer aliasing shenanigans, so it's hard to make it as efficient as Fortran. I have seen a couple of projects that tried to port Fortran libraries to C++. They came out slower, buggier, and less readable. The only reason you'd want to do that is a specific hatred for Fortran -- which you are not the only one to have, but over the decades it hasn't proven to be a good motivation for redesigning software.
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. If you use Python for numerical computing, you are not "moving away from Fortran", you're embracing its success.
I don't actually know Fortran, but I have huge respect for the people who do. They're the reason most of the things I do are possible and fast.
Julia is JITed, but not in the same sense that (say) JavaScript is. It's more like a very lazy AOT compiler – and it can certainly hold its own against Fortran. That's not to say it has every optimisation it could, but the JIT is not the bottleneck there.
1.0 will be out around midway through the year, so that will ease the growing pains.
> 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.
> Fortran was great for 77 but isn't great for 17.
Fortran is not the same in 17 as it was in 77. They are different languages.
> 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.
Others do. Plenty of scientific programmers consider Fortran to be a perfectly sane language.
> I mean... when people use Fortran they usually don't even make use of Fortran 90's abstraction features. It's insane.
False. My group does.
> > 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
GP never said numpy contained Fortran in its code base, that was a strawman you added. Of course, that is what it means for numpy to provide a high-level platform for numerical computing: it means wrapping current code.
Eh. It's not too much of a strawman. I was under the apparently incorrect impression that there's some Fortran in NumPy, as the NumPy codebase is where f2py comes from. But it could very well not be used in any NumPy operations.
> But it even still have a comprehensive numeric library [1].
I think, by number crunching, they may mean blas/lapack, which is nowhere near replaced by that numeric library...
>> 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).
Not sure you are understanding what is meant by pointer aliasing. Explicitly marking pointer arguments as 'restrict' in C can have a pretty dramatic speed benefit as the compiler can assume that the memory spaces do not overlap. C++ does not (strictly) have such a feature, unfortunately, and I don't see how shared_ptr/constexpr can fix this (although inline might in some cases)
You're assuming wrong. Feel free to join us in scientific computing and make your case. Many have, and yet we still use fortran alongside the newer stuff.
Perhaps people who disagree with you do so out of something other than ignorance. Just a thought.