First year of Fortran-lang

Last week marked one year since the birth of the Fortran-lang open source community. A lot has happened and many of us who have participated agree that the progress exceeded our highest expectations. After two decades of a cold and desolate Fortran winter, are we approaching a new golden era of Fortran? We just may have a chance.

This is the story of the first year of the Fortran-lang community.

Conception

I went back to the earliest seed that I could find — a short and to-the-point article from August 2019 by the orbital mechanic and Fortran programmer Jacob Williams:

Jacob pointed out several key things that have been lacking or just plain harmful to Fortran: No website for new users to learn about the language and connect with others; opaque standards committee that is disconnected from end users; archaic collaboration practices that result in glacial pace of the language development. This passage especially resonated with me:

The slowness of the language development process, the refusal to adopt modern practices of collaboration, and the refusal to address major shortcomings of the language has allowed other languages to overtake Fortran in the fields it was once dominant. In fields such as machine learning, one of the major computational activities of modern times, there is no significant presence of Fortran. The committee has given us incremental, somewhat half-baked features that don’t really solve real-world problems in any kind of satisfactory manner (like ISO_VARYING_STRING, parameterized derived types, user-defined IO, floating point exceptions). While shortcomings from decades ago are left unaddressed (lack of a useful mechanism for generic programming, lack of access to the file system, no intrinsic high-level classes for dynamic structures such as stacks and queues, no useful varying string class, a non-standard module file format that is a constant source of annoyance for both users and library developers, even the lack of a standardized file extension for Fortran, which leads to nonsense like .f90, .f03, .f08, .f18? being used).

Discussion ensued about what could we do to help fix it. This was where Ondřej Čertík of the SymPy fame, and a member of the Fortran Standards Committee, reached out and invited us to join.

Before this I only knew about Ondřej from his work, but we hadn’t met. I thought that this could be the turning point — increasingly more Fortran users have been raising concerns about the state of the language and its ecosystem, and new blood has been joining the Standards Committee. I knew of many other Fortran programmers — whether from GitHub, Stack Overflow, or comp.lang.fortran — but we were all disconnected, doing our own thing, reinventing the wheel. And here we were now, discussing the issues and what we could do to fix them.

In my view a dedicated and modern Fortran website has been sorely lacking, to the point that back in 2018 I went ahead and registered the fortran-lang.org domain. I didn’t know who was going to make the website or when, but I believed it would happen. Save for a few free curated resources like FortranWiki and fortran90.org, Fortran on the internet has been very much like the Wild West — an occasional saloon here and a decrepit church there, with a whole lot of tumbleweed in between. Prospective Fortran users search for help and struggle. Where do I get a Fortran compiler? How do I build and link Fortran programs? How do I include this library in my package? And where are all the tools that other languages have? Many walk away never to come back. Fortran needs every user it can get.

Things got quiet for a few months, but these thoughts kept simmering in the backs of our minds. The message I got then was that there were ambitious people out there willing to fight for Fortran and its future.

Fortran Standard proposals on GitHub

A few months later, this came from Ondřej:

More important was the new GitHub repo that Ondřej linked to in the Twitter thread:

j3-fortran/fortran_proposals

where he started tracking existing Fortran proposals to the Standards Committee, as well as requests from the broader community, as GitHub issues.

For the first time end users could publicly suggest, discuss, and even write proposals to the Standards Committee. While technically speaking this was possible before, the process was obscure to the level that you had to “know a guy who knows a guy” to provide feedback to the Committee. The Fortran proposals repository streamlined and made this process transparent. Here’s an example of how well it works:

1. Michael Zingale suggested on Twitter to introduce namespaces for Fortran modules.
2. Ondřej opened an issue to track this idea and wrote a short proposal as a Pull Request to discuss at the October Committee meeting that same week.
3. The committee reviewed and discussed the proposal. Many people from the broader community continued to discuss various ideas about the syntax and semantics that this feature could have. The proposal was later revised in another PR and reviewed again in the February 2020 meeting.
4. The feature is a candidate for Fortran 202y (the one after 202x).

This process is effective. It doesn’t at all change how the Committee works, and it adds a layer of idea solicitation, feedback, and curation before the Committee formally discusses it in meetings and/or mailing lists. The community is now part of the process. To my pleasant surprise, even one of my suggestions — default values for optional dummy arguments — got discussed, written up as a formal proposal, and evaluated at the February meeting. This one is also a candidate for inclusion in Fortran 202y. The process works.

The proposals repository also had prominent members of the Committee actively engaged, including the then WG5 Chair Steve Lionel (a.k.a Dr. Fortran), Bill Long from Cray/HPE, Tom Clune from NASA, Gary Klimowicz and Peter Klausler from Nvidia, Damian Rouson from the Sourcery Institute, and others. Ideally, most Committee members would eventually participate in the GitHub discussions.

Since its inception, this repository has fostered 164 discussion threads from 73 people, resulting in several proposal papers submitted and discussed by the Committee. This is a tremendous success in my book. Kudos to Ondřej for starting and pushing the repo forward and everybody else who contributed.

