Ask someone outside scientific computing what's happening with Fortran and the honest answer is usually some version of "nothing, it's frozen." That assumption doesn't survive five minutes of looking at what's actually landing in Fortran's own GitHub organizations this year. A community-built package manager with real, measurable adoption. A second Fortran compiler being written from scratch, not forked from gfortran, with its own interactive REPL and Jupyter kernel. Libraries that bind Fortran code directly to PyTorch. And, on the language's own public discussion board, a working scientist casually describing how he spent a weekend porting a C quantum-chemistry library into Fortran because he wanted to, not because a modernization vendor told him to. None of that is what "legacy language" usually implies. This is what active tool-building looks like, and unlike most claims about a programming language's health, every fact below is dated and independently checkable.
The package manager a "dead" language shouldn't need
For most of Fortran's history, there was no standard way to declare a dependency, pull it down, and build it, the way Cargo does for Rust or pip does for Python. Every shop rolled its own Makefiles, or vendored the code it needed directly into the project. fpm, the Fortran Package Manager, exists specifically to close that gap, and it's not a vendor product or an academic prototype: it's a community-run, MIT-licensed tool built under the fortran-lang GitHub organization.
None of those numbers make fpm a top-tier package manager by the standards of npm or crates.io, and nobody involved with it would claim otherwise. What they do establish is that this is not an abandoned side project: 274 open issues is a sign of a tool with active users filing real problems, not a tool nobody touches. A community that spends six decades without a package manager and then builds one, keeps shipping commits to it, and keeps arguing about its issue tracker in year six of its existence is not a community managing decline. It's a community doing ordinary open-source maintenance on infrastructure it decided it needed.
It's worth being honest about why that infrastructure took so long to show up in the first place. Fortran's scientific-computing user base spent decades solving the dependency problem the way HPC shops usually do: vendor-supplied module systems on shared clusters, hand-maintained build scripts, and code that vendored its dependencies directly into the source tree rather than fetching them at build time. That approach works, and a lot of production HPC code still uses it today. fpm doesn't replace that world, it sits alongside it, aimed specifically at the smaller libraries, personal projects, and cross-project collaboration that the older model was never built for.
A compiler being written from zero, with a Jupyter kernel attached
Writing a new Fortran compiler in 2026 is a strange thing to do if you think the language has no future. LFortran is exactly that: an LLVM-based Fortran compiler built from scratch by Ondřej Čertík and a team of collaborators, not a fork or a wrapper around gfortran's existing front end. Its own GitHub topics describe features that have nothing to do with maintaining old code: an interactive REPL, a Jupyter kernel, notebook support. That's not tooling aimed at a bank running a 1980s actuarial model. That's tooling aimed at someone who wants to explore Fortran the way a data scientist explores Python in a notebook.
A compiler backlog of over two thousand open issues sounds alarming out of context, but read correctly it's the opposite: it's the natural footprint of an enormous, still-unfinished engineering effort with people actively finding and reporting where it falls short of full standards conformance. Nobody files 2,373 issues against software they've stopped using.
What the compiler's own maintainer said, in public, this year
In August 2026, a Fortran Discourse thread titled "Ported a C code to Fortran, etiquette around it?" gave a small, concrete window into how this ecosystem actually works day to day. A user going by jorgeg had spent a weekend, with help from an AI coding assistant, converting libcint, a C quantum-chemistry library for computing molecular integrals, into Fortran, purely as a performance experiment for his own research. His result wasn't a clean performance win for Fortran: he reported the opposite.
“As of now, performance seems to get a 5-8% penalty compared to C and I have narrowed it down to the Fortran compiler generating a couple more instructions than the C compiler. I've verified this across gfortran and ifx.”
jorgeg, on porting the libcint quantum-chemistry library to Fortran, Fortran Discourse
That honesty is worth pausing on. This isn't a case study engineered to flatter Fortran; it's a real practitioner reporting a real, unresolved codegen difference between two production compilers, in public, without spin. What happened next is the more interesting part. Čertík, LFortran's own founder, replied directly, first with genuine enthusiasm for the port, then with real open-source process: how to attribute the original Apache-2.0-licensed C library correctly, whether the port belonged in its own repository, and an open invitation to feed the new Fortran code into LFortran itself.
“Once you are ready, send the code over and let's fix LFortran to compile it. And then later, once we are in beta, to also optimize it well.”
certik (Ondřej Čertík), replying in the same libcint-port thread, Fortran Discourse
A maintainer treating a hobbyist's weekend port as free compiler test coverage, and a licensing conversation happening carefully and correctly in public rather than being ignored, are both signs of a functioning open-source project with real process maturity, not a hobby forum with a handful of stragglers. jorgeg pushed the finished port to GitHub under the name Libfint within the hour.
The thread didn't stop there, either. Another user, jsjie, immediately asked whether jorgeg planned to do the same thing to libint2, a second, harder Gaussian-integral library written in C++ against the Boost libraries. jorgeg's answer is worth quoting for how ordinary it sounds, which is exactly the point: this isn't a grand modernization crusade, it's a hobbyist deciding what to do with his vacation time.
“Depends on my level of masochism if I'd do this. Libint shouldn't be too hard because it does rely on their compiler so in theory it should just be making sure it emits Fortran instead of C++... I'm taking 3 weeks off work later this year so I'll have time to do hobby stuff…so keep your eyes open!”
jorgeg, on a possible follow-up port of libint2, Fortran Discourse
That's a genuinely different picture of who writes new Fortran in 2026 than the one most people carry around. It isn't only a mainframe-adjacent maintenance programmer keeping a forty-year-old model running under duress. It's also, in the same week, on the same public forum, a quantum chemist treating a from-scratch Fortran port of a C library as a reasonable way to spend a long weekend and some vacation days, with an AI coding assistant doing some of the typing and a compiler's own founder cheering it on.
Scientists are wiring Fortran straight into PyTorch
The same week, a different thread on the same forum, titled "Using PyTorch in Fortran, which package to choose?", showed a second, unrelated axis of new development: machine learning bolted directly onto existing Fortran codebases, not replacing them. A researcher named Albert asked which library to use for adding ML routines to an existing Fortran project. The answer came from Joe Wallwork, a developer of one of the libraries in question, laying out the actual landscape rather than a sales pitch.
“A group of developers of such packages including myself, Milan, and the authors of TorchFort are currently working on a comparison study that will hopefully give some helpful insight on this issue.”
jwallwork23 (Joe Wallwork), on Fortran-PyTorch integration libraries, Fortran Discourse
Wallwork's answer described three genuinely distinct approaches now available: FTorch and TorchFort, which bind directly to PyTorch's C++ libtorch backend for full training and inference functionality; ENNUF and SmartSim, more general interfacing layers that support multiple ML backends but are limited in scope; and neural-fortran and Fiats, pure-Fortran implementations with no external dependencies at all, giving a project full control without leaving the language. He went further and matched specific tools to specific use cases from firsthand experience: TorchFort for reinforcement-learning workloads, FTorch when the target hardware isn't Nvidia, ENNUF for quickly deploying a small one-dimensional model, and the pure-Fortran path for teams that want to stay inside a single language's build system entirely. That's not a marketing comparison chart, it's a working developer describing tradeoffs he's actually hit.
neural-fortran, the pure-Fortran option Wallwork mentioned, is its own data point: created in 2018, still actively maintained under the modern-fortran GitHub organization, described plainly in its own repository as "a parallel framework for deep learning," and carrying 474 stars and 108 forks as of this writing. It started as the basis for a book on modern Fortran by its creator, Milan Curcic, and has since picked up outside contributors who treat it as shared infrastructure rather than a personal project. None of this reads like a community managing an exit. It reads like one actively deciding what its next decade of tooling should look like, and building it.
Put the four threads together and a pattern emerges that's easy to miss if you only ever encounter Fortran through a thirty-year-old solver's crash log. A package manager most languages take for granted didn't exist here until 2020, and it's being used and argued over now. A second, independent compiler implementation is being built from the ground up specifically to support interactive and educational use cases nobody needed forty years ago. And the people asking questions about all of it, in public, this year, are quantum chemists and climate scientists wiring modern machine-learning tooling into codebases they have no intention of abandoning. That's not what active decline looks like from the inside.
Where this leaves you
- fpm gives Fortran something it never had in six decades of existence: a standard, actively maintained way to declare and build dependencies, and its issue tracker shows real ongoing use, not abandonment.
- LFortran is a full, independent Fortran compiler built from scratch with an interactive REPL and Jupyter kernel, aimed at exploratory and educational use as much as production builds — a second implementation only gets built for a language people expect to keep using.
- The community's own forum shows real practitioners porting other languages into Fortran by choice in 2026, not away from it, with functioning open-source norms around licensing and attribution when they do.
- FTorch, TorchFort, neural-fortran, and similar libraries mean current Fortran codebases can add machine learning without leaving the language, a genuinely new capability that didn't exist a decade ago.
- None of this contradicts the fact that most Fortran in production is old; it means the newest work being done on the language itself is healthier and more active than its reputation suggests.