That is simply not true. An educated person with minimal programming exposure can readily pick up modern Fortran programming in 1-3 days at a pragmatic level.
Did you mean, "Julia never found any widespread adoption and remains an obscure, niche language"?
Fortran was the world's top programming language until the new millennium and is still among the top ten most popular. Arrays in Fortran can start from any index; the default choice is 1, which can be overridden with literally one keystroke: 0.
No, you can still trust compilers: 1) The hand-tuned BLAS routines are essentially a different algorithm with hard-coded information. 2) The default OpenBLAS uses OpenMP parallelism, so much speed likely originates from multithreading. Set OMP_NUM_THREADS environment variable to 1 before running your benchmarks. You will still see a significant performance difference due to a few factors, such as extra hard-coded information in OpenBLAS implementation.
Fortran has officially had the concept of modules for 35 years, which just made its way to the C++ world in 2020. It's the people who cannot update and sync with contemporary technology and remain stuck to COMMON blocks.
As someone who has been using about a dozen programming languages over more than two decades, I completely disagree with your experience, some of which appear to be due to incomplete knowledge of the Fortran programming language, including your statement "lacking in standard IEEE numerical things such as a function to check for nan". Everyone talks about C and C++, but we all know in our hearts how terrible the syntax of these languages is.
The "Hiring Fortran programmers is risky" argument is incorrect. This is, in fact, the whole point of Fortran, that anyone as dumb as a rock "would" (not "could" or "might") write performant code. There is currently no other language that can achieve this. Any other language claiming this capability is essentially recreating Fortran (perhaps with a slightly different syntax). Fortran Standard has been pursuing this sole goal for 70 years and has become extremely good at it.
Your argument applies very well to C++, though. But it's not too hard to catch a novice there, either.
This process of language love and hatred over a short period is what's called language fad. Ten years ago, people wrote articles praising MATLAB over established languages. I do not recall any of those writings ever mentioning Matlab's licensing as an issue. MATLAB is now >1000 fold better than ten years ago. Yet, the new generation throws it under the bus daily because it's not their favorite. Change is the only constant in the world of programing fashion and language fads.
The hard line limit length is at 1,000,000 characters not 10,000.
Also, all major compilers currently have flags to significantly extend the line limit length.
All Julia codes are arbitrarily extensible. Any Julia code can always be readily extended to silently yield incorrect results. That is the whole point of the blog post shared above. Justifying the indefensible is different from wanting or liking it.
That "always" holds for the Julia language almost surely as long as interfaces are missing in the language. It is just a matter of time to find newer issues.
Except for the fact that your Julia code will always suffer from correctness problems, something that would rarely if ever happen in Fortran. https://yuri.is/not-julia/
As of today, Fortran is newest and the oldest programming language with its most recent standard in 2023 and its first draft as the first high level programming language in 1954.
Our discussion will continue as long as one side believes fair, realistic benchmarks are merely moving the goalposts. Your benchmark has a severe fundamental flaw, especially given the tiny reported runtimes. I hope you realize and fix it before other critics (perhaps more credible than an unknown forum contributor) begin to question your programming knowledge or fairness.
To address the matter, you must compile/write whole programs in each of the respective languages to enable full compiler/interpreter optimizations. If you use special routines (BLAS/LAPACK, ...), use them everywhere as the respective community does. Apples to Apples.
It is not just about call overhead. It is about a whole suite of aggressive optimizations only possible for a whole program. Point to one person or entity in the world who calls SUNDIALS Julia wrapper to bind their C production code to SUNDIALS. If you cannot, you have two options: 1. make your Julia benchmarks concrete and realistic or 2. cease and desist from pointless advocacy of your employer (JuliaComputing) and its benchmarks in public forums.