Standard Library

It occurred to me early on that many proposal issues in the j3-fortran/fortran_proposals repository asked for new intrinsics (an intrinsic is a built-in procedure, module, or derived type in Fortran lingo). Most of them would provide functionality that’s commonly found in standard libraries of other languages. Under the traditional Fortran development model, the new feature is proposed, discussed, and approved by the Standards Committee and specified in the Standard (a several years-long process), then implemented in the compilers (a few years-long process), and only after the users update their compilers are they able to use the new features. The whole journey from idea about an intrinsic to its application in the end-user code can easily take 10+ years.

I thought, why don’t we implement these procedures ourselves and provide a testbed to prototype and play with future intrinsics before they’re formalized in the Standard? After all, many usability issues are more easily discovered by actually using the function, rather than by reading its spec. Plus, it would provide a space for people to discuss and collaborate on commonly used general-purpose facilities that are being re-written over and over again. So I opened an issue to read the temperature of the room. The response was warm and encouraging. People were excited to collaborate on such project and agreed to proceed and develop the Fortran Standard Library, or stdlib in short. Stdlib was the first repo of the Fortran-lang GitHub organization — in a way, it broke the ice for several other Fortran projects to come in the following months.

fortran-lang/stdlib

What’s in stdlib so far:

• ascii module with 16 procedures to work with the ASCII character set.
• bitsets module with a derived type and procedures to work with bitsets.
• error module with the check procedure for checking logical conditions.
• io module with convenience subroutines loadtxt, savetxt, and open.
• kinds module which provides constants for different integer and real type kinds.
• linalg module with procedures for linear algebra. For now it provides diag, eye, and trace functions.
• logger module with a derived type and procedures for logging general, warning, and error messages.
• optval module which provides a convenience function optval for working with optional dummy arguments.
• quadrature module to integrate functions using trapezoidal or Simpson’s rule.
• stats module with functions to compute correlation, covariance, mean, moment, and variance of arrays of any rank.
• system module that currently provides the sleep subroutine.

All this and more — documentation, continuous integration, code reviews — is the result of the hard work of over 20 direct contributors. We also presented it at FortranCon 2020. Here’s the recording of the presentation by Jérémie Vandenplas, one of the core stdlib developers:

Fortran stdlib at FortranCon2020 by Jérémie Vandenplas

Please check out stdlib if you haven’t yet. We need help across all aspects of the project, be it with improving the documentation, testing, implementation, or just ideas and discussion.

Fortran Package Manager

The stdlib repository quickly proved to be an incubator for innovative ideas to improve the Fortran ecosystem. Only 9 days since the creation of the repository, Dominik Gronkiewicz opened an issue about a packaging ecosystem experiment. We discussed and agreed that there was a real need for a dedicated and Fortran-specific package manager and build system, with the key goal to improve user experience. If such tool became mainstream among Fortran developers, it would have an opportunity to completely revitalize the Fortran ecosystem of libraries and applications.

On January 14 — only a month after we started the Fortran-lang Org and the stdlib repository — Ondřej created the repository for the Fortran Package Manager, a.k.a fpm:

fortran-lang/fpm

We discussed what would be the best language to implement fpm and agreed on the following requirements:

• The language must have mature utilities for file system operations and networking. This at least initially disqualified Fortran as the implementation language.
• The language implementation must have a compiler that could produce a static executable with fast start-up. This disqualified Python as the implementation language.
• The language would have to be either well known or at least somewhat familiar and easy to learn for existing Fortran programmers. On this point we considered C++, Go, and Rust as potential candidates.

Ondřej was already proficient with C++ and both of us were interested in learning Rust, so Ondřej went ahead and put together a minimal Rust prototype that built a simple Fortran program and library. It was at this time that we started studying Cargo (Rust’s package manager) in more detail and quickly fell in love with its UX.

However, development soon proved to be difficult. Rust has a steep learning curve and Ondřej was already busy with LFortran, j3-fortran/fortran_proposals, and stdlib. Other developers, myself included, weren’t so quick to pick up Rust and help out. We were fortunate that around this time, Brad Richardson got more engaged in Fortran-lang discussions and proposed that he pushes the fpm prototype forward. The plan was for Brad to lead a Haskell implementation of fpm, quickly get to something usable that we can all play and experiment with, and develop a specification for fpm’s functionality and UI. We recognized early on that Haskell, despite being a powerful language, wasn’t viable for fpm in the long-term because of its steep learning curve and the lack of Haskell programmers in the Fortran community. Once we learned enough from the prototype, we’d evaluate the languages again and re-implement fpm for production in the optimal language.

Here’s Brad’s fpm talk from FortranCon 2020:

fpm at FortranCon 2020 by Brad Richardson

By May, the Haskell fpm was mature enough that you could build Fortran projects of arbitrary complexity (as long as they conformed to fpm’s layout convention), including remote dependencies, with fpm build, run the executables with fpm run, test with fpm test, and create a new package with fpm new — just like with Cargo. We could finally experience the magic of creating, building, and running a Fortran package with dependencies using only a few commands. It worked. And the heavy weight of development was pulled by Brad alone, with only gentle steering by Ondřej, myself, and several others.

