Reasons why Fortran is still used (2021) | Hacker News Reader

Reasons why Fortran is still used (2021)

matecdev.com

119 pointsngcc_hk72 comments

I have recently went through Fortran from zero to all advanced features. My take is the following.

The language is verbose but pleasant to work with. The latest 2008 version is really nice to look at. My assumption is that working with Fortran 77 and earlier isn’t going to be do nice. With modern Fortran, it’s possible to write generic code, operators can be overridden, new operators can be defined, derived types support inheritance. The language supports pure functions and subroutines verified by the compiler. Programs compile to native binaries.

On the other hand, numbers overflow and there’s no support for any networking without c interop, no byte arrays.

The language shines for multi-dimensional data. For example, multiply every array element by two: [10, 20, 45, 65] * 2. Or, multiply one array over another: [10, 30, 46, 32] * [100, 134, 32, 87]. Up to 15 dimensions are supported. Parallel computing: Fortran coarrays are a relatively simple mechanism to distribute work across CPUs, pin work to selected CPUs, and synchronize the computation across CPUs. Potentially thousands of them.

This makes Fortran a one trick pony. It does parallel multi-dimensional data very well, but that’s really where it ends.

A couple of notes on the ecosystem. The community has done a tremendous job at making Fortran easy. FPM is a package manager designed after cargo. It is really easy to import packages from remote locations, for example git branches. There are some really high quality packages out there, but the ecosystem is difficult to explore because there are no package catalogs. FPM website tries to change that. Editor support is awesome. There are extensions for many editors, language servers exist so code hints and syntax checking also works.

Would I choose Fortran for a new product today? If it had byte arrays, sockets and TLS available natively, maybe.

Fortran’s strengths with numbers, particularly multidimensional data and parallel computing, is partly why it’s still the go-to standard for crunching through weather modeling.

That's the point, Fortran today is a DSL for computational science, that's it and mainly what it focuses on today. It is not (if it ever was) a general programming language.

Remember C did not come out until 1972. So in the 1960s your primary options were Fortran, COBOL and assembly language (there were lots of other languages but they were relatively minor languages). Considering the major defects of assembly language there was a significant amount of use of Fortran as a general programming language in conjunction with various libraries.

