Fortran | Hacker News Reader

Fortran

fortran-lang.org

290 pointsqsort223 comments

Very recently, Los Alamos National Lab published a report An evaluation of risks associated with relying on Fortran for mission critical codes for the next 15 years [1]. In their summary, they write:

<quote> Our assessment for seven distinct risks associated with continued use of Fortran are that in the next fifteen years:

1. It is very likely that we will be unable to staff Fortran projects with top-rate computer scientists and computer engineers.

2. There is an even chance that we will be unable to staff Fortran projects with top-rate computational scientists and physicists.

3. There is an even chance continued maintenance of Fortran codes will lead to expensive human or financial maintenance costs.

4. It is very unlikely that codes that rely on Fortran will have poor performance on future CPU technologies.

5. It is likely that codes that rely on Fortran will have poor performance for GPU technologies.

6. It is very likely that Fortran will preclude effective use of important advances in computing technology.

7. There is an even chance that Fortran will inhibit introduction of new features or physics that can be introduced with other languages. </quote>

In my view, a language is destined for being a "maintenance language" if all of these are simultaneously true:

1. There is a dearth of people who know the language well.

2. Few people are opting to learn it in their free time, and/or seek it out for a job.

3. Companies do not seriously invest in training in learning the language.

4. Companies don't pay enough to convince an engineer to use it. who otherwise loves using other languages and has better prospects with them.

I've experienced unique challenges in hiring Lisp programmers, but the fact it remains sufficiently interesting to enough software engineers (who are usually good programmers) has been a boon, and likewise providing space to learn it helps even more.

Fortran though is teetering on its historical significance and prevalence in HPC. Aside from the plethora of existing and typically inscrutable scientific code, I'm not sure what the big iron imperative language offers over the dozens of other superficially similar choices these days, except beaten-path HPC integration. Scientists are more and more writing their code in C++ and Python—definitively more complicated than Fortran but still regarded as premier languages for superlative efficiency and flexibility respectively. Julia has had a few moments, but (anecdotally) it doesn't seem to have taken off with a quorum of hardcore scientist-programmers.

[1] https://permalink.lanl.gov/object/tr?what=info:lanl-repo/lar...

I fail to see how risk #6 was rated "very likely" given that neither #4 nor #5 scored "very likely".

"computing advances" probably means new software and algorithmic techniques, not (only) new hardware.

It's described more in the report. Their assessment #6 hinges on

- "Very likely" poor or non-existent robust GPU support,

- Unlikely robust support for specialized processors (i.e., non-general purpose CPU) like "Data Flow processors" and "processing in/near memory",

- Fortran advocacy and advancement is likely limited to DOE, which the report implies is insufficient, and

- Vendors of hardware have prioritized C++.

I guess “advances in technology” are not only new CPUs and GPUs, but also many other kinds of hardware and software

I can see this.

About 4: I think Fortran looks quite like C when it comes to the CPU architecture. Both are somewhat low level procedural languages.

As long as C works well on future CPUs, Fortran is probably fine and I don't see C disappear overnight. At least, Fortran compilers can be updated to produce reasonable code for new CPUs. Which should happen because of the shared compiler architecture (backend).

About 5: GPUs architectures seem less stable and seem to require specific development. If those specific developments require language support, that's probably not coming to Fortran if the assumption is that Fortran is going maintenance-only.

About 6: advances in computing technology are not restricted to CPUs and GPUs.

