In 1957, a small team at IBM led by John Backus released the first Fortran compiler. The name was short for "Formula Translation," and the goal was modest by today's standards: let scientists write equations that looked like equations, and let the machine turn them into fast code. Nearly seventy years later, that language still sits underneath a surprising share of modern engineering. It helps shape aircraft wings. It produces the weather forecast you probably checked this morning. It models the chemistry inside battery materials that haven't been manufactured yet.
Most people find that hard to believe. Fortran almost never shows up in startup job ads or product launch threads, and plenty of working developers have never opened a Fortran file. So when a founder, a product manager or a writer types is Fortran still relevant 2027 into a search bar, they usually expect confirmation that it's a museum piece. What they find instead is a language that big research centers are still paying to modernize, with compilers that got meaningful updates as recently as this year.
This guide covers why Fortran has hung on, where it causes trouble, what the alternatives look like, and how to decide what to do if your company inherits Fortran code. No programming background is assumed.
Old, but not frozen in 1977
Most people picture Fortran as punch cards and shouty ALL-CAPS code. That was FORTRAN 77, and plenty of it survives, but the language has changed a lot since.
Fortran 90 was the turning point. It added modules, which let programmers group related code and data into tidy, reusable packages. It dropped the old rule that code had to start in a particular column. And it added whole-array math, so adding two huge grids of numbers together took one line instead of a hand-written loop.
Later revisions kept going. Fortran 2003 brought object-oriented features and, more usefully for today's world, an official way to call C code and be called from C. That single feature is why Python programs can use Fortran libraries without much fuss. Fortran 2008 added coarrays (a way to split work across many processors using the language itself) and a loop type called "do concurrent," which tells the compiler it's safe to run every pass of the loop at the same time. Fortran 2018 and Fortran 2023 followed, and work on the next standard is underway.
The tools moved as well. Intel's ifx compiler reached version 2026.0 this year with full Fortran 2018 support and parts of the 2023 standard. GCC 16.1, released in April 2026, gave gfortran native coarray support on single machines. LLVM's Flang compiler lost its "flang-new" label in 2025 and became the official LLVM Fortran compiler, and its version 22 release improved how "do concurrent" loops run on both regular processors and graphics cards. There's also LFortran, an open-source project that lets you run Fortran interactively, line by line, the way people use Python in a Jupyter notebook. It's still in development, but people don't build new tools for a dead language.
A language with one abandoned compiler is a risk. Fortran has active compilers from Intel, NVIDIA, HPE, GNU and LLVM.
Where Fortran quietly does the heavy lifting
Aerospace
Before an aircraft or rocket is built, engineers simulate it. The biggest of these simulations is computational fluid dynamics (CFD): the air around a wing is cut into millions of tiny boxes, and the physics of airflow is solved in each box, over and over, until the picture settles.
Several of NASA's long-running CFD programs, including FUN3D, OVERFLOW and CFL3D, are written largely in Fortran. The same goes for structural analysis. NASTRAN, which NASA developed in the 1960s to work out stresses in aircraft and spacecraft frames, was a Fortran program, and commercial versions descended from it are still used across the industry.
One clarification that trips up a lot of non-engineers: Fortran is usually not the software running on the aircraft itself. Flight control computers typically run code written in C, C++ or Ada, under strict certification rules. Fortran does its work on the ground, in the design and testing stage, where it helps decide what shape the aircraft should be and whether its structure will hold up.
Weather and climate
Weather forecasting is probably the most visible Fortran workload on the planet. The European Centre for Medium-Range Weather Forecasts runs its IFS model largely in Fortran. The UK Met Office's Unified Model is Fortran, and so is its successor, LFRic. The open-source WRF weather model and the NEMO ocean model are Fortran too.
Physics, chemistry and materials
Researchers designing new solar cells, catalysts and battery materials lean heavily on programs such as VASP, CASTEP, CP2K and Quantum ESPRESSO. All of them are built mainly in Fortran.
Hidden inside other software
Even people who never touch Fortran rely on it. The reference version of LAPACK, the standard toolkit for solving systems of linear equations, is written in Fortran, and many numerical libraries, including ones Python's scientific tools depend on, grew out of it.
Fortran by the numbers
Language statistics are slippery, so it helps to compare two kinds: how much people talk about a language, and how much computing time it actually uses.
The TIOBE index measures things like search activity, courses and vendors, not how much code runs. ARCHER2, the UK's national supercomputer, publishes which programs use its compute time. Put those two side by side and you get a more grounded answer to the search is Fortran still relevant 2027 than either number gives alone. Fortran is a mid-table language by popularity, yet on at least one major national machine, Fortran programs consumed well over half of the available computing time in the month examined.
TIOBE's chief executive, Paul Jansen, has partly credited legacy systems: as their original developers near retirement, companies are keeping and extending those systems rather than risking replacements.
Why Fortran is so good at math
Ask a Fortran programmer why the language is still fast and you'll hear a few recurring reasons. None of them are magic.
First, arrays are built into the language. An array is just a big organized block of numbers, like a spreadsheet grid with thousands or millions of cells. Here's what adjusting an entire grid of temperatures looks like:
That second line updates a million values. Just as important, the compiler (the program that turns human-written code into machine instructions) knows exactly what's being asked and can arrange the work to suit the processor.
Second, when a Fortran routine receives two arrays, the compiler may assume they don't overlap in memory. That lets it reorder and speed up calculations safely. C can do the same with a keyword called "restrict," but programmers have to remember to use it correctly.
Third, there's no background memory cleanup. Languages like Java and Go run a "garbage collector" that pauses now and then. Across thousands of processors, one random pause can hold up all the others, so Fortran's predictable memory handling means predictable timing.
Finally, compiler writers have spent decades tuning Fortran for exactly this kind of work.
What happens when the input data has holes
Real data is messy. Sensors fail, files get truncated, and a satellite sometimes misses a pass. Fortran programs written decades ago handle these gaps in ways that can surprise anyone building a modern data pipeline around them.
Many older programs mark a missing reading with a made-up number such as -999.0 or 9999. The code then checks for that number before using the value. This works fine until someone upstream changes the convention. Suppose a new data feed marks missing values as NaN ("not a number," the standard computer value for an undefined result) instead of -999. The old check never fires. The NaN flows into the math, and because any calculation involving NaN produces another NaN, one bad reading can spread across a whole region of the output. The reverse is just as bad: feed -999 into a routine expecting NaN and it will average -999 degrees into a temperature map.
Fortran 2003 added a proper toolkit for this, a module called ieee_arithmetic, which lets code test directly for NaN and similar special values. Lots of legacy programs were written before it existed, so they don't use it.
Old input formats add their own risks. Much legacy Fortran reads files by exact column position, so shifting one column means reading the wrong digits without complaint. Worse, under default rules a completely blank numeric field reads as zero. A missing pressure reading doesn't raise an error. It becomes a pressure of zero, which is absurd and still gets used.
Forecasting systems handle gaps deliberately. When observations are missing for an area, the model leans more on its own previous forecast there. That fallback has to be coded, tested and documented, and if it lives in an uncommented subroutine from 1994, nobody on today's team may know exactly what it does.
The second kind of data gap is missing knowledge. A constant like 0.4127 might sit in a routine with no comment. It might come from a wind tunnel test, a tuning fudge or an old typo everyone has calibrated around, and the person who knew may have retired. Test cases with known correct outputs often end up as the most reliable documentation a team has.
When two correct answers disagree
Here's a situation that confuses managers every time. The same Fortran program is compiled with two different compilers, run on the same input, and produces two different answers. Neither run crashed. Which one is right?
Often, both are. Computers store most numbers with limited precision, which means tiny rounding happens constantly. In ordinary arithmetic, (a + b) + c equals a + (b + c). On a computer, it can be off in the last few digits, because the rounding happens at different points. When a compiler reorders a calculation to make it faster, or when a big sum is split across a thousand processors and the partial results are added in whatever order they arrive, the final digits move.
For most engineering work, a difference in the seventh decimal place doesn't matter. In weather prediction it can, because the atmosphere is chaotic and tiny starting differences grow. Forecasting centers deal with this by running groups of slightly varied forecasts on purpose (called ensembles) and treating the spread as a measure of uncertainty.
For testing, teams usually keep a strict mode where the program must match its previous output exactly, bit for bit, plus looser tolerance checks for optimized builds. Without both, it becomes impossible to tell a harmless rounding change from a real bug.
The same conflict shows up during migrations. Picture a team that rewrites an aerodynamics code in C++. The new version predicts drag that is 0.3% lower than the Fortran original. Is the new code wrong, or did the old code have a bug that everyone had learned to live with? Comparing the two programs against each other can't settle it. The only fair judge is real-world data such as wind tunnel measurements or flight test results. Every disagreement needs an investigation, which is a big reason rewrites take so long.
The popularity numbers send mixed messages too. One summary of the June 2026 TIOBE index had Fortran sliding to 17th; by September it was 11th. Job boards list few Fortran roles, yet labs and aerospace suppliers often struggle to fill the ones they have. Watch who is still funding new Fortran work, not just the rankings.
Deadlines that don't move
Some Fortran programs have to finish on time or their results are worthless. Weather forecasting is the clearest case. A forecast for this afternoon's storm that arrives this evening isn't much use to anyone.
So forecasting centers plan compute time down to the minute. The model's running speed on a given machine is a hard requirement, not a nice-to-have. If a new compiler version makes the code 10% slower, that's an operational problem that has to be fixed before the upgrade goes live. Fortran's predictable timing, with no background pauses and mature optimization, is part of why these centers stay with it.
Aerospace has a softer version of this. During a test campaign or a mission, analysts may rerun trajectory or load calculations overnight so that engineers can make a go or no-go call the next morning. It isn't millisecond real-time, but the results must be ready, and trustworthy, by a fixed hour.
What happens when something breaks at 3 a.m.? Well-run systems plan for it:
• Long runs save their state to disk regularly (a checkpoint), so a crash costs an hour, not the night.
• Forecasting centers often keep a lower-resolution backup run ready.
• Input checks run first, because rejecting a corrupt file in minute one beats discovering it six hours in.
The edge cases that catch newcomers
If your team is picking up an older Fortran program, these are the traps that tend to cause the most lost afternoons.
• Implicit typing. In older Fortran, variables starting with I through N are automatically whole numbers unless declared otherwise. Misspell one and Fortran quietly creates a new variable set to zero. Modern code starts with "implicit none" to prevent this.
• No array size checks. By default, most compilers let code read past the end of an array and carry on with junk values. Options such as gfortran's "-fcheck=bounds" catch this during testing.
• Column order. Fortran stores grids column by column, while C and Python's NumPy store them row by row by default. Fortran also counts from 1 instead of 0. Pass a grid between the languages carelessly and you get data that looks plausible but is transposed or shifted by one.
• Integer overflow. Default whole numbers are often 32-bit, topping out a little above 2.1 billion. Meshes bigger than that make counters wrap to negative numbers, and the error shows up far from its cause.
• Shared global memory. COMMON blocks let any routine read or change a shared chunk of memory, and EQUIVALENCE lets two variable names share the same memory. Both hide dependencies and cause trouble when you try to run code on many threads.
• Variables that remember. A local variable given a starting value in its declaration keeps its value between calls, which surprises people from other languages.
• Silent math errors. Dividing by zero usually produces "infinity" and the run continues, unless someone turns on error trapping.
• Binary file mismatches. Raw binary output files can differ between compilers in byte order and layout, so a file written on one system may not read correctly on another.
How it behaves under pressure
Large Fortran simulations run on thousands of processors at once. The usual method, called domain decomposition, splits the problem into pieces. Picture the Atlantic divided into a few thousand map tiles, one per processor. Neighboring tiles affect each other, so after every step the processors swap a thin strip of border data using MPI (Message Passing Interface), which Fortran has supported well for decades.
This works well up to a point. Doubling the processors roughly halves the time, until the tiles get so small that processors spend more time talking than calculating. Getting a code to scale to half a million cores, the size of the largest ARCHER2 jobs, usually takes years of tuning.
Saving results is another pinch point. When tens of thousands of processes write output at once, the file system becomes the bottleneck, so serious codes use parallel libraries such as HDF5 or NetCDF.
At this scale hardware failures are expected, and checkpointing keeps one dead node from wiping out a day's work.
Then there are graphics cards. GPUs are now where much of the world's new computing power comes from, and Fortran has several routes onto them. OpenACC and OpenMP let programmers mark loops for the GPU with special comments. The "do concurrent" loop lets compilers such as NVIDIA's nvfortran and LLVM Flang move work to the GPU with fewer hints. In practice, the arithmetic is the easy part. The hard part is moving data between the regular processor's memory and the GPU's memory, which can eat all the speed gains if it's done carelessly.
Fortran alternatives 2027: what teams actually consider
Most comparisons of Fortran alternatives 2027 end up with the same short list. Each option solves some of Fortran's problems and introduces others.
C++
C++ is the most common replacement in high-performance computing. It has a far bigger developer pool, strong tooling, and libraries such as Kokkos and SYCL that help one codebase run on different hardware. The catch is complexity: for a physicist, fast Fortran is easier to write than fast, correct C++.
Julia
Julia was built for scientific computing, aiming to be as easy as Python and nearly as fast as Fortran. TIOBE's chief executive noted in September 2026 that it has been taking ground from MATLAB, though it sits 21st in the index and remains a specialist language. Its weak points are slower start-up and a younger ecosystem for formally validated work.
Python with NumPy, Numba or JAX
Python is where most new scientists start, and it's excellent for experiments and connecting pieces together. The heavy calculations happen in compiled libraries underneath, some written in C or Fortran. Numba and JAX can compile Python-style code into faster machine code for certain workloads.
Rust
Rust's selling point is memory safety: it catches bugs like reading past the end of an array before the program runs. Its libraries for large parallel work are still maturing, and few scientists know it yet.
How they stack up
The honest reading of this table is that no alternative beats Fortran on every row. The newer languages win on hiring and tooling. Fortran wins where decades of tested, trusted code already exist.
Rewrite, wrap or modernize?
This is where the question is Fortran still worth using for legacy scientific computing in 2027 gets practical. If you already own a Fortran program that works, you have three realistic paths.
The cost that surprises people is revalidation. An aerodynamics program might have been compared against wind tunnel data, flight tests and published benchmarks for thirty years. A rewrite, however elegant, starts with a track record of zero.
When a rewrite is justified, the safest approach is to replace one piece at a time. Pick a self-contained routine, rewrite it, run the old and new versions side by side on the same inputs, and only switch over once they agree within agreed tolerances. The Fortran 2003 C-interoperability feature makes this far easier, because old and new code can call each other during the transition.
What this means for founders and business teams
Fortran tends to land on a business owner's desk in a few predictable ways.
You're building a product on top of a simulation engine. Plenty of engineering software companies sell a modern web or desktop product whose core is a Fortran solver. That's a perfectly good architecture. Treat the Fortran engine as a component with a clear interface, and put automated tests at the boundary.
You've acquired or inherited Fortran code. Don't schedule an immediate rewrite. First find out what it does and who depends on its outputs. Documentation and tests are cheap compared with the cost of a mistaken engineering result. For teams in this spot, the question is Fortran still worth using for legacy scientific computing in 2027 usually has a plain answer: yes, at least until you've proven that something else does the job better.
You need to hire. Dedicated Fortran developers are scarce, but engineers with a physics or applied math background often pick up modern Fortran quickly, and many teams train strong C++ or Python developers on it. AI coding assistants help newcomers read old code faster, but their suggestions still need testing against known results.
You're starting a new project. Here the case for Fortran is weaker. Compare the Fortran alternatives 2027 offers against your team's skills, target hardware, reusable code, and whether you'll need to prove your results to a regulator or customer.
A few questions help sort out almost any Fortran decision:
• Does the current code produce results that people trust and use to make real decisions?
• Is there a test suite, and does anyone know what "correct" output looks like?
• Who can maintain it today, and who could maintain it in five years?
• Is it blocking something specific, such as GPUs, cloud deployment or integration?
• What would it cost to revalidate a replacement against real-world data?
Final word
So, is Fortran still relevant 2027? For general app development, not really, and nobody serious suggests building a mobile app or a website in it. For large numerical simulation, it's still very much alive. It runs the forecast models that national weather services depend on, much of the design analysis behind aircraft and spacecraft, and a large share of the research codes that fill the world's supercomputers.
The reasons are practical. The language keeps getting updated, the compilers are maintained, and the existing programs carry decades of validation that no rewrite can copy overnight. The weaknesses are real too: a thin hiring pool, poorly documented old code, and edge cases that catch newcomers.
For anyone asking is Fortran still worth using for legacy scientific computing in 2027, the answer in most cases is yes, provided you treat it as a living codebase. Add tests, document what you learn, put modern interfaces around it, and replace pieces only when you can prove the replacement is at least as good.