Various LISPs were a major contender in those times, with various companies selling their own flavors. LISP was the major high-level programming language used for writing operating systems - before C, other OSs were basically written in assembler (though there was at least one written in COBOL, BLIS/COBOL, which seems to have been more or less contemporaneous with C's early life).

FORTRAN was always dedicated to scientific computing, I don't believe it was ever used for system software, so it is a bit apples-to-oranges.

> FORTRAN was always dedicated to scientific computing, I don't believe it was ever used for system software, so it is a bit apples-to-oranges.

Early versions of PRIMOS used FORTRAN as a systems programming language, although later versions switched to Prime's proprietary PL/I dialect (PL/P) and Modula 2.

The reason for the somewhat unusual choice of FORTRAN as a systems programming language? Prime's founders were experienced FORTRAN programmers, so it was the natural choice for them, and in 1972 alternatives were far less established (C was only just being invented)

I think PL/I has more of a claim to have been used for writing operating systems before C than Lisp.

I feel like in the history of software, "computational science," while now a niche was then one of the major users or computers in the early days in addition to business and then eventually, computer scientists. That way we (I am a computational physicist) were one of the major users of large computer systems as they replaced computers, that is, actual people who sat in a room manually computing things. It was only natural then in a certain sense one of the first high-level programming languages were suited for scientific applications like calculation and simulation.

I think since f90, modern fortran still is a language well suited to that domain while removing a lot of the cruft (like requiring each line fit on a punch card, things like that, ugh), although the landscape of computing has changed dramatically since with scientists now being relegated to being a niche of computing as a whole. So fortran in that sense is more like a DSL today rather than one of the major use cases for computers, but by luck and history has a lineage with literally the oldest high level language. This is thus more like a historical accident than being something contingent for me. I think the fact that it is suited to computational science is a result, not a cause of it being for scientists (it was designed for us, we didn't find it and build it up or something like that), and the strict aliasing, well, I feel like that's just a lucky break that it was and thus easily optimizable...that and cray, HP et al did make supercomputers to run codes that scientists liked, and thus their architecture and optimizations worked well with fortran codes, and thus the development of both are clearly a coupled situation here.

Anyway, when it comes to today, modern fortran is still a strong language for computational science, specifically for numerical things like simulation and numerical solution and things like that, so when I say, "it is a DSL for computational science today," that encapsulates my opinion succinctly without having to go into the ramble about history, although history is mostly why it is the case today.

I wouldn't consider Lisp, Algol-60 and PL/I dialects minor languages.

DSL = domain specific language, in this context

https://en.wikipedia.org/wiki/Domain-specific_language

> It is not (if it ever was) a general programming language.

Colossal Cave Adventure (ADVENT) was written in Fortran.

Zork (aka Dungeon) was originally written in an obscure Lisp dialect invented at MIT, MDL; but Bob Supnik at DEC ported it into Fortran, and that version became widely distributed.

I used to work for a university, where the software which determined whether students had met all their degree requirements to graduate (such software is sometimes called a "degree audit tool"), was written in Fortran. Why? Well, it was a manual paper-based process, then one of the academics kindly volunteered to automate it for them. And he was one of the mathematics lecturers, and Fortran was his favourite language, so that's what he did it in. Some years later he retired, and without him the software became increasingly difficult to maintain – the university no doubt had some Fortran programmers in the physics/maths/engineering/etc departments, but the central administration's IT didn't. They ended up replacing it with some commercial off-the-shelf solution–no idea what that was written in, but almost certainly not Fortran.

First Prolog was written in Fortran.

The first Prolog was written in Algol-W. The second one, which was called Prolog I was written in Fortran. See comments for more: https://stackoverflow.com/a/4478969

Thank you, awesome.

Yes, I could see it being preferable or at least on the same level as Cobol and certainly better than using Assembly for programming text adventures, but surely that's just due to certain limitations of the times. Lisp came out like a year later (not sure how long until you could purchase a lisp machine) and is a much better general purpose language (some would claim it's still unsurpassed). Later we had things like APL, C, Pascal...etc and Fortran was left to numerical work.

All that to say I think Fortran can only claim to be what we call "general purpose" for a very limited window of time in the very early stages of computing.

> Lisp came out like a year later

In the early 1970s, almost every mainframe and minicomputer had a Fortran compiler available for it. Lisp was much rarer. Pascal had only just been invented and C was only just being invented. If you wanted your software to be as widely portable as possible, your choices were Fortran or Cobol, and no wonder why many preferred the former. (Especially if we are talking about software in academic/research environments, where Fortran was far more common than Cobol.)

This has little to do with Fortran and Lisp's respective years of introduction (1957 vs 1958), but rather how far they'd managed to spread in their first 15 years (almost everywhere for Fortran versus only to a narrow subset of academic research institutions for Lisp.)

> Fortran can only claim to be what we call "general purpose" for a very limited window of time in the very early stages of computing.

The timeframe in which Fortran saw “general purpose” use spanned at least a decade (maybe closer to two) and was after the “very early stages” (during which almost everything was in assembler - or even hand-assembled machine code - and portable code was basically unheard of)

10 years out of ~70ish total is a pretty limited window in my eyes. I guess that's all a little subjective. Thanks for the additional information though. I figured there was a little more choice in the 70s.

Are you saying that computational science boils down to parallel multiplication of arrays? That makes sense to me intuitively, but I’m just checking here.

Well, quite often yes. At least in the areas I know (computational physics, quantum chemistry, weather and climate modelling, engineering, things like that).

Two other usage patterns I can think of are large strings processing (think bioinformatics and genetics), and things with neural networks (which to be fair would be a natural fit for Fortran, if the libraries were not mainly developed in C++ and accessed from Python). Still, on the HPC facilities I use, number crunching in large arrays dominates used CPU time, and I would say about half of them are in Fortran.

Does Fortran run on GPUs?

https://developer.nvidia.com/cuda-fortran

There is also Intel oneAPI Fortran.

CUDA-Fortran is actually great. The added bits of syntax fit very well in the language, much better than standard CUDA in C or C++.

It’s a shame I never really was in a situation to use it in a real program (also, you had to use PGI, which I have always found sub par), but I have tinkered with it over the years and it is very pleasant to use.

Perhaps Fortrans wasn't designed as a general purposed programming language. But at least that's what was used by Niklaus Wirth to write the first Pascal compiler... :D

> Fortran coarrays are a relatively simple mechanism to distribute work across CPUs, pin work to selected CPUs, and synchronize the computation across CPUs. Potentially thousands of them.

Add MPI to the mix, and you can distribute that work to multiple machines. Potentially to thousands of them.

MPI over InfiniBand also can do some computations on the fly (in the HBAs and switches), so it makes it even fasterer (sic).

> This makes Fortran a one trick pony. It does parallel multi-dimensional data very well, but that’s really where it ends.

That one weird trick is a very strategic and cross-cutting one so almost every scientist can benefit from using FORTRAN. So, having one trick is not a bad thing here.

> Add MPI to the mix, and you can distribute that work to multiple machines. Potentially to thousands of them.

My understanding is that coarrays are a modern replacement for MPI and that coarrays abstract the notion of "machines", they bundle that under "multiple CPUs". I'm not very fluent in either of those, only know as much as the "Modern Fortran" book explains but from the examples I have seen, coarrays can do anything MPI can and they're simpler to work with.

> So, having one trick is not a bad thing here.

Definitely not. Personally, I would imagine myself using it if integration with other technologies over the network was available out of the box.

Aren’t coarrays only for single machine CPU parallelization? I‘d be surprised if you could abstract a whole network topology over it. The MPI communicator is really where it’s at when you want to drive a whole cluster (and if you’re using Fortran, you probably do).

A quick glance at Coarray Fortran [0] shows that Coarray library is built on top of MPI instead of replacing it.

MPI and InfiniBand are irreplaceable technologies for HPC clusters as of today, both in terms of speed and latency. Lastly IB is not a connectivity layer. It's a HBA which carries information from memory space of one application to another. So it's properly "Magick" in terms of programming and research.

[0]: https://en.wikipedia.org/wiki/Coarray_Fortran

not necessarily. But at least one of the major Coarray implementations (Intel Fortran compiler) translates the Coarray syntax to MPI so that the Intel MPI library can be used underneath. As a counter-example, the NAG Fortran compiler implements Coarrays for shared-memory architecture, and apparently has nothing to do with MPI.

> My understanding is that coarrays are a modern replacement for MPI

Well, yes and no. Co-arrays are a higher level abstraction, belonging to the category of Partitioned Global Address Space (PGAS).

Depending on the implementation, co-arrays might very well be implemented on top of a MPI library (as there has been a huge amount of work making MPI fast over all kinds of fancy interconnect fabrics).

What resources did you use to learn modern Fortran? I'd like to some something similar in order to better understand the code base for a popular fire model, and would appreciate any advice.

Not fire but waves. Here’s the book: https://www.manning.com/books/modern-fortran. This is the resource I used while learning.

The author of the book is very active on github: https://github.com/milancurcic.

Thank you!

I know no FORTRAN. I just support many researchers who use it extensively, and make sure their code works with the hardware we provide to them.

I also like FPM and the ecosystem. In case anyone is just getting started with Fortran, definitely checkout the Fortran Standard Library project:

https://github.com/fortran-lang/stdlib

How well does Fortran intermingle with other languages, like loading libraries (so, dll etc) or compile source as a library (dynamic or static)?

Most Fortran compilers are also C compilers, and the Fortran standard library is usually implemented in C. So interop with C is easy.

Ahh, FORTRAN. I have fun, memories of FORTRAN. Write out of college in the mid to late 90's I worked with the language quite a bit. I was working for a logistics company and we spent a lot of time calculating routes, costs (fuel, maintenance, etc.) and the like using FORTRAN. The move from F77 -> F90 -> F95 was rather pleasant.

When the web started to become popular and Microsoft started including IE on desktops, I ended up writing CGI scripts, in FORTRAN!, to model reports in HTML. We were moving from OpenVMS to Sun Solaris boxes, which allowed use to move way from writing text based reports that people viewed on a terminal to HTML pages that would easily allow CSV files to be downloaded. I was a mess for few months. I don't think I have ever fully recovered.

Yep, my first bit of web based programming was FORTRAN 95 and DCL. I had to cobble a cgi library together where I put in something that acted like, but wasn't exactly, authentication and security.

By the mid-2000s the system had been migrated to some monstrous application that was mostly Java, but there were still FORTRAN bits handling the math and numerical back end, but I had moved on by then.

I still have nightmares about the system, but writing the FORTRAN code was also easy. Using it in the right spot was always the hard part.

Talk is cheap, show me the code. There are exactly 0 snippets in this article, despite making subjective claims about the language being easier and more intuitive than C/C++ for HPC.

Here’s a good introduction to coarrays: https://github.com/tkoenig1/coarray-tutorial/blob/main/tutor....

In my view, Fortran's biggest advantage over C and C++ is its much simpler mental model. Compared against C and C++, a Fortran programmer needs to think much less about pointers and memory addresses. For example, Fortran procedures (functions and subroutines) are pass-by-reference, compared against C functions being pass-by-value. A Fortran programmer doesn't need to call a procedure with (C syntax) func(&x), declare the procedure with int *x, dereference the pointer with *x to get the value inside the procedure, etc. They can simply write x in all those places and it'll work. Why is pass-by-reference good in computational science? Passing large arrays by value would waste memory. Pass-by-reference is a better choice for large arrays.

A bit off topic, but the author has some nice links to his experience with Julia (starting with this post) which seems a very strong contender for taking over numerical computation and HPC from Fortran (not to mention the somewhat unnatural languages like Python/C/C++)

I was about to comment, if you like Fortran's syntax for numerical computation, you should try Julia. I feel it's basically the spiritual successor to Fortran, without all the historical baggage.

There is also comp.lang.fortran in USENET if you do not want to mess with discourse. There are a few very knowledgeable people still hanging out there. Plus no tracking if you use a real news reader (which means not google groups).

That newsgroup also has more than it's fair share of maddeningly annoying people who think anything beyond Fortran77 plus the proprietary compiler extensions of the compiler they happen to use (which inevitably is some long-dead trainwreck like MS Powerstation that nobody else has used for decades) is an affront to them and God (in order of importance).

And some people who inevitably try to derail every single thread into a discussion of Fortran IV and PL/I in the context of programming some 1970'ies IBM mainframes.

I used to be somewhat active on c.l.f, but I quit many years ago, and to be honest I haven't missed it one bit.

As an open source dev, I was impressed by how patient everyone is in getting complex Fortran PRs merged (you can take a look on OpenBLAS on GitHub). Part of this is the communities which still use Fortran, and part of it is no one is doing it haphazardly. I even got good suggestions on my own repo from strangers.

I can think of one or two reasons,

- It is damn good at what it is designed for, and that use case covers a lot of ground.

- No maddening update cycle which breaks all of you code once every 6 months

There are some languages where the primary reason for using them seems to be

- It is the first language I learned, and even though it is maddeningly inconsistent (despite claiming to be simple), it is a tool I am comfortable with

Not taking sides here. If you need to deliver something, the tool you know may be the best way to get it done on time/in budget, or a common tool may be better for business continuity.

Everything is tradeoffs.

> Fortran is easier to use than C/C++ for scientific computing

You had me at “Fortran is easier than C++”.

Have you tired modern fortran? Arrays and matrix are easy. String are horrible, but they have also many quirks in C.

Anyway, we still use a mix of modern fortran with old fortran (I'm not sure it's even fortran 77).

Most things are easier to master than C++, Fortran included.

I think the main reason, sort of related to "code longevity", is simply that a) nobody learns Fortran anymore and b) there is a huge existing library of extremely efficient, mostly bug-free numerical code that was written by experts in the 70s-80s-90s. LAPACK being the best example. Any port will a) contain more bugs and b) be slower, so what's the point? There are more fun things to do in life.