(disclaimer: I've only seen Fortran code from far away. And code targeted to GPUs too).

> big iron imperative language offers over the dozens of other superficially similar choices

Given the capabilities of modern machines and the fact that non-homogenous hardware (GPUs, different processors like in Apple Silicon) is back, the "winning" strategy is to have high-level scripting languages where you can ignore most of the details, which call into hyper-optimized, high performance libraries. For instance, when you're using Scipy, you call into Fortran and C almost interchangeably.

Since most likely you aren't writing full programs in the low-level language, it doesn't need to be a general-purpose language offering the same affordances, say, C++ is supposed to provide.

For numerical/scientific code, Fortran is much, much easier to use, especially for people whose background isn't computer science. Being able to write your code in terms of matrices and arrays rather than "pointer to const restrict" is a godsend when you're programming what is often very difficult mathematical code. When compared to modern C or C++ you won't get any advantage in terms of performance, but you don't lose much either, and in return you get to use a language that's much more suited to the task.

The historical Achilles' heel of Fortran is that it's kind of awkward as a general-purpose language, but that's negated by the "compiled core, interpreted shell" approach that's dominant these days.

(I should preface this by saying that my claims are all based on what I see in a specific scientific community and US laboratory environment. I can't say for sure my observations are true more generally.)

I think what you say is true in principle, basically on all counts, but Fortran's niche that its advantages serve best has been continually eaten away at by the Python/C++ combination.

The "I don't know pointers" crowd steers toward Python, and the "I care about CPU cycles" crowd steers toward C++, and that relationship is symbiotic.

Julia promised to be a general-purpose language, both as fast (or faster) than Fortran/C++ and as easy (or easier) than Fortran/Python. But it doesn't seem to have panned out as they'd perhaps have hoped.

Looking at Julia Computing industry partners, it isn't that bad.

Fortran still has a big fanbase and people actively fighting to keep it alive and thriving as much as possible. Maybe the crown will remain with C++ (in terms of fast languages), and maybe Rust will eat some of its lunch, but there seems to be a resurgence in the Fortran community to make sure it remains an important language in this space.

Julia has something similar but to a lesser degree. Its main problem has been the developer experience - the latencies (slowly getting better), lack of a great editor/LSP experience (the VS Code plugin is decent, but not yet great), lack of accessible how-to resources (people are starting to write more of these), and things like that.

I don't think Julia has been around quite long enough to make that statement yet.

I've just noticed it's now available on the system I work with, which puts it in the frame for a possible (probably far out still)future move for a massive C/Fortran codebase I maintain.

My general default if I'm going to update something is C++, but from what I see of Julia it's at least worth a look.

How has it “not panned out”? Julia has been in a useable state only for a few years, and is still rapidly developing. Prior to Julia 1.0, I would have said Fortran (which I have 15 years experience with) was the most productive language for scientific computing. Today, Julia is, by a wide margin. In fact, our benchmarks show Julia matching or beating Fortran’s performance, to say nothing of the mich increased flexibility.

In my experience "very difficult mathematical code" stems from employing little or no abstraction of the problem domain, mashing together numerical algorithms with physics formula. Using Fortran is IMO as much a prerequisite as a result of this.

I fully agree with you that scripting languages are a great fit for scientific computing. But I just don't see how this is a case for Fortran.

R or Python are still much easier to use and give you the same access to high-performance numerical accelerators via BLAS/LAPACK backends. And if you need a low-level language (e.g when developing an optimised routine that solves a specific problem), I would use a high-performance widely supported systems programming language like C++ or Rust.

Fortran seems to be around mostly for legacy reasons. And I am not sure that legacy considerations alone make a good foundation.

BLAS/LAPACK are written in fortran was the point I think. There are eigen and nalgebra certainly, but neither exports as cleanly to python, and neither is significantly (if at all) faster.

CuBLAS on the other hand makes a lot of sense to use from python if you have the right hardware.

The reference implementation of BLAS that you should absolutely not use is written in Fortran. The actual implementations are written in C/C++/ASM.

That's not to say you should use C yourself, memory management is a lot nicer in Fortran, for multidimensional arrays. You can stack allocate arrays inside functions and modern fortran has move semantics. Arrays are contiguous even if they have multiple index. It's generally a nice language for math, has good C API integration (both as caller and callee) and compiles down to small libraries without runtimes.

Thanks! I did not most any of that. Except for that it is good at math.

Loops in Python are excruciatingly slow, for no reason. Some algorithms are naturally written using loops, and Python makes this very uncomfortable, forcing you to rewrite your algorithm in a non-natural way. I hate writing numerical code in Python due to that; it just feels uncomfortable.

For scientific computation I just need multi-dimensional arrays of floats and fast loops. Fortran has both of these things natively. Python has neither.

I prefer vector types for this kind of stuff, as they are more compact than loops and naturally lend themselves to auto-vectorisation. In the end it comes down to the programming style preference.

A lot of the code used in scientific computing cannot be vectorized because the latter loop is dependent on the former loop (like time stepping in a simulation). It’s not really a programming style preference.

C++ and Rust don’t really have good semantics for scientific computing (linear algebra). They’re great for many other domains like “system’s programming”, where Fortran doesn’t compete, of course. The only language that’s similarly (in fact, more) expressive as Fortran for scientific computing today, as well as holding up for performance, is Julia

> the "winning" strategy is to have high-level scripting languages where you can ignore most of the details

From personal experience, I don't believe this works in practice. Invariably, some level of logic is implemented in said scripting language, and it becomes a huge bottleneck. Counterintuitively, when you have a central thread dolling out work to many subroutines, the performance of that thread becomes more critical as opposed to less.

"Invariably, some level of logic is implemented in said scripting language, and it becomes a huge bottleneck. "

Not necessarily and if it does, then the solution is to add that logic into the low level libary. So yes, you need at least one guy who can do this.

At that point, you’re not really using the high level language.

If you aren't using the scripting language enough for it to get in the way, you're probably not using it enough for it to make things easier either.

Just to be clear, I'm not saying it's impossible to strike the balance where it makes sense. I'm just saying I've yet to see it work, and I would, therefore, not assume such a balance is given by default, or even easy to achieve.

I agree with you. There’s also the additional cost of maintaining more than one language which makes the balance that much harder to do. I could see utility in the high level language to do something with the result if it’s not computationally intensive.

The theory is that 99% of the code is in the high level language, and 1% is in the low level language.

In my experience, that means that 80-90% of the developer effort goes into getting the FFI bindings to not be terrible. (In fairness to things like python, most of my FFI experience is with Java, which is notoriously bad at such things)

Have a look how games work. They are very performance critical - you have to calculate your simulation and draw it 60 times per second. That only works, if you have high performance low level libs. It is very common to mix C++ with lua. So yes, it is about balance, but it is standard procedure by now.

And with wasm (or even webGPU) one can do now the same with javascript and the web. Some logic in scripting is fine, but the heavy calculations should be lower level if one is aiming for performance.

    From personal experience, I don't believe this works in practice.

From personal experience, this works in practice.

It works well for web or other server-side tasks where your database is doing the "heavy lifting" computationally.

I believe you, though, when you say that you've seen failures of this paradigm.

It's pretty common to see issues where an inexperienced programmer is doing a bunch of data manipulation in 200 lines of Python/Ruby/PHP/whatever that could have been accomplished more easily, more performantly, and with more atomicity in 10 lines of SQL. I wouldn't say that means it's a busted paradigm. I don't consider bad implementations of a particular paradigm to equal refutations of that paradigm.

I do appreciate that there are probably arenas (scientific computing?) where maybe this approach doesn't work at all.

> the "winning" strategy is to have high-level scripting languages where you can ignore most of the details, which call into hyper-optimized, high performance libraries. For instance, when you're using Scipy, you call into Fortran and C almost interchangeably.

That gets you about 70% of the way there, but the remaining 30% is tricky. Unfortunately, the library-call stage doesn't easily (with generality) let you fuse operations. For example, consider the example of a finite-volume code, where the flux is some nonlinear function of the interface value, taken to be the average of left and right cells:

  flux = nonlinear_flux_op(f[:-1] + f[1:]) # Compute interface fluxes
  f[1:-1] += dt/dx*(flux[:-1] - flux[1:]) # Update cell volumes based on flux differences
  # Do something special for the boundaries

Each of the substeps here is fast. Sub-indexing these 1D arrays is trivial, and their local operations are highly vectorized. The nonlinear flux operator operates element-wise, so it's easy to compile it into a version that properly (CPU) vectorizes (and/or it might already be provided, like np.exp or *2). This code is also very readable.

However, real performance would require fusing operations. There's no need to compute a full temporary array for the interface values, but that's exactly what would happen in naive NumPy code. Likewise, there's no need to compute all of the fluxes before taking their differences.

A hand-optimized code would perform the full computation in a single scan of the array, keeping all of the data in CPU cache (blocking by a cache line or so in order to use vector registers effectively). Even if given the code naively written, an optimizing compiler would try loop fusion and get most of the way to the hand-optimized result.

Code such as this is relatively FLOPS-light compared to the amount of memory accessed, so effective use of cache can lead to an order of magnitude speed-up.

With a fair amount of work you can still achieve this result in Python, but to do so you need to use one of the optimizing Python compilation tools like numba. Unfortunately, this is not easy for the not-a-programmer domain scientist, since working with numba means understanding the intersection of Python and numba's imposed compilation rules.

Numba is quite restrictive... to someone comfortable in C++, coercing my code into a form Numba likes sometimes feels no easier than writing an extension using Eigen types and pybind11.

> "the "winning" strategy is to have high-level scripting languages where you can ignore most of the details, which call into hyper-optimized, high performance libraries. For instance, when you're using Scipy, you call into Fortran and C almost interchangeably"

That's nice as long as it works, but in my experience gets ugly when it doesn't. While we can currently witness this being a successful model, the impedance mismatch between both worlds is often a pain.

I bet on a language like Rust as the winning strategy in the long run - high level like Python but still close to the metal and all in one language, one compiler, one ecosystem.

Rust shares a lot of performance advantages around pointer aliasing with fortran. In fortran, pointers can't alias by default, and in rust, the borrow checker should be able to infer that a shared and exclusive reference don't alias, allowing the compiler to assume that it's not writing to input values of a loop, etc.

In C, pointers can alias by default. The last time I checked, that made these sorts of optimizations harder. However, I'm not sure how measurable the performance impact is these days.

Fortran pointers must be assumed to alias. It's Fortran's dummy arguments that must not alias.

That kind of sounds like Mojo.

Well, no. This is python's strategy. Doesn't make it the winning strategy. Python implicitly forces multiple languages upon you. A scripting one, and a performance one. Meanwhile languages such as Julia, Rust, etc. allow you to do the work in a single (fast/compiled) language. Much lower cognitive load, especially if you have multiple cores/machines to run on.

Another point I've been making for 30+ years in HPC, is that data motion is hard. Not simply between machines, but between process spaces. Take large slightly complex data structures in a fast compiled language, and move them back and forth to a scripting front end. This is hard as each language has their own specific memory layout for the structures, and impedance matching between them means you have to make trade-offs. These trade-offs often result in surprising issues as you scale up data structure size. Which is one of the reasons that only the simplest of structures (vectors/arrays) are implemented in a cross language scenario.

Moreover, these cross language boundaries implicitly prevent deeper optimization. Which leads to development of rather different scenarios for code development, including orthogonal not-quite-python based things (Triton, numba, etc.).

Fortran is a great language, and as one of the comments pointed out, its really not that hard to learn/use. The rumors of its demise are greatly exaggerated. And I note with some amusement, that they've been going on since I've been in graduate school some 30-35 years ago. Yet people keep using it.

Statements like these without discussing the language standard most of the Software you have uses is kind of pointless.

I guess most of the legacy code for which they do this risk assessment is Fortran 77. Not any more modern.

And getting it up to date to modern fortran would be as much effort as any other modern language.

The report mentions both "modern Fortran" (which they explicitly specify to be Fortran 2008) and "legacy Fortran" (which they don't further specify, but I assume is 77).

In the community, “legacy Fortran” is pre-Fortran 90. Modern includes everything since then, so right now up to Fortran 2018.

About:

> 1. It is very likely that we will be unable to staff Fortran projects with top-rate computer scientists and computer engineers.

They are mentioning "top-rate", I'm assuming salary is not an issue. I can understand for a scientist who's job is not programming (and programming is just a necessary activity). But for a "top-rate" computer engineer, given a good enough salary and an interesting field, how hard can it be to learn enough Fortran for this?

Or am I misunderstanding what is a computer engineer?

Even for a top-rate scientist actually. Surely the programming language is not the hardest part of the job?

(not saying they should not try to move away from Fortran, there are better solutions for this field now, I mostly agree with this list full of insight)

While I agree that a computer scientist should be able to pick up any language with a bit of training, to be effective in using it, it takes – sometimes – years of continued use. That's a steep investment for any company/lab.

Years is an exaggeration. I happened to ride the popularity wave of both Go and Rust at their respective moments. I've seen a lot of programmers, good to mediocre-bad learning a new language on the job. The range is between a month and three months maybe. It's really not that big of a deal.

> Years is an exaggeration

Not necessarily when it's not your job, but it depends on what level of comfort / ease we are talking about.

A relative who is a physicist and who started with Fortran recently switched to Python. They told me it took them around 3 years to be as comfortable as before.

Now, I suspect they were very comfortable with Fortran to begin with, and if they programmed a significant amount of time every day, they would have been up to speed way faster.

(They also said they would not go back to Fortran)

My wife is an "RSE" (research software engineer), she's an MD by training, but doing some programming for research. She's been in this role for about two years now, and she did maybe another two years of Python programming prior to that in a similar role.

She still doesn't feel comfortable with Python (or any language) and often needs guidance / help. Mostly because in this role, the amount of programming is really minuscule, and the expectation isn't that the programmer develops a useful application or library well-integrated into the larger ecosystem of applications or libraries. Rather it's that some research can sift through the data they've generated and publish on that.

The instances of "re-education" I was talking about were quite different: those were "programmer-first" people. In this capacity, they might write in a month more code than what what my wife wrote over the last four years, they are also expected to build a lot more complex (in terms of organization and integration) software.

I don't consider RSEs or similar roles to be professional programmers. These people typically have terminatory degrees in fields other than CS, but often no formal training in CS. They also rarely see their own goals in becoming as good of a programmer as they can, their evaluation is typically based on results that programming might help to bring about, but, in principle, isn't really necessary for. Sort of how you wouldn't call every programmer a "professional mathematician", even though writing programs is a kind of math, as is eg. checking out customers at the supermarket.

So, while someone like that might need years to adjust to a new language, OP seemed to have in mind professional good programmers. I think they even had another bullet point for hybrid scientist-programmers.

While I think you're correct that goals and roles may be different, on average, for the scientist-turned-programmer trajectory, there are plenty of RSEs who come from the opposite direction, i.e. strong programming background, but picks up the problem domain on the job.

Source: am RSE. And I will also say, a few of the scientists I support are among the best software engineers I have ever worked with, despite caring about code only insofar as it can help answer useful questions.

> A relative who is a physicist and who started with Fortran recently switched to Python.

Fortran is considerably simpler than Python, though. No metaprogramming. No functional programming. No objects. Etc.

Fortran is very simple though, more like Go or Java than Haskell. A C developer could pick it up in a week or so just reading the ISO spec, someone else might take like three weeks?

It's basically C with nicer syntax, and some QoL features.

I agree, Fortran is easy to learn, and it's a pretty small language so you can keep it all in your head. The part about Fortran that I find hard is the "culture" around it. There are styles of programming in Fortran that just don't work with my brain. Just like the "Java culture" of extreme abstraction (i.e FactoryFactoryBuilderHelper classes) bothers me too.

I can start a fresh Fortran program and write it out pretty quickly (though I do miss native dictionaries), but when I have to collaborate with an old-school Fortran programmer (especially one trained on FORTRAN 77) it's pretty tough for me. I have to reprogram my brain to think in that style/culture.

I tend to do most of my high performance numerical stuff in Numpy since it defers to the Fortran libraries for the hard stuff. I haven't found any properly written vectorized code get bottlenecked in the interpreter.

Fortran is simple enough to be used by dumb physicists. At its core it is a standard imperative language, like C with a lot less footguns and much more user-friendly. Its object-oriented parts have some strange syntax, but are otherwise unsurprising. There isn’t any step like when starting something like Lisp or Haskell.

It would definitely not take years to get on top of it for anyone who knows a bit of programming.

If you're a top-rate software engineer, you're not going to choose a career path that will trap you in some deprecated technology.

The challenge isn't that people can't learn it, it's that they don't want to because it's a bad career move.

This isn't true.

Enough of good programmers choose unpopular languages, and for different reasons. Some genuinely find particular aspects of the chosen language appealing, and since they are in general good programmers they don't have a fear of unemployment or the pressure to build their career -- they've already established themselves in their field and don't need to reassert their skills and knowledge.

Others may opportunistically choose a new, but still unpopular technology, sometimes because other good programmers seem to have chosen it, other times because they may hope to gain more popularity / acclaim, which is easier to do in a new, and especially in a small field.

Furthermore, it just so happened that popular technologies in the industry today are all kinds of bad. Just of sheer desperation / disdain to a particular group of related technologies one may want to try to switch to a niche technology that seems to go against the mainstream.

---

However, in all those cases, there must be something "interesting" going on for the technology in question. I don't know enough of Fortran to claim there's nothing "interesting" going on for it, but it's possible that there isn't. In which case, there won't be an incentive for good programmers to choose it over similar technology that has that glimmer of hope that it's going to be so much better.

> I don't know enough of Fortran to claim there's nothing "interesting" going on for it

You mean in the language itself or its applications. Honestly I’ve heard about a lot of really cool things written in Fortran. Honestly, I wouldn’t mind learning it, but I’m far from a “ top-rate computer scientist” so no Ike using Fortran would be interested in me.

All good stuff I've ever heard about Fortran could be summed up as "it's easier to write optimizing compilers for it", which was probably a claim made more than ten years ago based on an interview with someone who worked for IBM over twenty years ago on Fortran compiler.

Suppose this was the only really good thing going on for it... well, this wouldn't attract a lot of people. Also, I'm not sure Fortran can boast to be the easiest language for optimization. I believe the statement was made in the context of comparing it to C, in which case, it's not such a high bar.

I've been out of grad school for a bit now, but 10 years ago is about right. There were a lot of things being published about compilers that might have well been direct ports of papers written in the 70s, "now for JITs." And honestly, if you read some of those papers from the 70s about automatic parallelization and such, it was pretty freakin' cool. And there were memory guarantees in Fortran that were not present in C that made it non-applicable. Java had most/all of those guarantees, which is what I think brought about their revival. That's probably not the whole explanation, as I'm not sure why it took Java so long (these were 2010+ papers, 15+ years after Java came out).

The very first optimizing compiler was written in Fortran, to compile Fortran. I think this was the 60s.

The use of pointers in a language vastly complicates the task of optimization. From Fran Allen, a compiler researcher and co-inventor of SSA,

By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are basically not taught much anymore in the colleges and universities.

> If you're a top-rate software engineer, you're not going to choose a career path that will trap you in some deprecated technology.

Which is kinda good, to be honest. Long-term Fortran projects and the like don't deal with the usual FAANG-type career-oriented churn that well, that mirrors the same problems you have in academia-oriented libraries where you get maintenance gaps when graduate students leave.

I would have assumed that the best engineers are not afraid of being “trapped” by a specific technology. That seems like a very surface level concern to me.

> some deprecated technology

In numbers, IT jobs are dominated by social media companies, and companies selling ads and services on the web and via mobile apps. But I don't think these areas of applications should define what is or isn't deprecated technology for e.g. nuclear simulations, and weather and climate forecasts.

Fortran is bad for implementing web services. But it doesn't make popular web service technologies good for weather forecasting, either.

Yeah learning a new JS framework every three months is much more rewarding!

Financially, it is.

Salaries for software engineers at a US national labs like LANL don't deviate far from the $100k range [1]. For many projects, a security clearance and on-site presence are required. Add to that the requirement to train and use Fortran (old and new), the job proposition is only looking good to (1) people who love the problem domain (e.g., nuclear stockpile stewardship), (2) people who are specialized scientists who moonlight as programmers, or (3) people who simply like government lab environments (stability, science, ...).

[1] A SWE4 (BS + 12 YoE) has a pay scale of $109k - $182k and requires a Q clearance (top secret for nuclear): https://lanl.jobs/search/jobdetails/senior-software-applicat...

It's not about learning Fortran being hard, obviously if you're good you can acquire any language, especially in a paradigm you already know anyway, but why ?

That's the thing for these "top-rate" posts, you need to sell the candidates on why they want to take your offer, not some other role they could have. Yes, one option is to "just" pay them a tremendous amount of money, but remember you're competing with the banks who have the same strategy and their whole business is making money. So that would be very expensive.

Instead it makes sense to compete on other considerations. Candidate doesn't like to work in the office? No problem. Stay where you are, work for us remotely. Or maybe they'd like to move their grand parents and extended family to your country? You could make that happen. Or could you? Do you think the US Federal Government will accept "We need to naturalize these sixteen random people, immediately to get one Fortran programmer" ?

And the choice of language is one of those other considerations. To a first approximation nobody is more keen to take your offer because they get to write Fortran.

Hiring Fortran programmers is risky because there's so few and those that claim to know it might either be exaggerating or simply not good at it. It's not just the language, anyone can learn the syntax. It's making sure that whoever you bring in can actually do the job

The "Hiring Fortran programmers is risky" argument is incorrect. This is, in fact, the whole point of Fortran, that anyone as dumb as a rock "would" (not "could" or "might") write performant code. There is currently no other language that can achieve this. Any other language claiming this capability is essentially recreating Fortran (perhaps with a slightly different syntax). Fortran Standard has been pursuing this sole goal for 70 years and has become extremely good at it. Your argument applies very well to C++, though. But it's not too hard to catch a novice there, either.

When a job I'm interested in uses a language I haven't used before I say that I've learned a couple already and I'll quickly learn the next one. I'd generally say each additional language has been easier than the last. I've landed contracts to code in languages I didn't know and got positive feedback about my performance.

Is there anything unique about Fortran that prevents experienced engineers from quickly learning it on the job?

The language itself? In broad strokes, not really. The typical tooling? Definitely yes, it's usually very HPC centric (MPI, OpenMP, batch job schedulers, ...).

I assume all this specialized tooling will be a hurdle in the learning process. It's not like you can spin up a docker image and hack on.

Perhaps in the future, learning how to run native binaries on bare metal, will be viewed as learning specialized tooling.

I haven't used it, but shifter looks like an MLI on docker toolset.

https://docs.nersc.gov/development/shifter/examples/

People are reasonably expected to learn k8s or React on the job, and those have a learning curve as well. Are MPI/OpenMPI much more difficult than those? I suppose that's a hard comparison to make. At first glance it doesn't look too crazy to me.

https://www.eecis.udel.edu/~youse/openmpi/#/7

MPI is trivial to learn. CS students here are expected to use it for typical scientific tasks within a few hours of lessons. Complex use cases take some time to understand backgrounds (e.g. multi partition configurations, profiling, infiniband, ...) and it's possible to become a specialist, but that's very rarely needed.

But MPI, in most use cases, comprises far less than React does, so it's not a fair comparison.

> Is there anything unique about Fortran that prevents experienced engineers from quickly learning it on the job?

No. I think that Fortran is a convenient scapegoat for LANL, not an actual obstacle. I discuss what I think the real problem is in this comment: https://news.ycombinator.com/item?id=37292569

> Is there anything unique about Fortran that prevents experienced engineers from quickly learning it on the job?

Perceived prestige, or rather the lack thereof. People with CS background often feel that learning Fortran is beneath them.

> ...prevents experienced engineers from quickly learning it on the job

The problem is in the longevity of Fortran. The variety of codes accumulated through time makes up for more than one Fortran. Modern Fortran may appear as a new language, yet still very compatible with 'classic' Fortran. MPI adds another dimension to learning it, though there's tooling around it.

The aspect of tolerance to single letter variables and cryptic function names could also be a factor, no kidding.

In general, asking for prior experience with Fortran is reasonable, just as hiring someone to "quickly learn" C on the job is quite non-pragmatic.

I think it's the oldest joke in cs: "I don't know what we will be programming in the year 3000, but I know it will be called FORTRAN"

My own renaissance came via Jetson Nano where CUDA FORTRAN has some nice examples for image processing via convolution kernals. It's blazingly fast: both design time and run time!

This short film from 1982 shows the love scientists feel for "the infantile disorder":

The Beginnings of FORTRAN (Complete)

https://www.youtube.com/watch?v=KohboWwrsXg

> My own renaissance came via Jetson Nano where CUDA FORTRAN has some nice examples for image processing via convolution kernals. It's blazingly fast: both design time and run time!

CUDA Fortran was amazing. It had a really nice syntax, which did not feel that odd next to standard Fortran, and great performance. But it faced an uphill battle, was not really well managed and suffered from being coupled with the PGI compiler. I wish they’d put it in gfortran instead.

CUDA Fortran is actually alive and well, and is being carried forward into LLVM Fortran.

On LANL's points numbers 1 to 3, here's a perspective from the other side:

I think their main problem hiring is that they are looking for perfect candidates. (The same may be true for some of the other DOE labs like LLNL as well.) I've interviewed for at least 3 positions at LANL. I have a security clearance and would love to work for them, but I have never received an offer from them since finishing my PhD. (I did a summer internship with them a long time ago.) Issues like there being relatively few Fortran programmers are convenient scapegoats. They seem to want someone who not only knows Fortran, but also can easily get a security clearance or already has one, can write highly optimized MPI code, is familiar with the unusual numerical methods LANL uses, etc. They seem unwilling to hire people who are 80% of the way there. I've never programmed with MPI, for example, but understand the basics of parallel programming and have programmed shared memory codes. The most recent LANL group I interviewed with also didn't like that I quit a previous postdoc due to disagreements about the direction of the project.

In contrast, in my current job at a DoD contractor, they didn't seem to care much about what I did before or knew previously. They apparently hired me because I had some familiarity with their problem and could learn what I didn't know. I've done well in this job working on things mostly new to me. I'd like to leave because of the bad job security and bad benefits, but otherwise, I have no major problems. (And yes, I do use Fortran on a daily basis here, including some horrendous legacy Fortran.)

Given this, I don't think LANL's hiring problems will stop if they switch all their active softwares to C++ or some other language, because that's only part of the problem.

Edit: Another problem is that LANL's hiring process is convoluted. I almost got an offer from them two years ago, as the group I interviewed with liked me. But they required me to write an internal proposal which would have to be approved by someone outside of the group. I think this is part of LANL's standard post-doc hiring process, though at the time I thought it indicated that they didn't have the money to hire me and were trying to get it. There was no guarantee that the proposal would be approved. I didn't have the time then and backed out, though in retrospect I wish I went through with it as I've heard this is more routine than I thought it was.

Edit 2: Also, for clarity, not every position I applied to required Fortran knowledge. But I think my basic message is correct, in that LANL tends to be fixated on hiring "perfect candidates" when there are plenty of capable people that they could hire instead who just need to learn some things, or might not have a perfect job record (gaps in employment, etc.).

> I think their main problem hiring is that they are looking for perfect candidates.

I’ve noticed this with government and government adjacent stuff: they are choosing beggars.

The salaries they offer tend to cap well below what you can make in the private field, often are in weird areas and don’t offer relocation, and just seem terribly bureaucratic when it comes to advancement.

And yet, it seems they won’t hire you if you don’t hit their checklist to a T. I applied for a NOAA job, that wasn’t too crazy, and for the most part, was a pretty good fit for my resume. However, the application had a checkbox question along the lines of “have you ever written software for [hyper specific domain]”. I answered no and was unsurprisingly rejected. By the way, this wasn’t some wild scientific computing project, it was basically a job writing CRUD software for something that sounded interesting to me.

I really wonder how some roles get filled, I’ve seen some ridiculous asks.

What have you hired Lisp programmers for? I'm curious.

I am one of the co-founders of the fortran-lang effort. I did it while I was at LANL, where I worked as a scientist for almost 9 years. I think the report is overly pessimistic. Here is my full reply on the report: https://fortran-lang.discourse.group/t/an-evaluation-of-risk....

And yet, we now a compiler (Codon) that can compile Python into Fortran code, also allowing direct use of LLVM IR and ability to import C (and Fortran?) libraries.

Perhaps, interoperability is the way forward.

Yes, I lead the development of these two compilers:

https://lpython.org/ https://lfortran.org/

LPython compiles Python at the Fortran speed, since both compilers share the same internals.

So, I have a question (I didn't real the LANL paper, save for the highlights above, but I did read your initial post that you linked to).

And this isn't meant as some kind of bait, just honest intellectual curiosity (its the internet so you can't see how it presented, just read the raw words).

Simply, why is it important for Fortran to survive in this space? Why not let the field move on? Why fight this fight?

BLAS/LAPACK (fortran blobs) are the miracle that all AI relies on (to my understanding). I hope we keep it around and maintained.

I wonder why the cascaded triple for loop for GEMM is not just hardcoded in assembly for each architecture. And while we are at it, why is MKL > 5GB again?

Does this address your MKL question?[1] If so, sounds like we're two of today's lucky 10,000![0] Although for this esoterica, I'd probably reduce that to 10.

[0] https://xkcd.com/1053/

[1] https://community.intel.com/t5/Intel-oneAPI-Math-Kernel-Libr...

Most decent BLAS implementations use some variation of the kernels in K. Goto et al. "Anatomy of High-Performance Matrix Multiplication" written in assembly.

It's a great question. I think we answered it in one of our initial blog posts when we started LFortran:

https://lfortran.org/blog/2019/05/why-to-use-fortran-for-new...

Let me know if you have any follow up questions.

So the risks have more to do with adoption of the language than the language itself?

I studied Fortran in my college programming languages class (in the early 2010s) and loved it! Always wondered why it isn't used more.

As "way forward" report it covers only half the problem.

Identification of the risks including the likelihoods and hazards is pretty good. I like the notion of contrasting opinions included in the report.

But the big thing missing is mitigations: what can they do about training, about recruiting, and especially about "industry" investing in compilers? This report says nothing about ways to assure continued usability of Fortran-based codes in the next 10 or 15 years. It just lists risks. What can they do to improve the capability of GPU compilers, CPU compilers, training or staff development?

And, setting Fortran aside, what are the plans to assure continued capability in supporting and developing all of their codes, in whatever languages, in the next 10 or 15 years? This evaluation might well be replayed for CUDA, Python or Julia in the next 5 years.

The US budget for supercomputing must be in the $2G to $5G per year range, yet it seems the notion of planning a software strategy for supercomputing is not achievable.

>> I'm not sure what the big iron imperative language offers

Does any other language have built-in COMPLEX type? Or funny (but fast!) stack-free function calling?

Common Lisp has complex numbers: https://lispcookbook.github.io/cl-cookbook/numbers.html#comp...

Is stack-free function calling equivalent to tail call optimization? If so, then many CL implementations support it, including SBCL. For Scheme, it’s part of the standard.

Fortran is in a very strange position in the current tech landscape.

There is a race of sorts going on, to simplify and commoditize high performance computing in the post-Moore's era. This means enabling things like easy GPU programming, easy multi-core programming, easy "number crunching" etc. Historically this was the stuff of esoteric HPC (high performance computing) pursued by highly specialized computational scientists etc. (read -> an important but non-economic domain that subsisted largely on government funds).

Yet suddenly the same arcane HPC is effectively also the domain of "AI" and the associated planetary hyperventilation. Now all sorts of modern initiatives and language ecosystems aim to reposition to gainfully intermediate that AI revolution. Python was the scripting language that somewhat unexpectedly enabled all this, but now its warts are under the microscope and people think of various alternatives (julia), supersets (mojo), newcomers like rust etc. But that race is definetely not settled and it might not be so for quite some time. The requirements are highly non-trivial.

As far as taking part in this race, Fortran seems to have missed not one but several boats. Yet the fact remains that it was a language designed for number crunching and evolved as language for HPC, with parallel computing features (since F90) etc. It combines easy to read imperative numerical code with near optimal computational performance.

Its like a former world champion in a sport that was fell out of favor for a long time but is now unexpectedly back in vogue. So the question is whether the champ can get back into shape or make room for new contenders :-)

Very well put. Also a subset of Python: https://lpython.org/, and it shares the internals with https://lfortran.org/, both run at the same speed. If you have any feedback, please let us know.

I’ve done computational physics and used Fortran. There are some warts, like line length requirements. But for actual math, Fortran takes the cake

And the line length limit will soon (with Fortran 2023 later this year) practically go away--a hard limit of 10,000 characters.

Changes to the standard don't instantly, or even eventually, cause corresponding changes in implementations. Code that needs to be portable to many implementations will need to worry about line length limits for a long time into the future.

The Venn diagram of Fortran feature availability in the various actively maintained Fortran compilers is very messy, and the ISO standard is definitely not a subset of any of them. Standard-conforming code is not necessarily portable, and highly portable code is not necessarily standard-conforming, especially since Fortran '95.

The hard line limit length is at 1,000,000 characters not 10,000. Also, all major compilers currently have flags to significantly extend the line limit length.

You're correct about the compiler flags. 10K will be the line length limit; the 1M limit is for a statement length that can span any number of lines.

having used both FORTRAN and Julia, Julia generally had less friction and comparable speed. JIT is great for having a very short programming loop. I definitely prefer Fortran to Python though for math programming.

The insistence of using dot operators for nonsensical purity ruined julia for me. A good example of computer scientists ruining things.

Can you give an example? I haven’t used Julia and I’m curious to hear what you mean by that.

Normally, languages implement SIMD compilation for a specific set of data types/structures and even then you have to really make sure to ask the compiler nicely. Julia is able to vectorize any generic, user-defined data types/operators/functions. This comes at the cost of pretty horrid syntax. It needs extra syntax to give the compiler the information, for sure, but you can argue that it could have been chosen better.

  X .= f.(2 .* X.^2 .+ 6 .* X.^3 .- sqrt.(X))

Or just use @.

julia> X = [1.,2.,3.]; f=sin;

julia> @. X = f(2 * X^2 + 6 * X^3 - sqrt(X))

In fortran 90, an example I have sitting around:

   c_y   = (qmr*ey_sub*dtsq + c_y*(2 - omsq_b*dtsq))/gmdto2p1 - c_ym1*gminv

ey_sub, c_y, c_ym1 are N long arrays with the same shape, and in this case, the operation is elementwise, so indexing isn't needed, and I do not need an explicit do-loop (for loop in C languages) so it fits on a single line that is readable to a scientist in the field. The julia equivalent, I think is the same with a period on every operator

   c_y   .= (qmr.*ey_sub.*dtsq .+ c_y.*(2 .- omsq_b.*dtsq))./gmdto2p1 .- c_ym1.*gminv

The assignment was already verbose as it is, and I at the time tried to make it terser but still marginally readable by using variables that are named for...scientists I guess (e.g., gmdto2p1 means "gamma * dt / 2 + 1" dto2 thoughout the codes I read and use is "dt over 2") and adding 10 characters makes a little more cumbersome. While I think the visuals can be acclimated to, it is tedious to write, especially when you translate a formula from vectorised form to non vectorised or vice-versa and have to insert or delete periods. Mind you this is one of the simpler formulae in the code in question. You can imagine it quickly gets worse when the number of terms exceeds 6 or so.

If you can't rely on implicit-do or terse assignment statements, then the good alternative in terms of readability then for the formula is just to do an explicit do-loop (for loop for julia).

   ! fortran 90, `integer i` above
   do i=1,size(c_y)
     c_y(i) = (qmr*ey_sub(i)*dtsq + c_y(i)*(2 - omsq_b*dtsq))/gmdto2p1 - c_ym1(i)*gminv
   end do

   # julia
   for i=1:length(c_y)
     c_y[i] = (qmr*ey_sub[i]*dtsq + c_y[i]*(2 - omsq_b*dtsq))/gmdto2p1 - c_ym1[i]*gminv
   end

The problem is then I have made more extraneous bits to worry about. This gets even more hard to parse when the shape of the arrays exceeds more than 3 dimensions. I've read C style codes that are 7 levels deep with different indices, god is it painfully unclear and easy to get lost reading that, it's best to hide extraneous loops with syntactical sugar where possible such as to keep the algorithm as clear as possible, especially when it's a simple elementwise operation. It isn't like you can hide complexity all the time (or that it's even a good idea to do so), but this was a code for just two figures in a paper that needed a bit more oomf than numpy could, so given the time constraint for me, the size of the problem and everything, fortran fit much better.

If you want to know more about the dot macro in julia, here is a nice blogpost about them[0]. The line above is from work I did for a paper that I initially thought "hey, it's been a few years, why not see if julia has stabilised by now" only to find out this was a decisive change they made. I mean they might deserve praise having made this macro a very general thing and apply widely to things that aren't just syntactical sugar for broadcasting, but after being frustrated trying to write my code, googling, and then finding this post, I basically dropped the julia learning effort and got the code written in fortran and made my figures. I can learn things in my spare time to a limit but at the end of the day I have a job to do.

I still want to give julia a chance because the idea does seem cool. I complain about computer scientists a little tongue-in-cheek but really I find the metaprogramming in julia pretty interesting. I'm just not sure I can use it in my day job as a scientist without some effort in learning and time on my part which is at a premium right now.

[0] https://julialang.org/blog/2017/01/moredots/

It took me awhile to get used to the dot operator, but what convinced me that it was a good choice is that also your own function can be broadcasted with function_names.(args). For example is you have a function process_a_file(in_filename,out_filename,parameter_value), then you can easily process also a list of files with process_a_file.(in_filenames,out_filenames,parameter_value) (if parameter_value is a scalar it gets broadcasted). I think that it is similar to numpy ufunc's but every function have this possibility.

A useful macro is @. which allows you to write "@. A * B * C" instead of "A .* B .* C". Also the macro avoid the creation of an intermediate vector with A times B.

I'm far from a computer scientist, and used to be a fan of "Do What I Mean" (DWIM) magic like automatic elementwise broadcasting. But have come to highly favour consistency and predictability over that with experience.

I've certainly had moments where I've gone "just do that elementwise already, it's obvious!" and been mildly annoyed, but I'll take that any day over silent misbehaviour, hard to detect bugs, and being unable to tell at a glance what exact operations are going on in a line of code.

But I I would argue that for mathematical operations doing elementwise by default is much more consistent than doing matrix multiplication everywhere. Now the multiplication operator works differently (and importantly changes the shape of your result) based on what your arguments are. While elementwise behaves essentially like it was scalars everywhere. But the worst part of the elementwise operator is that they followed matlab and chose the freaking dot, the most easy to overlook character they could find. The issue is that missing the dot often does not result in errors but in bugs where somehow the code is not giving sensible results. Back in the days when I was still teaching matlab to students, the main source of bugs were missing dots which were always painful to find.

do you mean f.(x) for broadcasting?

What? That isn't at all about computer scientists. One of the most fundamental reasons for it is actually mathematical.

Functions like exp and sin can be defined on numbers, but are also well defined on square matrices. In languages that have automatic broadcasting of functions across arrays, if you write exp(x) and x happens to be a matrix, you won't get the mathematically correct answer. You actually get [exp(xi) for xi in x] which is nonsense.

Having the dot operators make it very easy to tell if a function should be operating on entire arrays or on elements of those arrays. It also enables performance enhancements, because if I write

    exp.(x) .+ 1

that will do [exp(xi) + 1 for xi in x] instead of [y + 1 for y in [exp(xi) for xi in x]] which wastes and allocation

I once noticed the thing is people balk at the line length in fortran as if it is some archaic hold off (which it is somewhat) that proves its obsolescence but in the next breath berate everyone for not using a formatter that will chunk lines into 100 characters in their favorite "modern" language. I guess the problem is fortran chose 80 as the line length and not 100.

> as if it is some archaic hold off (which it is somewhat)

Indeed it is! The standard IBM punch card had 80 columns.

> and not 100

The standard IBM printer models had 120 print positions.

It is 80 for "fixed form" (card image) source files. It is 132 for free form modern source, but adjustable on the compiler command line. LLVM Flang uses the line length only for emitting optional portability warnings.

100?? Obviously 132 is the correct line length.

But mah punch cards!

As weird as it may sound, I prefer the old fixed-form source with continuation characters and mandated 7-character indent. Like Python, it made for consistent code formatting across people and libraries.

Fortran-lang's role (as an open-source org) has been 4-pronged: Tooling (build system and package manager, testing, eventually compilers etc.), modernized and maintained libraries (stdlib, minpack, fftpack, etc.), community space (Discourse), and evangelism/marketing (website, Twitter, blog posts etc.). Some members participate in the standardization process of the language, but the groups and processes are separate and complementary.

It's true that one goal may be to pick an important race and try to win it.

Another goal, in my view more important, is to make Fortran more pleasant to use for people/Orgs who need it (there are many) and for people who love it (there are many).

I've found that more often than not, people/teams first like working with a technology, and then come up with technical arguments for why that technology is the best choice. Often the arguments are valid, sometimes they're made up, but ultimately underneath it all you either like it or not and that's all that matters. My goal with Fortran-lang has been to slowly and continuously increase the surface area of Fortran's likability. Fortran is not for everyone, but for people who think it may be, we can work to make it better and more pleasant to use.

As one example, we just released a small library to make high-level HTTP requests from Fortran applications: https://github.com/fortran-lang/http-client. This was a product of one of our Google Summer of Code contributors.

> people/teams first like working with a technology, and then come up with technical arguments for why that technology is the best choice.

Words of wisdom (:

Maybe it's not the way things should be, but it's common and very human. Sometimes I'll even catch myself retconning explanations for my choices in my own head, despite myself.

Thanks for writing Modern Fortran!

Looking forward to mojo. Right now it’s not production ready but it’ll great for some of my ML-adjacent code. For other HPC work I’ve used Rust which has some annoying syntax and lacks some of the simplicity of python.

Check out LPython as well (also in alpha): https://lpython.org/

I can recommend this recorded live stream to get an impression of what happens when trying to use Fortran without previous experience: “Learning Fortran in 2023” https://www.youtube.com/watch?v=PvUQndB8R9s

And here is the reaction of the fortran-lang.org people to that and later streams where he went on to implement tic-tac-toe in Fortran using for the GUI the C library raylib (https://www.raylib.com/), for which he made his own bindings live on screen: https://fortran-lang.discourse.group/t/tsoding-on-fortran/61...

Very understanding people from what I see. I might pick Fortran to do my course exercises this year alongside the required use of Python. This might be interesting, and worthwhile.

I wish there were more serious studies on "Matlab risk". There's a lot on $old_lang risk already, and Excel risk is now a serious thread of research, but many in academia (and very possibly greybeards in industrial R&D) just won't budge from Matlab. So e.g. all the codes from my thesis are in Matlab because my advisor wouldn't Python.

Matlab in theory has OO, but it's very slow and who bothers to verify that? So practically everything is matrices and there's very little "semantic expressed in code itself" (to paint issues with a broad brush). Also matrix calculations can get botched numerically, particularly matrix exponentials, but the whole culture (that I can't even expunge from my own thinking) is that I have a theorem so tests schmests.

There’s been numerous articles in nearly every field of science about this!

matlab is incredible for "I have some data, I want do a bunch of calculations and then spit out nice plots". It's why matplotlib is a thing. But not at all well suited for OO / building larger software applications / CI & testing, which is partially at least why the former is the case

Matlab is great for a lot of things, though it's not really a great general purpose language. Its main problem is that it's not free (though octave exists, obviously), which limits interoperability. Octave can trivially be embedded in C++ and Python; if it was easier to do that with Matlab I wonder if numpy would have ever existed...(after all, numpy is essentially a port of Matlab semantics to Python... most Python numeric programmers are unwittingly basically writing Matlab already...).

This process of language love and hatred over a short period is what's called language fad. Ten years ago, people wrote articles praising MATLAB over established languages. I do not recall any of those writings ever mentioning Matlab's licensing as an issue. MATLAB is now >1000 fold better than ten years ago. Yet, the new generation throws it under the bus daily because it's not their favorite. Change is the only constant in the world of programing fashion and language fads.

Underperformance in OO is not why MATLAB is problematic.

I am currently working on a project trying to convert some numerical linear algebra from Fortran90 into Python and was frankly shocked at how much more performant some relatively naive Fortran is, even over using Numpy/Scipy for matrix operations. Orders and orders of magnitude faster. No, I still don't totally understand why.

sorry but maybe give Julia a try?

Did actually switch to that. Surprisingly still a lot less performant than the Fortran code, but at least workable.

make a question post on Julia discourse, many people including me are more than happy to do free work for you!

https://github.com/thornewolf/CFC-Fortran

This is somewhat of a link dump since the code is definitely too hard to interpret for someone not familiar but this is me converting some fairly performant Fortran code to python w/ numba at only a 1-2% performance penalty.

I would absolutely expect python to perform orders if magnitude slower. Even optimal python calling numpy is going through multiple levels of abstraction copying data around. Fortran is raw operations, compiled and with the data packed together.

Why port? Just make it tidier and bind it with f2py so you can use the kernels together with numpy in your glue.

lots of avoidable copies in NumPy, and even if you manage to get rid of that, the python interpretation overhead isn't amortized until your matrix dimensions are in the several-hundreds at least.

I would strongly suspect that you are misusing Numpy in some way.

Python is horrifically slow, everyone knows that, but if used correctly numpy can even the playing field a great deal. I've seen lots of python/numpy written using nested loops, and this is always going to be really really slow.

You're probably doing some unnecessary data movement. Using a modern profiler like scalene might point out where some improvements are possible: https://github.com/plasma-umass/scalene

Consistently separating words by spaces became a general custom about the tenth century A.D., and lasted until about 1957, when FORTRAN abandoned the practice. -- Sun FORTRAN Reference Manual

fortran itself is pretty easy to learn - the stuff people usually have problems with are things like linking with external libraries, job control and the execution environment generally. meh, same with most languages, i suppose.

I've been a bit immersed in pre-Fortran-77 (so FORTRAN-IV and FORTRAN-66). It was an interesting time: FORTRAN was the most standard language, so people used it for things like compilers. An example I have is Motorola's 6800 assembler, which was delivered as a tape for various common machines of the day:

http://www.bitsavers.org/components/motorola/6800/cross-asse...

But this was before FORTRAN had strings.. or even bit-wise operators.. But you could read an input line into an array of integers. Then to read each character from this array, you used integer multiplication and division to perform shifting and masking. Although in this version, I can see calls to assembly language helper functions.

Note the Hollerith constants.. (no strings).

My professor have mentioned Fortran plenty of times and its heavy usage in masssive computations, that's what it is good at and deserves more attention.

When visiting the link, I expected some website written in boring plain text describing its history and docs BUT I was wrong, what a modern website for such a old language. Well done!

TIL "Fortran is a natively parallel programming language". I guess we aren't talking about FORTRAN 77 then.

things have advanced a little since then - speaking as someone that really liked f77 :-) but even way back when i think there were parallel options, if your hardware could support them.

Makes sense, somehow I assumed things stayed the same. Turns out I only know fortran from the memes about it.

The important thing is that old programs and libraries keep working.

Some features were removed from the standard, and modern compilers are much better at detecting errors (and are much stricter than they used to be by default), but all of them have a switch to make them work with random codes from the 1980s.

There is an awful lot of new features on top of that (things like first-class multidimensional arrays language-level parallelism, object orientation, modules, etc), but old software keeps working.

That was my first thought as well. I’ve had researchers running an in-house built Fortran program in the field of genetics on our HPC clusters, such that they’d run their task as 1000s of jobs in the cluster each operating on a small segment of data instead of a single program making use of as many cores available in the system. Perhaps, newer Fortran would’ve done it, but the old software was still reliant on old Fortran.

New and old Fortran is incredibly compatible. Chances are you can rewrite or refactor to add new features directly into or along the old code. If you know what you’re doing.

Fortran 90+ has strong support for parallel programming, including MPI, OpenMP, CUDA and OpenAPI (for GPU).

Why would we be talking about FORTRAN 77 in 2023?

Because there are still codebases in active use and development in FORTRAN 77.

This is an allusion to coarrays, which is a feature from Fortran 2008. It is actually very neat and very nice to program for. There is a C thing that took inspiration from it: https://en.m.wikipedia.org/wiki/Unified_Parallel_C .

Do concurrent loops can also be parallelized.

Yes, a lot of things can be parallelised with OpenMP or MPI, just like in C/C++. These extensions and libraries are not core language features, though.

Very true, and it opens the door to new optimizations which are not possible when going through a library (at least in the case of MPI).

DO CONCURRENT is not a parallel construct. It is a serial loop with arbitrary ordering of iterations, and limitations on data accesses that were intended to ease parallelization but turned out to be incorrect.

I agree that it is not a parallel construct. But it can nonetheless be parallelized if certain criteria are met.

Unfortunately, the necessary restrictions on data accesses to enable parallel execution are not required to hold true in the body of a DO CONCURRENT loop by its botched specification, and neither can they be verified at compilation time. And the committee has known about these problems for many years and has refused to fix them; Fortran 2023 still has them and the topic is not going to be brought up again for Fortran 2028.

So it is possible for a conforming program to be non-parallelizable, due to holes in the default data localization rules, despite the name of the construct and the obvious intent of the long list of restrictions imposed on code in the construct.

I summarized the two specific problems in https://github.com/llvm/llvm-project/blob/main/flang/docs/Do....

It's an excellent essay, and the Fortran community owes you a major gratitude for promoting these issues. But surely there loops can be safely parallelized if the iterations do not interact, e.g. per-element array arithmetic, and a compiler ought to safely identify such arithmetic.

Also, isn't your employer promoting do concurrent as a method of GPU parallelization? Has this been controversial within Nvidia?

Related ongoing thread:

Lfortran: Modern interactive LLVM-based Fortran compiler - https://news.ycombinator.com/item?id=37295144 - Aug 2023 (25 comments)

(other thread is arguably better because less generic)

As to the best of my understanding, Fortran still offers some "fringe", but very important low-level optimization potential, specifically in the areas of pointers and aliases that are important to linear algorithm packages, which are apparently still hard to impossible to recreate in C.

Semi-informed, but serious question: Isn't there any other modern, high-level language that can offer these kinds of optimizations? Preferably in a safe kind of way?

I'm still struggling to understand how Fortran still stays relevant and what could possibly succeed it as a migration (or transpilation?) target with equivalent speed but superior maintainability and safety.

It’s true that Fortran played a fundamental role in the area of numerical linear algebra but most of the linear algebra packages you’re likely using today were written in C or C++.

Why is Fortran relevant? Because of that aforementioned history. However, Fortran’s use in numerical software has steadily been declining (e.g., look at the past two decades of TOMS articles).

Most of the BLAS implementations are in C/C++/ASM, as they're the small performance critical part. The LAPACK layer above that which calls the BLAS to do the heavy lifting is a much much bigger target, and aside from the most commonly used routines (cholesky, svd) most vendors just ship the FORTRAN code (possibly in automatically converted to C form).

One thing I noticed on the page:

> Fortran is a relatively small language that is surprisingly easy to learn and use

I suppose you could say the same of C. C is also a small language, but if you don't know your way around the libraries and tooling you're going to have a bad time. I wonder if the same is true for Fortran.

I suppose that really true for Windows users that only know of msvc. My first time using it was via Linux and gcc and didn't really have any troubles. It's even better today with vscode and clangd.

True, but C and Fortran have very different semantics that make them suitable for very different fields. In particular, C does not have great semantics for linear algebra. Also, C has many footguns due to its use of pointers, while Fortran has virtually none.

You still need to learn the tooling, but the tooling is actually pretty similar for Fortran/C/C++ (same compiler/linker toolchain). Libraries aren't that much of a thing in Fortran, but to the extent that they are, this again is similar to C/C++.

When I learned FORTRAN, I recall each line of code was prefixed by a numeric label. From the “Hello, World!” presented on the website, it looks like that’s no longer the case in modern FORTRAN?

  program hello
    ! This is a comment line; it is ignored by the compiler
    print *, 'Hello, World!'
  end program hello

https://fortran-lang.org/en/learn/quickstart/hello_world/

Labels are no more and no less optional than they ever were; any statement that starts a line may be labeled. Fortran has had IF THEN / END IF and DO / END DO since F'77, so the need for statement labels has greatly decreased. You still see them on FORMAT statements, of course.

I wish these new languages would have some example code on their homepage! ;)

Base Fortran has a lot of advantages for scientific programming over other languages, but I think there are two factors that are contributing to it's unpopularity:

1. Models are increasingly becoming much larger projects where flexibility, configuration, setup, are just as important as the actual number crunching that's done. These aren't areas that Fortran is known for.

2. The existence of libraries like Eigen for c++ provide most, if not close to all, of the advantages that Fortran gives for number crunching.

“I don't know what the language of the year 2000 will look like, but I know it will be called Fortran.” —Tony Hoare

I think it should be corrected to year 3000.

I’m wondering if Mojo will become the next Fortran or the next Python.

If you like both Python and Fortran, checkout LPython: https://lpython.org/, which shares internals with LFortran (https://lfortran.org/), thus delivering exactly the same performance.

Quoting what I wrote a couple of months ago in another thread, regarding the advantages of (Modern) Fortran vs. C/C++:

"""

Just an example on how to declaring a couple of input float pointers in a fully optimized way, avoiding aliases and declaring it readonly (if I remember correctly, it's been a few years:

Fortran:

    real(32), intent(in) :: foo, bar, baz

    const float *const restrict foo
    const float *const restrict bar
    const float *const restrict baz

of course what happens then is that people will do a typedef and hide it away... and then every application invents its own standards and becomes harder to interoperate on a common basis. in Fortran it's just baked in. Another example: multidimensional arrays. In C/C++ it either doesn't exist, is not flat memory space (and thus for grid applications very slow), or is an external library (again restricting your interop with other scientific applications). In Fortran:

    integer, parameter :: n = 10, m = 5
    real(32), dimension(n, m) :: foo, bar, baz

Again, reasonably simple to understand, and it's already reasonably close to what you want - there are still ways to make it better like memory alignment, but I'd claim you're already at 80% of optimal as long as you understand memory layout and its impact on caching when accessing it (which is usually a very low hanging fruit, you just have to know which order to loop it over).

"""

This is such a disingenuous exemple.

You declare all 3 variables on the same line in Fortran but not in C despite it being supported.

In any case, syntaxic sugar is irrelevant.

Yes I do, because in C you do have to repeat pointer declarations and their modifiers per variable - there is no clean way to separate the variable name declarations from their properties

Edit: disagree also on sugar being irrelevant. It’s all about where you guide non engineers towards when they learn it. Domain scientists can be astonishingly productive in Fortran thanks to that - to achieve the same in e.g. C++ takes a lot more effort in training and establishing best practices, libraries etc.

C2x (or any gnu dialect):

    typeof(const float *const restrict) foo, bar, baz;

But yes FORTRAN got the defaults correct for it's applications.

Thanks! Actually wasn't aware of this. Still, not exactly something you want to repeat in every function declaration.

You don't really have to use a pointer in modern C. The recommended practice is to use variably modified types these days[1].

[1]: https://gustedt.wordpress.com/2014/09/08/dont-use-fake-matri...

> Another example: multidimensional arrays.

It depends on what you mean by that, but VMTs are pretty much that.

    size_t n = 10, m = 5;
    typeof((*float)[n]) foo, var, baz;

You still need to initialize those, but that's also quite easy, e.g. to allocate it on the heap: foo = malloc(m*sizeof *foo)

The C equivalent for Fortran stack-allocated arrays is Variable Length Arrays (VLA) which are (afaik) a GNU extension which is usually considered bad.

They are awesome in Fortran because it means that I can (for example) write a function that takes arrays of size N and stack allocate temporaries of size N on entry. I can pass those to other functions etc and they will be freed automatically when I return to my caller. It's actually a really nice feature.

The reason VLAs are considered bad is because they stack allocate non fixed size buffers and the stack is limited. The argument goes that one might as well use a fixed size if you need to use enforce upper bound anyways.

It is possible to heap allocate a VLA too, although the syntax is a bit more cumbersome with pointer access. But it does allow you to pass dynamically sized multi-dimensional arrays to functions and access them with array indexing notation.

VLAs on the stack were introduced in C99. They became optional in C11. They are a GNU extension for C++, though.

BTW, MSVC never supported C99 or VLAs. Recent versions support C11.

Thanks, didn't know they were in the standard (for a while anyway).

In Fortran it is suggested that you define a module with a parameter specifying the working precision of real variables, perhaps with

   module kind_mod
   use iso_fortran_env
   integer, parameter :: wp = real64 ! or real32 or real128
   end module kind_mod

   use kind_mod
   real(kind=wp) :: a, b, c

Then you change your entire program to use single, double or quadruple precision by changing the line that sets wp.

What about in Rust?

    foo: Box<f32> // or &’a f32 or &f32 if borrowing

Multidimensional arrays:

    foo: [[f32; M]; N]

(These have flat storage. However I do assume most Rust devs use external libraries, which also have flat storage but the incompatibility issues you mentioned)

I wish the Python<->Rust interop story was a little better. I learned to write some C++ for an embedded thing (smart flashlight, story for another time) and immediately started writing the Python extensions I struggled to write with Rust.

(The average data science/ML-ish person encounters/figures out custom algorithms maybe three or four times a year, and three of these are fast enough with vectorization contortions. I've had two cases that were recursive and 25X faster in $fast_lang than I could possibly make in Python.)

Crazy to think someone would pass a single 32-bit float by reference.

note: it was just an example. but in the end from a performance optimization standpoint it is a lot about what information you want to give to help the compiler along at doing its best job. with many compilers/languages that tends to be value semantics; however specifically in Fortran, which defaults to immutable reference semantics, reference types tend to be very straightforward to work together with the machine, avoid additional and keep functions inline-able. Overall from my experience this creates a more performant baseline when non-engineers work with it.

Unfortunately, you cannot get the main users of Fortran to use anything other than Fortran 77.

I guess it depends on the field. What I experienced in climate & weather prediction was by and large Fortran 90 codebases.

I don’t think this is true. All the people who got stuck in the 1980s retired. The people I know who write in-house Fortran codes are somewhere in F2003 (all of the multidimensional arrays and allocatable variables niceness, some objects and QoL improvements from F2008/2018). None of them still writes in fixed form, and most of them never did at any point in their careers.

Based on the comments, it seems it is very field dependent. My experience is mostly from physics/electromagnetics. All my fellow grad students learned Fortran 77 as that's what the code bases were in. I should ping the few that are professors to see if they're forcing their students to behave likewise.

It's absolutely true in some domains. I've got several million lines of F77 and no money to update it and an absolute mandate not to change a single compiler flag.

The active Fortran projects I have seen (hydrology) are mostly f90+. That said, they were rewritten over years of dedicated effort and could easily have languished in original form had the federal funding landscape looked different in recent decades.

Fortran is unpopular because programming is fashion driven. That is basically all.

It is very suitable for it’s domain, but it’s old. Programmers have no attention span and love new and shiny things. They would rather reimplement known solutions in new languages rather than struggle with new problems. So perfectly serviceable code and languages get left behind.

“He who knows only his own generation remains forever a child.“ — Alan Kay, quoting Cicero.

Popular culture is also fashion driven, and most programmers are not immune to that.

This is unintuitive, but modern fortran is a shorter jump from Matlab than Python.

The greatness and wretchedness of Python is "pythonicity". It's very hard to miss the mark with Python (all things considered: life is finite, most people are more like analysts than developers, analysts deliver generally more value per hour than developers, Rust is hard to learn) but you basically need to submit to the "Pythonic" brainwashing -- which includes "anything performance-critical should be written in $fast_lang and then used from Python; but almost nothing is perf critical, and most of what's conceivably needed already exists".

There is an element of that, but C and C++ are not young either and have retained more of their peak popularity.

I would wager Fortran is more reliant on a set of users who aren't as familiar with programming as C/Cpp people are. I assume it's easier to sell a language like Python to mathematicians, than it is for people in Computer Science.

These are all assumptions on my part, and my own biases may have affected my understanding of the problem.

Off topic: it's a bit shocking to see that a language like FORTRAN, with its enormous history, has a web page like that of Nim or Vale. It doesn't seem to be an official one, or is it?

My impression, having programmed quite a bit of Fortran, is that it’s not official at all. Also the language is maintained in a completely different way (standards Committee) so it feels off.

It is not official, but several people involved are in one of the standard committees.

There is quite a lot of discussion on the Discourse group ( https://fortran-lang.discourse.group/ ), which also involves both committee members and ordinary developers.

And lots of crazy trolls. Not recommended.

Yes, there is a bit of that, unfortunately. Which is a shame because there are very nice people too.

Yes, there are many nice people there and we are doing what we can to moderate the Discourse so that we can all have a nice place to discuss.

Peter, I am sorry that some users drove you away, possibly myself included. I am personally doing what I can to keep the Fortran open source (and commercial) community together, I have done this before (e.g., with SymPy), and the Fortran community can be very tough in some of the responses. I know most of the people in person, and they are all very nice people.

We regularly address unconstructive behavior. If you or anyone has some feedback how we can run things better, please let me know (you can email me at ondrej@certik.us).

One of the co-founders of the fortran-lang effort. Actually, I would say it is as official as it can be. If you google "fortran", it comes up as first. We provide the home for all of fortran, all of the compilers (commercial and open source), documentation, forum, etc. Wikipedia lists fortran-lang.org as the webpage. Both of the initial co-founders of fortran-lang are part of the standards committee (but the fortran-lang effort is now much bigger than them), and many of the standards committee members are participating in the discourse. I don't think it is the job of the ISO Fortran Standards Committee to maintain a website and a discussion forum, but rather the job is to standardize the language. So it is a complementary effort. To maintain the language has to be an effort of the whole Fortran community, which includes users, compiler writers, the standards committee, and anybody who is able to help.

That’s good news! Fortran has always suffered from too few online resources of good quality. No wonder people prefer other languages - I bought some used Metcalf books, but an online, searchable reference is much better.

I didn’t intend to say that «not official» means «bad». I learned a lot of stuff from «non-official web pages» over the years.

> I didn’t intend to say that «not official» means «bad».

Yes, I know, I understood that. Thank you. I was reacting to the term official, since it is an interesting question what official means for Fortran, since in a way it was "abandoned", there was the ISO committee as the only official body, but nobody wanted to provide an official place for it on the internet (the most official place was actually the Fortran Wikipedia article). So we volunteered that. In a way, I think it could already be treated as official, or if not, hopefully in a few years most people will treat it as the de-facto official. Kind of like the git webpage has migrated from https://repo.or.cz/ to https://git-scm.com/, but both in a way are unofficial, but the second one is a nice modern webpage and most people liked it and accepted it as official. I don't know the people behind either webpage.

Apparently it is.

There's two ways to go on this. They could have done the clean GNU style information-only webpage or the hip hyphy pitch.

The second is probably the right move to respond to the complaint "fortran? Isn't that from like the cold war?"

There's usually a small snippet of example code that does something useless on the splash, often with some typing animation. I'm surprised that's not here. Also where's a cute logo? A purple F is insufficient.

I vote for a sea fan. It's resilient, robust, doesn't seem to die, rhymes with fortran, is basically the same color, you can shape it like an F and the double entendre of "C Fan" harkening back to the classic roots, is there as well

I have not much experience with fortran but I see it as something like cobol - a relict of old times.

I don't think you are getting downvoted because people think you are wrong. Both cobol and fortran are still in widespread use, but primarily for maintained projects that are not well understood even though they still work well. You are getting downvoted because, unlike cobol, plenty of people still like fortran. It isn't a bad language at all, it has had meaningful updates for modern HPC. So people are sad to see it go.

Yes this is exactly what I think. Not nice getting downvote for that. In the future I shut my mouth

It's more like C or C++. Old, yes, but actively developed by a standards committee.

In terms of features, it's definitely more modern than C, with generics, move semantics for pointers etc.

“Actively” is debatable. New revisions arrive at roughly 5-year cadence and some (esp. 2018 and 2023) have been pretty small updates. And implementation uptake since F’95 has been spotty and buggy, so new features aren’t as portable as they should be, standard or not. (See https://github.com/klausler/fortran-wringer-tests for some examples.)

I'm confused why you would post this, and I'm even more confused why it would make the front page. Fortran is a dying programming language, and even if they have a website now, they are still a dying language.

In essence: Fortran, please die more quickly.

Did you take your car this morning? A bike? A plane recently? All these were designed with industrial finite elements codes that are programmed in Fortran. Radioss, Ansys, Abaqus, LS-Dyna, Code_Aster… Fortran is all around you, in your phone that has been designed to survive drop test, the solder creeping of its BGAs, the thermals… Fortran is not dying, it’s supporting your standard of living.

What sort of experience did you have with fortran that led you to feel this way?

I guarantee, the answer is "no experience".

Reply on news.ycombinator.com