Why abandon Fortran for Linear Algebra?

When I first heard about rust and decided to dive into it, I almost immediately found very detailed books for free in the internet. But most important I knew where to start: They have one book (nicknamed “the book”) which is highly recommended, available online and offline for free.
If I search for “learn fortran” and navigate to fortran-lang.org I get a crash course and mini-books (which is nice), but no single book which will explain everything in detail (alike “the book”). Instead I get a list of over 50 links to all varieties of books, courses and topics which seam to be a little bit overwhelming (and untidy).
In my opinion quality is more important than quantity.
Therefore, it may be better to established “the book” for Fortran, which explains everything about modern Fortran in detail for free and with the option for the whole community to contribute. We don’t need many books as long as one book covers everything important in a comprehensive way.


I’d add: cheap, modern texts on Fortran for applied science. It shouldn’t be about “Fortran”, but “Computational X with Modern Fortran” where X could be: physics, chemistry, biology, etc.

Dover Publications – an entity with a strong catalogue of scientific materials of both historic and current interest, might be worth approaching.

Also – materials for high school through undergraduate instructors would be critical in reviving the ecosystem.


There are books on “Computational X with Matlab” for all X. Matlab and modern Fortran are similar languages, and there are partial translators matlab2fortran and matlab2fmex. There is also Mc2FOR: A tool for automatically translating MATLAB to FORTRAN 95 (2014). Back in 1996 there was a paper A MATLAB to Fortran 90 Translator and its Effectiveness. I don’t use Matlab and have not tried these tools, but the existence of a translator that did 99% of the work would open up many algorithms to Fortran.

Fortran is not going to be the first programming language, or even the first scientific programming language for most people, but it should be easy to transition to it.


Excellent, excellent point. Thank you @certik for explaining it so clearly.

Re: “What else?”: feature gaps in Fortran language.

The ground reality is for year 2021, the base language Fortran is feature deficient.

From simple convenience (but powerful features) such as proper enumeration type support and unsigned integers and bitset types to proper exception handling and comprehensive generic metaprogramming facilities, most budget managers will not sign off on a decision to use Fortran for any part of a significant commercial software endeavor involving many code contributors, cross-functional teams, multilanguage and multiple programming paradigms with goals toward speed-to-market and so forth.

With each of above features, one is looking at 20+ years before robust language support becomes even conceivable e.g., some generics feature (possibly diluted even relative to 1990s Ada or C++98) may go into 202Y and reasonable compiler support may come around 2035 to 2040. That’s way too late. No manager in the commercial sector will be willing to wait a quarter for their decision, especially considering so many other better-featured language options on offer with so many highly skilled and motivated people working to elevate those languages.

The computational technology lead architects and budget managers and peers laugh at me that Fortran 202X will not allow something simple like assigning values to Fortran enumerators when a programmer so desires, something every modern language including Julia provides simply as a matter of fact: “@enum Fruit apple=1 orange=2 kiwi=3”

Not acknowledging and addressing the feature deficiency is also a big problem in Fortran: simple, basic things needed toward modern applications get in way too late, often with little comprehensiveness for the practitioners. Every little thing becomes such heavy-lifting in Fortran.

So I remain extremely dismayed and saddened by the lack of recognition and acceptance and addressal by the dozen or two active Fortran practitioners posting online (e.g., here) as those with voting power (e.g., Fortran language committees) on the gaps in the base language itself.

Decisions like the one in the original post have been dime a dozen over the last 2 decades and the few remaining codebases of any significance will soon migrate away from Fortran.


I presume there is a way to call fortran code to speed up Matlab calculations. Is this documented anywhere?

Yes, Fortran Source MEX Files. The matlab2fmex tool I mentioned earlier translates Matlab code to Fortran so that the Fortran can be compiled to a MEX file. MathWorks would prefer that your code stays in Matlab:

MEX files are not appropriate for all applications. MATLAB is a high-productivity environment whose specialty is eliminating time-consuming, low-level programming in compiled languages like Fortran. In general, do your programming in MATLAB. Do not use MEX files unless your application requires it.

I remember that when a Matlab salesman visited my company in the late 1990s, he presented Matlab array operations and said that in Fortran you would have to write loops. That’s what the company had told him. There was an awkward silence when I interjected that Fortran 90 had array operations.

1 Like

Would it be helpful if NAG made more noise about how we produce Libraries for C, C++, Fortran, Python, Java, Matlab and .NET out of 126k LOC of C++ and 2284k LOC of Fortran? Sometimes it seems that people are not aware of the possibilities.