Porting LAPACK is not necessarily slower. C, C++ and D languages have better performance ports that are faster than Fortran based LAPACK (numerical library still being used by Matlab and Julia to this very day) [1][2]. Particularly, D language has a better performance port of LAPACK since more than 6 years ago and it should be much easier to be understood and maintained compared to Fortran, C or C++ ones [2][3].

Recently D introduced importC feature to natively support C, the de facto language for system programming. You can then just simply import and re-used the existing C programs and libraries as it is with all the bugs without introducing more bugs [4].

I hope already debunked the myth that Fortran is irreplaceable for numerical codes based on your arguments for good.

[1]Vastly outperforming LAPACK with C++ metaprogramming:

https://wordsandbuttons.online/vastly_outperforming_lapack_w...

[2]Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen:

http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...

[3]Commentary on "Outperforming LAPACK with C++ metaprogramming":

https://news.ycombinator.com/item?id=16257794

[4]Your next C compiler is a D compiler: Introducing DMD's ImportC:

https://news.ycombinator.com/item?id=33443615

Any chance you can make a PR to julia to give us one of the better LAPACKS? Our medium term goal is to replace LAPACK with pure Julia code but in the meantime, performance improvements are always appreciated.

To insist on a point :

FORTRAN is not just used like the (more recent) COBOL might still be "used" in legacy infrastructure - it's still being taught too, with mandatory FORTRAN-only assignments !

