Fortran Should Be Dead. It’s Winning Instead.

You’ve probably never written a line of Fortran. You might not even know anyone who has. And yet, the weather forecast you checked this morning? Probably computed in Fortran. The climate model predicting whether your coastal city floods in 2050? Fortran. The nuclear simulation keeping deterrence credible? Fortran, Fortran, Fortran.

We’ve been told a clean story about progress: newer languages replace older ones. Python replaced Perl. Rust is replacing C. JavaScript ate the world. So why does a language born in 1957 — older than the integrated circuit — still dominate the most computationally intense work on Earth?

The assumption that Fortran survives out of pure inertia is the most lazy explanation in software. The truth is more uncomfortable: Fortran wins because modern languages are too flexible to compete.

Here’s what nobody explains to you. When you give a compiler freedom to optimize, you also give it ambiguity to second-guess. C lets pointers alias — two pointers might point to the same memory, so the compiler has to be conservative. Python is dynamically typed, meaning the interpreter does work at runtime that Fortran resolved at compile time in 1957. Every bit of flexibility you love in modern languages is a tax on performance.

Fortran was designed by people who didn’t care about your developer experience. They cared about one thing: crunching arrays of floating-point numbers as fast as the hardware could physically allow. The language is restrictive. It’s clunky. It looks like it was designed by committee in the Eisenhower administration — because it was. And that restriction is precisely what lets its compiler generate machine code that leaves C and C++ in the dust for numerical kernels.

Every feature you add to make a language ergonomic is a feature you subtract from its ceiling of performance. There is no free lunch, and the bill always comes due at the silicon.

Then there’s the library problem — or rather, the library advantage. BLAS, LAPACK, MPI routines, decades of battle-tested numerical code live in Fortran. You don’t rewrite sixty years of verified scientific computation in Julia because the syntax looks nicer. When a physics simulation needs to be trusted to model reactor safety or spacecraft trajectories, “new and shiny” is a liability, not a feature.

Every few years, someone declares Fortran dead. They point to Julia, to Python with NumPy, to Rust’s growing scientific ecosystem. And yet the supercomputing centers keep running Fortran. The DOE labs keep maintaining Fortran. The weather services of the world keep compiling Fortran. Not because they’re stuck — because they’ve done the benchmarks.

You don’t abandon a tool that works because a newer tool exists. You abandon it when the newer tool does the job better. For raw numerical performance, that day hasn’t come — and may never come.

This isn’t just about Fortran. It’s about a deeper truth we keep refusing to learn in tech: constraints are features. The things that make a language annoying — rigid types, no pointers, no dynamic dispatch — are the same things that let compilers produce blazingly fast code. The things that make a codebase hard to change are sometimes the things that make it reliable for decades.

We worship flexibility. We build tools that let anyone do anything. And then we wonder why our software is slow, fragile, and impossible to reason about. Fortran is the ghost at the feast, reminding us that sometimes the best engineering decision is to refuse to be clever.

So the next time you hear someone dismiss an old technology as “legacy,” ask them a simple question: if it’s so obsolete, why is it still running the world?

The most dangerous assumption in engineering is that newer means better. The most valuable lesson is that surviving decades of disruption is itself the strongest proof of value.