One of the authors of stdlib here. I agree with many of your points.

Fortran needs a good compiler, that is why I started LFortran some time ago:

https://lfortran.org/blog/2019/04/why-we-created-lfortran/

and there is also Flang. Both Flang and LFortra are in development. GFortran is currently the most advanced open source compiler.

See our page for the list of all compilers:

https://fortran-lang.org/compilers/

> Both Flang and LFortra are in development. GFortran is currently the most advanced open source compiler.

Most of these tiny programs do at-least compile with ifc —

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

— fewer of them compile with gfortran —

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

— and fewer still compile with flang —

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

No doubt there's something ifc specific about the programs, or something obvious to a Fortran programmer but…

That is you problem right there, gfortran instead of something like Intel or PGI.

That might fix the compiler quality and vectorization, but it doesn't fix the lack of library and terrible string support.

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.

When I learn fortran years ago, I quickly gave up on string manipulation and custom file parsing. It just not worth it to struggle with string and file manipulation in fortran. Instead, I simply read or dump the array directly into raw file or netcdf file and wrote some python script to prepare input files for the fortran program or read and visualize the output.

Sure it does, because they also come with high quality libraries.

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.

Nowadays intel is not a reference for C++; the versions found on HPC compilers are not the fastest nor the best following the latest standards.

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.

Most code bases don't care about latest standards, rather quality of generated code.

Exactly, that is my point: so we are mainly still in the land of Fortran95, which is not designed for taking advantage of the latest features of the hardware.

Which doesn't change the current situation that commercial compilers still win, and NVidia/ARM contribution to LLVM comes from PGI experience.

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.

But then we are not talking about fortran anymore: I tried recently PGI and it is far behind than intel/gfortran with respect to the standard.

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++.

Sure we are, OpenAAC, MPI and GPGPU support are a standard feature of any commercial Fortran compiler.

And yet none of those technologies is fortran-specific, nor mentioned on its standard, nor solve at tiny bit the problems the OP was specifying.

Try to give a C developer a C compiler without support for inline assembly to see how they will appreciate it.

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.

Do they have libraries for JSON, network functions, strings, data types (e.g. dict/map, resizeable vector, sorting, linked list, kd-tree...), databases, and all the things that make a programming language useful? Please point me to the library. I'm only aware of numerics.

They have the libraries that make sense for the people that are willing to pay for commercial compilers, in the contexts that Fortran gets used for.

I also don't expect e.g. Ruby to have libraries for AAA game engines, or Erlang to have numeric libraries.

I guess that's a no then. Well, I better give up on Fortran if I need to load configuration files, sort data, expand an array, take command line parameters, associate some text with the data, or use a hash table, if those aren't reasonable features. Apparently, it's only acceptable to use fortran to load some matrix, process it, then spit something out into a file.

Most of the fortran codes I'm working on would be much simpler with a common libraries to do things like that.

There is a cottage industry that actually do just that: create a wrapper program with nice gui to prepare data file input and read/visualize data file output from an open source fortran model. For example, aermod is an open source air pollutant dispersion model developed by EPA and there are a bunch of commercial GUI wrapper for it because (as you note it) you can't expect scientists without computer science background to compile, prepare data and parse the output of a fortran program. Those thing are hard to do in fortran as a programmer, let alone as a scientist without computer science background.

It is a no if you are not willing to put the money into it.