Re: “speed of change of the language,” that is a severe concern we have with Fortran but unfortunately our concerns are shared by very few, or one can say almost no one.
Our experience is as follows.
Code base after code base migrates away from Fortran after remaining in maintenance-only mode for ages on account of having legacy FORTRAN-style constructs all over the code - like those in this recent comp.lang.fortran thread - that few young engineers want to touch.
But then when we try to comprehensively modernize the code or write new code particularly toward large or multi-team application developments using modern Fortran, our computational technology senior leads and managers find that so many of the well-established and proven good coding practices starting with
- Explicit typing (sorry, requiring
implicit none in every scope does NOT count as Fortran providing explicit typing),
- proper Enums,
- Generics,
- Exception Handling for situations that truly are exceptions,
- OO conveniences, etc.
are all either missing in Fortran or that the Fortran standard offers half-baked or token facilities for which the compiler support is so poor the first dozen or so attempts to write small test cases to explore the facility in the standard results in having to file bug reports with the compiler team(s) and wait 6 months to 2+ years or forever for fixes.
The ground reality is many of us are polyglots: we can write highly performant and cross-platform code libraries in modern C++ (C++14,17, and now 20 revisions and with Microsoft under Herb Sutter taking renewed interest in ISO standard support in their C++ compiler making a big difference) and/or C also making use of other powerful and more importantly, fast advancing libraries to achieve quite a few HPC tasks as needed. We can then have any number of bindings to UI-driven programs, cloud computing and/or mobile apps, interpreted environments, spreadsheets, other compute platforms to facilitate convenient consumption. Fortran can be entirely superfluous under the circumstances.
At the present rate, we reckon it will take at least 15 to 20 more years for modern Fortran to catch up to where we would truly prefer Fortran to be today i.e., in year 2021. This is simply based on 10+ years of successful use of certain good coding practices with other languages starting with Ada that had most of what we seek by 1990s to early 2000s. And this is assuming Fortran 202Y even adopts such feature sets - it’s highly unlikely given extreme resistances. The estimate of 15-20 years is based on the facts that it will be about 7 to 10 years or so until Fortran 202Y is published and about 8 to 10 years until two or more compiler provide robust (relatively bug-free) support for the facilities. In the meantime, outside of a few limited domains like the numerically heavy portion of climate simulations, so much else of scientific and technical coding will have no need for Fortran for sure.
The situation is really dire for Fortran in many scientific and technical computing domains: the only hope for it is the great efforts by @certik , @milancurcic , @everythingfunctional , and everyone working toward Fortran stdlib, etc. The pace needs to really pick up to turn things around for Fortran.