What you want isn't really "output C++ code that is pedantically equivalent to this Fortran code but with the array indexing fixed up", it's usually more like "translate this Fortran module into something that I can offload to a GPU using CUDA/ROCm/etc. with the same high level semantics, but GPU-friendly low level optimizations", and the exact composition of those low level bits probably don't look exactly like a loop-by-loop translation.

Yeah I've used FORTRAN to C transpilers before too and they worked fine. There were some downsides though like it has to add and subtract 1 everywhere to deal with FORTRAN's 1-based indexing.

In theory AI could do a more idiomatic translation, but I think I would still prefer the janky but correct translation over the looks nice but probably subtly buggy AI one.

I don’t know what the transpiled code would look like vs that rendered by an LLM, but maybe the hope is that latter will be more readable?

From the looks of [1] they have a graph DB storing the code structure and acting as the RAG for an LLM.

[1] https://microsoft.github.io/graphrag/

In my experience such methods work really well for small/simple code snippets. Attempting large code snippets is not functional.

I do not believe it ran without errors on all cases.

[flagged]

Seems pretty obvious to me, and I’ve written my fair share of both Fortran and C++. I think it is mostly that very few people know Fortran anymore and even fewer people want to maintain it. A vast number of people in 2025 will happily work in C++ and are skilled at it.

Fortran also hasn’t been faster than C++ for a very long time. This was demonstrable even back when I worked in HPC, and Fortran can be quite a bit worse for some useful types of performance engineering. The only reason we continued to use it was that a lot of legacy numerics code was written in it. Almost all new code was written in C++ because it was easier to maintain. I actually worked in Fortran before I worked in HPC, it was already dying in HPC by the time I got there. Nothing has changed in the interim. If anything, C++ is a much stronger language today than it was back then.

Some people at LANL seem to be on a holy crusade to replace Fortran with C++. They occasionally produce stuff like papers saying Fortran is dying and whatever. Perhaps it makes sense for their in-house applications and libraries, but one shouldn't read too much into it outside their own bubble.

I wonder if they feel that the toolchains are just rotting.

This. If someone can't correctly articulate the advantages of Fortran they shouldn't be migrating away from it. This is not to say that migrations should never happen.

The soon to be GCC 15 release will contain a COBOL frontend. Also other non mainframe compilers have existed for a long time, both proprietary and FOSS.

Thus, availability of a compiler is but a small piece of the puzzle. The real problem is the spider web of dependencies on the mainframe environment, as the enterprises business processes have been intertwined into the mainframe system over decades.

No, not for the foreseeable future. In fact, this is the absolute hardest possible code translation task you can give an LLM.

COBOL varies greatly, the dialect depends on the mainframe. Chatbots will get quite confused about this. AI training data doesn't have much true COBOL, the internet is polluted with GnuCOBOL which is a mismash of a bunch of different dialects, minus all the things that make a mainframe a mainframe. So it will assume the COBOL code is more modern than it is. In terms of generating COBOL (e.g. for adding some debugging code to an existing system to analyze its behavior) it won't be able to stay within the 80 column limit due to tokenization, it will just be riddled with syntax errors.

Data matters, and mainframes have a rather specific way they store and retrieve data. Just operating the mainframe to get the data out of an old system and into a new database in a workable & well-architected format will be its own chore.

Finally, the reason these systems haven't been ported is because requirements for how the system needs to work are tight. The COBOL holdouts are exclusively financial, government, and healthcare -- no one else is stuck on old mainframes for any other reason. The new system to replace it needs to exactly match the behavior of the old system, the developer has to know how to figure out the exact confines of the laws and regulations or they are not qualified to do the task of porting it. All an LLM will do is hallucinate a new set of requirements and ignore the old ones. And aside from just knowing the requirements on paper, you'd need to spend a good chunk of time just checking what the existing system is even doing, because there will be plenty of surprises in such an old system.

There are COBOL compilers that target JVM and .NET for as long as these technologies exist.

There are also modern compilers to IBM mainframes, including Go, C++, Java, PHP,..

Also outside DevOps and CNCF application space very few people bother with Go, specially not the kind of customers that buy IBM mainframes.

Apart from cobol is only part of the reason for running on a mainframe. The other part is the orchestration and "resilience" of the mainframe platform

You can run cobol on x86, there are at least two compilers.

f2c produces pretty sketchy C code. It's very easy for reasonable thread-safe Fortran code to go through f2c and end up as C code with globals and other thread-unsafe constructs. You have to be prepared to completely rewrite the generated C code to make it usable, possibly more unpleasantly than just doing the port by hand.