(Of course I might just be unaware, and COBOL teaching might still be widespread in some fields, feel free to prove me wrong !)

Fortran was my first language. It's crap on working with character data. I happily moved to PL/1.

I was in a project using Fortran for telecom switches and had to add an Assembler routine for character manipulation.

PL/I can produce efficient numeric code, provided you avoid library calls, and dope vectors (use static and pointers).

However that requires setting standards to avoid PL/I performance traps.

PL/I data conversion library subroutines can bog performance by a factor of 10.

I am always surprised that people are surprised about Fortran's activity! It works and your code will likely still compile 10-20 years from now. (It is certainly not perfect and sometimes it is annoying, but the same can be said about most programming languages).

Years ago at university I wrote a small 2D circuit board drawing system in Fortran running on some old IBM mainframe computer. Only the first 6 characters of function names mattered so I ended up using the first 2 characters as the module/namespace and carefully encoded the next 4 characters as needed. I had never programmed in Fortran before but it was easy to learn. Fun times.

The company I work for is still using old Fortran code to simulate how long it takes for trains with a certain load to get from A to B given a sequence of gradients. I bet small bits of Fortran still lives inside many systems written in C/C++.

I recently checked out flang[0] because I had never used Fortran and just wanted to see what it was like. It works pretty well! I did find one compiler crasher which I reported and they fixed within a few days.

