Should I Py or Should I Fortran?
milancurcic.com
milancurcic.com
I don't feel this is the whole truth. You can (and many people do) write a modern Fortran MPI-CoArray application for HPC and it can be slim, compile and run fast. No big ecosystem, like a small C application. The same is most likely not true if you include Python in your toolchain and then use some FFI to call C or Fortran in performance critical sections. As the author, you might be able to hide the ugliness (such as Numpy does it), but it can be a show stopper for maintainability and future generations working with the code. That's probably why still so many new HPC codes are pure Fortran/C codebases and Julia or Python remains the language for postprocessing data on workstations.
I'm always sad that the power systems industry has mostly moved from Fortran to C++ as the Fortran is much easier to read and doesn't make overzealous use of OO principles.
I use a lot of Python for process automation and data analysis. If I had to put numerical code in production it would probably be in either Fortran or Julia. My problems with Fortran usually boil down to libraries for certain things like database access. I did a little googling and there is some ODBC support, but it doesn't seem to be very good.
I agree -- many general purpose domains are lacking Fortran libraries. Regarding DB access, Arjen Markus has an interface to SQLite, but I'm not aware of anything else.
As almost everything out there has a C API, getting it compatible with Fortran is a matter of doing the grunt work and writing the wrappers around the C functions. To me, the lack of such Fortran libraries just shows there hasn't been much need for it.