Edit: plus to ship our code to others requires a free good quality compiler. In the C/C++ world, that is standard. In fortran, that is not the case.
Edit: plus to ship our code to others requires a free good quality compiler. In the C/C++ world, that is standard. In fortran, that is not the case.
Regarding C and C++ compilers, for the same reasons most high performance HPC computers use Intel, IBM, PGI compilers instead of plain gcc or clang.
I don't think commercial/open source is the key here: on the fortran side we have been long suffering from a lot of bugs/regressions with the current versions of intel fortran (with respect to the "latest" features like OOP) -- I would even say that they could be more than we are finding in gfortran.
An explanation could be that they are investing time in supporting their big customers that likely use ancient code bases.
gfortran also does not do GPGPU.
It was quite surprising to find out the lack of understanding from Khronos that CUDA supports Fortran out of the box, during OpenCL 3.0 Q&A session.
I can code with CUDA in many more languages than fortran. If I wanted to use gfortran, I just would make a wrapper to CUDA with C++.
Yet, inline assembly is not part of ISO C.
Or one that generates lousy machine without full advantage of the CPU vector units.
Yet, vector instructions are not part of ISO C.
I also don't expect e.g. Ruby to have libraries for AAA game engines, or Erlang to have numeric libraries.
Most of the fortran codes I'm working on would be much simpler with a common libraries to do things like that.