Microsoft demoed a version of their GraphRAG that translated C code to (I believe) mostly idiomatic Rust, and it ran without errors.
I tried to find reference to how they did it, does anyone know?
It sounds like this approach of translating old code could help speed up teams that are looking at rewrites. I also have some old code that's in Kotlin that I'd like to move to something else. I had a bad NullPointerException take down my application after missing a breaking change in a Kotlin update.
vlovich123 3 hours ago [-]
From the looks of [1] they have a graph DB storing the code structure and acting as the RAG for an LLM.
I mentioned neither of the things you're shouting at me about.
> I also have some old code that's in Kotlin that I'd like to move to something else.
Something else was left unmentioned because I'm not even talking about Rust. My reference to it was that I've seen the approach before where a RAG is used to aid in translating C code, and it's an interesting thing which with more examples, might be easier to non-experts like me.
Translating languages is of great interest to various communities. I have friends stuck with a Scala codebase written by geniuses who are no longer around, and they want to move it to something else that the team is comfortable with.
npalli 2 hours ago [-]
My bad. Sorry. Didn't read the full comment and you didn't deserve the accusations from me.
vlovich123 3 hours ago [-]
Or he’s just mentioning the other major transpiler he’s heard of recently that happens to be C to Rust and wondering how it works and if it could be adapted to other language pairs. You’re the one that’s taken the conversation in a super weird direction all by your lonesome.
jedimastert 3 hours ago [-]
I'm trying to think of a reason this couldn't be done more directly with a pretty run-of-the-mill transpiler. Like I understand if this is a technical demo and there is a LOT of Fortran code, but...?
I've actually had to do this with a couple of different Fortran projects when I was in college, I translated them to C for various reasons.
Maybe it's because it was specifically code written by scientists (i.e somewhat brute force and very straightforward) but there really wasn't very many features that I can recall that didn't have a direct C counterpart, other than column major ordering and arrays staring at 1.
Was I just blissfully unaware?
AndrewGaspar 2 hours ago [-]
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.
jeffbee 1 hours ago [-]
Doesn't CUDA handle FORTRAN as such?
1 hours ago [-]
SanjayMehta 2 hours ago [-]
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?
musicale 1 hours ago [-]
Good idea. I'd much rather write
do concurrent (i = 1:n)
y(i) = y(i) + a*x(i)
enddo
and then let the a compiler translate it into
std::transform(par, x, x+n, y, y,
[=](float x, float y){ return y + a*x; }
);
if C++ is required for some reason.
npalli 3 hours ago [-]
This is great effort, wonder how it compares to Fortran2Cpp
LLM as translators for Cobol code to Java or Go should be attempted. And Shut down the IBM mainframe rent seek business for good permanently.
3 days ago [-]
almostgotcaught 2 hours ago [-]
What is the point of this? Fortran is both faster than cpp and easier to write than cpp. It's also by no means a dead or dying or whatever language. Smells like literally "your scientists were so busy they forgot to ask why".
jandrewrogers 1 hours ago [-]
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.
walleeee 42 minutes ago [-]
> Almost all new code was written in C++ because it was easier to maintain.
What makes you say so? See musicale's comment above. I have a hard time seeing C++ as easier to maintain, if we are just talking about the language. The ecosystem is a different story.
jandrewrogers 8 minutes ago [-]
For pure number crunching, Fortran is nicer. Unfortunately, performance for most codes became about optimizing memory bandwidth utilization at some point in the 2000s, and systems languages are much more effective at expressing that in a sane way. It was easier to make C/C++ do numerics code than to make Fortran do systems code. Some popular HPC workloads were also quite light on numerics code generally, being more about parallelization of data processing.
This was before modern C++ existed, so most of the code was “C with classes” style C++. If you can read C then you can read that code. I don’t consider that to be particularly maintainable by modern standards but neither is Fortran.
Modern C++ dialects, on the other hand, are much more maintainable than either. Better results with a fraction of the code. The article doesn’t say but I would expect at least idiomatic C++11, if not later dialects.
jeffbee 1 hours ago [-]
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.
greenavocado 2 hours ago [-]
Chesterton's Fence
Rendered at 03:25:15 GMT+0000 (Coordinated Universal Time) with Vercel.
I tried to find reference to how they did it, does anyone know?
It sounds like this approach of translating old code could help speed up teams that are looking at rewrites. I also have some old code that's in Kotlin that I'd like to move to something else. I had a bad NullPointerException take down my application after missing a breaking change in a Kotlin update.
[1] https://microsoft.github.io/graphrag/
> I also have some old code that's in Kotlin that I'd like to move to something else.
Something else was left unmentioned because I'm not even talking about Rust. My reference to it was that I've seen the approach before where a RAG is used to aid in translating C code, and it's an interesting thing which with more examples, might be easier to non-experts like me.
Translating languages is of great interest to various communities. I have friends stuck with a Scala codebase written by geniuses who are no longer around, and they want to move it to something else that the team is comfortable with.
I've actually had to do this with a couple of different Fortran projects when I was in college, I translated them to C for various reasons.
Maybe it's because it was specifically code written by scientists (i.e somewhat brute force and very straightforward) but there really wasn't very many features that I can recall that didn't have a direct C counterpart, other than column major ordering and arrays staring at 1.
Was I just blissfully unaware?
https://github.com/HPC-Fortran2CPP/Fortran2Cpp
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.
What makes you say so? See musicale's comment above. I have a hard time seeing C++ as easier to maintain, if we are just talking about the language. The ecosystem is a different story.
This was before modern C++ existed, so most of the code was “C with classes” style C++. If you can read C then you can read that code. I don’t consider that to be particularly maintainable by modern standards but neither is Fortran.
Modern C++ dialects, on the other hand, are much more maintainable than either. Better results with a fraction of the code. The article doesn’t say but I would expect at least idiomatic C++11, if not later dialects.
https://github.com/flang-compiler/flang
https://flang.llvm.org/docs/