In the short term, I agree, but there should be a long term goal of introducing programming as a way of problem solving. Fortran is good for the numerical aspect, but other languages are currently preferable for the symbolic. This corresponds to the distinction between declarative knowledge and procedural knowledge made in logic programming (of which I am a fan of).

Matthias Felleisen (invenor of Racket and the How to Design Programs curriculum) has given much thought on:

  1. The need for multiple languages in a project
  2. The need to integrate computing science into the broader approach to mathematics education.

Worth reading:

  1. Felleisen, M, Krishnamurthi, S (2009) Why Computer Science Doesn’t Matter (pdf)
  2. Felleisen on Programming Languages (link)
  3. Developing Developers: (link)
1 Like

I love Fortran and want it to be the best tool in its target market.

At the same time, if people are moving away from Fortran for well informed technical reasons, I think they should.

If people are moving away from Fortran for well informed social reasons, such as difficult to hire, I think they should.

If people are moving away from Fortran because they’re misinformed, then I will try to convince to change their mind, and we all should.

At the same time, we all need to work hard to improve numerous aspects of Fortran and its compilers, libraries, tooling, community, marketing, and yes, public relations, so that good technical reasons to move away shrink, and perhaps even completely disappear, and that bad social reasons go away. I don’t want tools and libraries to be built in Fortran just because of Fortran. I want them to be built with the best tool for the job.

If BALLISTIC brings an improved linear algebra system over the current state-of-the-art, in a different language, I’m all for it. It’s not like we’ll lose the Fortran implementations, and people will choose. And the BALLISTIC paper promises standard-conforming Fortran bindings. As an end-user of linear algebra, I want the most stable, performant, portable, and easy-to-use library or framework. I don’t care what’s running under the hood. If it’s Fortran, fantastic. If it’s something else, I doesn’t offend me.

I do worry, however, about these shifts affecting the availability of Fortran programmers, which could (and probably has, a while ago) entered a positive feedback cycle: Fewer large Fortran projects → fewer Fortran programmers → more difficult to hire → even fewer larger Fortran projects.

I agree that the lack of university Fortran courses (in the US, at least) is a problem. However, as @certik pointed out, we can’t fix this in the short term. These trends have a time scale of about one generation, ~30 years. Even if we start reversing this now, it will be decades to reach a favorable level of college-level Fortran courses. Within that time frame, universities may become mostly obsolete, or there may be a new programming language that would make most other languages completely redundant. We live in exponential times.

Speaking specifically about the problem of Fortran at the universities, here’s what we can do (we who work at universities):

  • Organize periodic Fortran seminars
  • Organize local discussion or reading groups
  • Teach a day-long Fortran workshop (free of charge, of course. Tip: bring snacks and drinks for higher attendance). It’s great experience if you consider doing more teaching.
  • Reach out to the university-wide mail list and say you’re a local Fortran expert (yes, if you don’t feel like one, you are), and invite anybody who programs Fortran to ask you for help at any time. There may be Fortran programmers around that you’re not aware of.
  • Write blogs and articles about Fortran
  • Talk about and promote Fortran

Like with most systemic problems, this one we need to address locally, from the bottom up, each of us.


Worth remembering that it is only the reference implementation of Sca/LAPACK that is in (very naughty) Fortran. You would have to ask each vendor if they substituted other source codes. At least now I know why they have never bothered to fix the non-conformances in those reference Fortran codes.

One more for the pile of concerns: How easy is it to contribute to code-generation improvement for a Fortran compiler? I expect the LLVM folks will make a dent on that, I hope flang is not hitting big problems.


I have written a Fortran package that interoperates with MATLAB both serially and in parallel (via MPI). As @Beliavsky mentioned, all MATLAB interoperations with C/Fortran are done via MeX files. Unfortunately, the Fortran MEX API is too archaic relying almost exclusively on FORTRAN77. Fortunately, Fortran/C interoperability resolves the issue and you can interoperate with MATLAB as if the Fortran code is C. If you need more help with the inner workings of the above package and the how-to of MATLAB-Fortran interoperation, I would be happy to direct you to more specific details. Keep in mind that MATLAB Mex API changes without any notice. The Fortran/Mex binary interface that you generate may work with one MATLAB version, but not with the next. Currently, I am sure at least MATLAB 2018a and 2018b have incompatible APIs (meaning you will have to compile your code separately for these two).

