What is the advantage of Julia over Fortran?

I’m curious what is the use case for a compiled Fortran program to be small. I thought Fortran was usually run on machines no smaller than a PC? So what is the advantage of smallness for a Fortran program?

Well, if each package takes 100mb and suppose we ship 100 packages in a Linux distro, that is ~10gb. My hard drive has 250gb, and my local Julia packages are taking 30gb already (I need to clean up).

Probably this will be all irrelevant in the future, but it isn’t now. Anyway it is not an advantage.


Imagine writing some code to do analysis of network performance on an embedded router so that the router can auto-tune its queue management software so that people will not complain about buffering and stuttering and dropped packets during their video calls or online gaming sessions. Just an example.

Do people write embedded programs in Fortran?

I assume the answer is yes. I bet a bunch of space satellite stuff is still Fortran for example. Who knows. The point is it’s not impossible.

A better analogy in my opinion would be this one, from a talk I gave about Julia a few months ago. Say you want a toy truck.

The Python/R solution is to look for the appropriate package–like buying a Playmobil truck. It comes pre-manufactured, well-engineered and tested, and does 95% of what you would ever want a toy truck to do.

The Fortran/C solution is to build the truck from scratch. This allows total customization and you can optimize the features and performance however you want. The downside is that it takes more time, you need woodworking skills, and might hurt yourself with the power tools.

The Julia solution is like Legos. You can get the truck kit if you want–which will require a bit more assembly than the Playmobil, but way less than building it from scratch. Or, you can get the component pieces and assemble the truck to your own specs. There’s no limit to what you can put together, and because the pieces all have the same system of bumps, everything snaps together quickly and easily.

Ok, sure. Toy trucks are like linear algebra, though, a common request, and every “toy system” will have an implementation that works basically fine. But what if you want a time-traveling sailing/space ship with lasers AND dragon wings? And it should be as easy to build and use as a basic dump truck?

There’s a reason that only Lego ever made anything like Dr Cyber’s Flying Time Vessel :wink:


I’m going to steal use this awesome example crediting you in my next talk about julia


@EIOceanografo, that is a really really cool presentation you gave there. Would It be okay to use them while crediting you? Thanks for the awesome slides!

1 Like

4 posts were split to a new topic: Validity of package documentation and examples

Yes, that’s also the rationale given in the documentation. I think it’s the wrong default: we should ensure reproducibility by default, and adding a devtools environment should be very easy, but opt-in.

(I guess this discussion of reproducibility could also be split into its own thread…)


This is such a good analogy!

1 Like

None that I know off. Most of it is C and C++ but there might also be some hardware running Forth still flying around. There is a lot of Fortran in the ground systems, though. Especially in orbital dynamics.

Speaking of which, here’s why I have not touched my Fortran code in years. The obvious benefits of interactive dynamic environments (REPL, plotting, less boilerplate) have all been mentioned. Modern Fortran is still very performant with little effort and IMHO a much better choice for technical computing than C++.

It is also true that Fortran77 is super portable and runs everywhere. In my experience, this was not true at all for Modern Fortran (Fortran2003+) five years ago. I needed to support 4-5 different compilers including Intel Fortran on Windows and some ancient GFortran which was an absolute nightmare. There were even miscompilations and compiler crashes when using “modern” features. In the end, I dumbed down my code to “Fortran95 with benefits”, shipped it to the client to fulfil my contract, and have not touched Fortran since :see_no_evil:


Fortran compilers have improved a lot recently (I agree the adoption of Fortran 2008 by the compiler vendors was very slow and agonizing, partly due to the significant distributed parallelism component of F2008). Intel, Cray, and NAG compilers already fully support Fortran 2018, which is quite impressive given the complexity of the native advanced parallelism features of Fortran 2018 (teams, events, …). GFortran covers a significant part of the Fortran 2018 (including the Coarray parallelism paradigm of F2018 thanks to the OpenCoarrays open-source library). NVIDIA has started a new LLVM-based Fortran 2018 compiler, which is a work in progress. Still, their classic (PGI) compiler does not support the Coarray parallelism features of F2008 and F2018, similar to the IBM compiler. These are the major players, but others like Absoft, Silverfrost, PathScale, Oracle, etc., partially support modern Fortran. Here is a relevant recent article on the use of modern Fortran in NASA missions.


Yes, by all means!

Paywall :frowning:

NASA publications can always be found on NTRS: https://ntrs.nasa.gov/api/citations/20180000413/downloads/20180000413.pdf


The big thing I don’t like about Fortran is that it always looks like it’s yelling at me.

1 Like

Does it still? Fortran Programming Language


Huh – today I learned they renamed it from FORTRAN to Fortran a while back, and FORTRAN has just stuck around for a while.

(To be clear, my comment was a joke.)


Pretty sure I have told this story around here before but here it goes:

I was once admonished during peer review for misspelling FORTRAN as Fortran. I replied that FORTRAN has been called Fortran since Fortran90.