Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

So I don't doubt that "modern Fortran" is a nice language, but last I'd heard, it also effectively didn't exist in the wild; Fortran remains king of numerical computation by virtue (largely if not exclusively) of having a vast number of packages already written spanning decades of use... but not, generally, spanning to new versions of the language. So is it good enough to use the language in spite of its ecosystem?

View on HN

No.

I write Fortran professionally and it is a real pain in the dick to get anything done. It has some nice SIMD and matrix operation syntactic sugar but that is about it.

If you want to get anything useful done you are better off writing in another language.

The Fortran ecosystem is running on fumes from the inertia of these massive legacy code bases that no one wants to pay to rewrite. But then complain that it is expensive to get anything done in them.

This surprises me. I wrote a lot of Fortran doing research and found it very strong for numerics. Having first class multidimensional arrays with debuggers being able to understand slicing operators is a nice boost for productivity, because half the time is often spent figuring out why two results don’t agree. The main missing feature was generic functions and that’s where I think Julia brings some real advantages to the table. But SIMD, multicore, MPI and GPU support is afaik. still more mature on Fortran and that’s where it counts when programming cluster applications.

I agree with you that Fortran is running on more than just legacy here. At the same time, I also think Julia has caught up a lot as far as SIMD, multicore, MPI and GPU.

For SIMD, Chris Elrod's LoopVectorization.jl [1] is an (IMHO) incredibly impressive piece of work (which incidentally provides the foundation for I think the first pure Julia linear algebra library competitive with BLAS).

Multithreading is pretty easy with things like `@spawn`/`@sync` and `@threads for` in the base language, as well as super low-overhead multithreading from the Polyester.jl [2] package (which LoopVectorization also uses to provide a version its vectorization macro that'll also multithread your loops in addition to SIMD-vectorizing them).

MPI.jl [3] has been totally problem free for me, though I wouldn't be surprised if the Fortran bindings still have an edge somewhere, and Cuda.jl [4] seems to provide pretty seamless GPU support which should play nicely with MPI.jl's Cuda-aware MPI [5], but I don't work as much with GPUs myself.

[1] https://github.com/JuliaSIMD/LoopVectorization.jl

[2] https://github.com/JuliaSIMD/Polyester.jl

[3] https://github.com/JuliaParallel/MPI.jl

[4] https://github.com/JuliaGPU/CUDA.jl

[5] https://juliaparallel.github.io/MPI.jl/latest/usage/#CUDA-aw...

What about debuggers? For Fortran there are some powerful commercial debuggers available, incl. Parallel debugging and even reverse debugging (being able to step backwards based on snapshots).

I tend not to use debuggers very much myself so not speaking on a ton of expertise, but I think it's probably safe to say the Fortran ones are going to be a lot better on that front. There are a few options for debuggers so far, but no parallel ones that I know of yet.

It depends a bit on what you want, but https://rr-project.org/ works really well with julia

What Fortran standard have you used? About your specific pain, you need to visit a doctor, it is unrelated to Fortran or programming in general.

It's true that many of the famous Fortran libraries such as Lapack are Fortran 77 or close to it. However, there are lots of projects using modern Fortran, especially at universities and national labs, in the areas of astrophysics, computational fluid dynamics, earth science, climate and weather prediction, and electronic structure and quantum chemistry. A list of GitHub Fortran codes by category is at https://github.com/Beliavsky/Fortran-code-on-GitHub .

From the article:

> The idea of introductory languages is not necessarily that they are suited to commercial endeavors, but rather that they are (i) easy to implement algorithm in, (ii) readable, and (iii) do not contain things that will confuse and bewilder.

As for FORTRAN in the wild, there are many simulations used by the US government still in use, example like Enhanced Surface-to-Air Missile Simulation (ESAMS).

Would it be a good language to use outside of specialized needs? Probably not.

I'm not questioning Fortran in the wild, I'm questioning modern Fortran in the wild. Are those simulations Fortran 2008, or FORTRAN 77 that nobody dares touch?

There's modern stuff being written in astro(nomy/physics) (I can attest to some of the codebases listed in https://github.com/Beliavsky/Fortran-code-on-GitHub#astrophy... being modern, at least in terms of development), but I'd say C++ likely does have the upper hand for newer codebases (unless things have changed dramatically last time I looked, algorithms that don't nicely align with nd-arrays are still painful in Fortran).

I've also heard rumours of Julia and even Rust being used (the latter because of the ability to reuse libraries in the browser e.g. for visualisation), but the writers of these codebases (and the Fortran/C/C++/Java) are unusual—Python and R (and for some holdouts, IDL) are what are most people write in (even if those languages call something else).

As much as C11, C++11, Java 11, C# 8, Python 3, and later exist in the wild.

After a certain threshold is very hard to get people to move on when the IT managed compilers just work, and coding isn't a full time activity.

Reply on news.ycombinator.com