[0] https://flang.llvm.org/docs/

Is there another numerical computing language that compiles?

Julia just-in-time compiles.

A bit earlier even than that.

Sometimes one finds oneself agreeing with a HN story that one knows to be factually correct and then not bother to defend its position against naysayers with entrenched views as to do is to buy an argument that one can't win—well, this is one such story.

As a Fortran programmer I know the language is alive, well and still doing what it does best so there's no need for me to defend its position in the programming languages debate—a debate which in recent times has taken on a fervor of nationalism about it.

What do you use it for? My dream is to write Fortran some day. I'm a mathematician who does mostly computations stuff, so like, it should be easy to come by such an opportunity, but so far I had no luck. Only Python, C, C++ and some Julia.

Physics. If you do any computational physics, sooner or later you’ll have to read and write Fortran.

Or hydrology

Maybe you would be a good candidate to compile a number of Reasons Why Fortran Should Be Used More Often.

Just one thing - debugged and battle tested numerical compute libraries

What do Coarrays do differently than a simple C(++) int/float array for atomicity?

Is there some extra magic, maybe for architectures that have "weak" memory?

It's not about atomicity.

Co-Array Fortran is for multiple copies of the same program running on different data -- SPMD. Think MPI but much easier to write for.

You start a CAF program with mpirun. Multiple copies on the same machine or multiple machines in a cluster, your choice.

Embedded directives to process arrays concurrently is a different topic, and confusingly called OpenMP with no "I". Thus your multi-core CPU can process a numeric code more quickly.

You start a program using OpenMPI with it's own name --- ./a.out for example. You can control the number of threads used. Etc.

Ok, to me those abstractions/tools make little sense.

I'd much rather use C on a client (int/float arrays for parallelism + cache) or Java concurrency on a server.

If I need cross machine parallelism that is not something I want automated.

I would love to get some exposure to FORTRAN! Where are the jobs hiding?

Assuming you’re in the US, Check out the various Department of Energy labs, NASA, basically anywhere there’s big computations being done to support science and engineering projects.

Reply on news.ycombinator.com