Could you elaborate? I’m using gfortran 14.2 and it works well on CPUs.
I could agree if “modern computers” was referring specifically to GPUs and other accelerators. At least that was one of the critiques LANL had in that other report (An evaluation of risks associated with relying on Fortran for mission critical codes for the next 15 years).
I agree with @PierU, this is an over-generalization; the flip-side being that I partially agree with this. Some codes indeed don’t map well to modern architectures, but I think this is true for many C and C++ codes too. One problem with F77 codes is the heavy use of common blocks and static variables (i.e. save), which can be a blocker for multithreading. In the past I’ve met two domain scientists/engineers (one from TUM, one from RWTH) who told me their university engineering departments had large existing codes (finite elements, tribology) which became obsolete as a result of being limited to single-threaded execution only. The younger PhD students did not have the knowledge needed to refactor these programs. Also SciPy had this problem with some of the included ODE solvers. Their solution was to rewrite them in Cython/C, also for other reasons (toolchain availability).
This really varies between organizations. In general I would agree that Fortran was kicked out of CS departments already decades ago. Engineering departments have replaced Fortran with Python/MATLAB/Julia and this process also started decades ago. Many students learn Fortran when confronted with existing applications.
Concerning the translation of Fortran to C++ using LLMs. It is interesting that DARPA is also funding a program to translate C to Rust:
There have also been calls from the US Department of Commerce to drop C++ in new applications in favor of memory-safe languages like Rust and Go. I’m not sure how relevant these calls are to the applications at LANL, which are probably ran behind an air gap anyway.