It was time to ask the question again — what language should we implement the production fpm in, now that we had a better idea about its spec? Ondřej wrote to me and Brad and proposed that it should be Fortran:

I would like to propose to actually use Fortran to implement the production version of fpm. It sounds crazy at first, but if you think about it, it makes perfect sense:

* Compiled, statically typed
* Quick start, single executable distribution
* Mainstream (in our community!)
* Easy to install fpm from source (because we will use fpm to build fpm!)
* Using this language has compounding positive effects on other Fortran projects and/or fortran-lang

The only thing that Fortran is missing is mature libraries and tooling so that we can work with processes, file system, networking, TOML file reading, command line options handling, etc.

However, we are trying to fix this, so we might as well fix it while building fpm.

Brad and I were on board and shortly after we discussed this with the broader community. It was received with excitement. Fast-forward a few months and the Fortran fpm already implements most of the Haskell fpm functionality (and some others that Haskell fpm doesn’t), and the first binary releases for Linux, macOS, and Windows started rolling out in November.

In retrospect, it was serendipitous that we chose TOML as the configuration file format for fpm. When we looked for a Fortran TOML parser, we found toml-f. It just happened so that its author, Sebastian Ehlert, got excited about fpm and is now a core developer on the project.

While stdlib is essential for Fortran’s ease of use and general-purpose programming, fpm just may be the most exciting thing to happen for Fortran’s ecosystem and community right now. Creating, building, testing, and running a Fortran package has never been easier. I’m excited to see it evolve and change how Fortran programmers work on a daily basis.

Have you tried fpm yet? What are you waiting for? Grab a binary release now and take it for a spin.

fortran-lang.org

We recognized early on that the lack of a clean, modern, and maintained website is a serious impediment to Fortran’s user adoption and retention. I already owned the domain name and it was just a matter of putting together something half decent-looking to start with. In early April I took a Saturday afternoon to put together a basic, static Jekyll website, largely adapted from the Neovim website:

Home - Fortran Programming Language

While initially just a landing page with a few other placeholder pages, the website quickly grew with the help of over 29 direct contributors to date. Laurence Kedward came in and made it better looking, more responsive, and easier to build content. Many others jumped in to write tutorials and other resources. The website now features a list of all active open source and commercial Fortran compilers, a few in-depth tutorials (mini-books) aimed at novice Fortran programmers, a Fortran package index, a monthly newsletter, and more. A modern looking, responsive, and helpful website is essential for Fortran’s well-being — a prospective user looking for Fortran resources should be able to find everything they need in one place.

And the content has indeed been both relevant and useful — it’s been eight months since we started fortran-lang.org and it’s already near the top result for the word “fortran” in all popular search engines. #1 is within reach and only a matter of time.

The logo I adapted from Jacob by changing the color from punchcard brown (nobody’s favorite color) to some shade of purple (my favorite color). I originally thought of it as a placeholder logo until we come up with something better looking, but people seem to like it so it stuck. The font originates from the front cover of the original IBM FORTRAN manual for the 704 computer.

Another important element for nurturing a healthy, inclusive open source community is a friendly and moderated discussion board. In May we applied for a free Discourse instance, which has been increasingly more active every week. Since May, the Fortran Discourse has grown to 147 users and 1.8K posts. If you haven’t seen it yet, please check it out and join the conversations.

Fortran Discourse

For people who prefer communication by email, there’s also the mailing list, although so far it’s been used mostly for news and announcements.

Finally, there are also monthly video calls where we get together and discuss the current issues and next steps forward. We typically have 10–20 people on the call, and it’s always fun and engaging. These calls are the highlights of the day for me.

To wrap up, I want to thank everybody who made Fortran-lang such an open, friendly, and productive community:

Fortran-lang Community

You all made this. 👏

My takeaways

• Though only a year old, Fortran-lang was years in the making. It took Fortran to hit rock bottom for people to mobilize and start building new infrastructure.
• There’s an incredible amount of untapped energy and enthusiasm among Fortran programmers. But something needed to connect them and provide a place for them to work toward common goals and channel that energy.
• Fortran proposals repository on GitHub will be essential for more efficient language development, and should help accelerate the release of future Fortran Standard revisions. It will also help align future Fortran standards with end-user interests.
• Once mature, stdlib and fpm should make Fortran programming easier, more fun, and more effective. They will also help nurture and grow Fortran’s ecosystem of libraries and applications.
• I’m impressed by how much work has been done in the past year, but I’m more impressed with how many friendly, kind, and patient people there are in the Fortran community. They give me faith that Fortran will experience the revival that it deserves.

Thanks to Jacob Williams, Ondřej Čertík, Jérémie Vandenplas, Ivan Pribec, Brad Richardson, Sebastian Ehlert, and Laurence Kedward who helped improve this article.