A lot has been said about Fortran compilers capabilities on this forum recently. On the positive side, I can attest that the package that we wrote in Fortran is orders of magnitude faster than the equivalent that we wrote in pure MATLAB.

1 Like

I agree with @pmk above. I’ve been a member of the committee for about 2 years, so I am now partly responsible for this failure myself. If anybody has any ideas what I and others can do differently at the committee, please let us know. One way to contribute is to have a solid plan how to implement generics in Fortran. Anybody can join our effort here: GitHub - j3-fortran/generics. @pmk, if you have spare cycles, you can prototype some of the proposals in Flang, or even create your own “generics” that you think we should do. That would be a huge help. I plan to prototype them in LFortran also after we deliver MVP.

The same with macros, the best thing is to simply prototype this in a compiler and let people play with it.

One reason is that commerial Fortran vendors do not understand that by not making their compilers available for the community they are killing the language. Probably because they don’t understand open source, or they think it’s irrelevant.

One example: I spent some time on trying to make scipy, a very popular scientific Python package, which uses several Fortran libraries, not only Lapack, be useful with the NAG’s nagfor compiler.

I spent some time expaining to NAG people why they should provide few nagfor licences to scipy for testing purposes. (I tried to find Fortran reviewers for these little changes in Fortran code there - please, have a look if you have time).

No, nothing has happened on the NAG side. Probably NAG thinks it’s irrelevant to their shareholders. Good luck to them with keeping profitable with their shrinking range of customers then.

1 Like

The situation with NAG is I think a bit different from others (like Intel that is a major chipmaker, or NVIDIA). But perhaps they could make it free to the open-source developers (which would be extremely valuable to the community). Even Intel made its compilers free when Apple announced they would be moving away from Intel chip. I do not know for sure if the two events are truly connected. But the coincidence makes people like me wonder.

1 Like

Compilers are difficult to write, and I think their developers deserve to be paid. I have paid for compilers from Microsoft, Digital, Compaq, Lahey, and Unicomp (for F) and think it was money well spent. The NAG site says

As a not-for-profit company, NAG reinvests surpluses into the research and development of its products, services, staff and its collaborations.

1 Like

@dimpase thank you for the comment and welcome! Maybe @themos can comment on the NAG situation, I don’t know what is best for them or their policies.

The situation of the Fortran compilers is complicated by the history, that 30 years ago it was profitable to sell compilers, but things have changed since then and now it seems one has to either do open source or be attached to a hardware company. Either way, the Fortran compilers should adapt to the new economy. I think they are, but it takes time.

Thank you again for the feedback!

I have not said they NAG or any other commercial vendor should open-source their compiler! What I said they fail to acknowledge that Python packages such as scipy is by far the largest install base of Fortran libraries, and fail to do anything to let their products be used in that largest Fortran market segment. It’s pathetic shortsightedness.

What have they lost by not providing few licences for free? Nothing, to the contrary, it only makes Python people more convinced that Fortran is dying, and less Fortran will be used in Python packages, no more. That was a unique moment when NAG’s Fortran was the only Fortran compiler capable of natively working on Apple’s M1 Arm architecture. Surely gfortran have caught up there, or it will, soon.

So they didn’t sell their licences to M1 users who wanted to build scipy natively on M1 using nagfor, because scipy was not and still is not ported to nagfor. Why on Earth do I have to teach NAG elementary marketing, are they blind, or still think that Python will magically go away and leave them in command of scientific computing market?


I agree. Please make sure you upvote this issue:

Consider releasing Fortran standard every 3 years instead of 5 · Issue #36 · j3-fortran/fortran_proposals · GitHub

I agree and I would even turn the reasoning around: compilers should be driving the development of the language, by implementing various extensions and the Fortran Standards Committee should standardize things that are already in use. I believe new features should not be by default invented by the committee, because it is extremely hard to do it right without a prior compiler implementation and user experience. Ideally it would be some kind of a compromise: the committee can suggest new features, compilers implement them, we get experience with them, and later on the committee can standardize.


I understand the logic, but an advantage of Fortran being standardized is that you are not tied to a compiler. At times I used F, ELF90, Lahey/Fujitsu F95, and g95. None of those compilers are currently maintained, but since I did not use extensions my codes still work with gfortran and Intel. If you are unable to compile a FORTRAN code from 1970, it’s because it used an extension that seemed like a good idea at the time. When do the benefits of compiler extensions exceed the drawbacks of code potentially being stranded if those extensions do not enter the standard, and the compiler stops being maintained?