Julia gets mentioned in an article about FORTRAN

Regardless of the specifics, it is nice to see Julia popping up in non-Julia related articles.


What I find intriguing in that article is the mention of the compiler from FORTRAN to LLVM (Ondrej Certik @certik), the LFortran. This might make it possible to include FORTRAN source files in a Julia program, might it not?

Well, the same reasoning should extend to C source files, no?

1 Like

Actually the quote is due to Certik:
“One way to think about Julia is that they took Python, and made it fast,” he says. “With LFortran, we are trying to go the opposite route: take a fast language like Fortran and see how interactive you can make it.”
From the article This old programming language is suddenly hot again. But its future is still far from certain

So if someone so conversant with Python has trouble distinguishing between those two,
I think we have a communication problem.


Tesla? Checkout the timeline.

1 Like

My name is Ondřej Čertík, who was quoted in the article.

I did a video interview with the author of the article, but I have not seen any draft prior to publication. When I read it, I wish I was quoted a bit differently, or to put more context into it, not just a short quote. Note that I told this exact quote to @StefanKarpinski several years ago (in person at a NumFOCUS meeting in NYC) and he did not object to it being completely inaccurate.

But it seems that a lot of people in the Julia community do object to this characterization.

Would any of you be willing to do a video call with me to discuss this further, so that next time I mention Julia, I characterize it more accurately?


Let me try to put it in context as I see it:

  • Julia: let’s keep the advantages of Python being interactive, easy to learn, “duck typing”, etc. Now let’s see how we can fix the main flaw: speed. To do that, one has to introduce types, use LLVM from the beginning, figure out the semantics in a way so that it can be compiled to be fast, etc. Modify the language a bit. Since we are introducing a new language, let’s also do some other cool stuff, such as multiple dispatch.

  • LFortran: let’s keep the advantages of Fortran being very fast, simple language, easy to learn and possible to write large codes in. Now let’s see how interactive we can make it.

I can do others too:

  • Rust: let’s take C++ and keep: fast, ahead of time compilation, generic programming. Now let’s fix some of the flaws: fix unreadable template error messages and provide excellent error messages in general, fix memory safety bugs, provide a good build system and a package manager (Cargo). Things that Rust didn’t fix (in my subjective opinion): slow compilation, large language with a steep learning curve.

  • Go: take Python, keep easy to learn, small language. Make it faster (but not necessarily as fast as possible) and ahead of time compiled, to better support building and maintaining larger code bases. (I think there is more to say about Go, I am not too familiar with it.)

I know that the above is necessarily simplified, but for people that know Python, C++ or Fortran and their pros/cons, it provides a quick intro into the other languages (Julia, Rust, Go) and where their strengths and weaknesses could be relative to the languages that they know.


Hi Ondrej,

Thanks for your efforts to learn about Julia. I wonder whether your lfortran could benefit from Julia? Why not drive the interactive part from Julia? You just translate fortran to llvm, and then run from Julia.

1 Like

I think LFortran can greatly benefit Julia in multiple ways. Right now we are concentrating on delivering a minimal viable product (MVP) to compile some simpler Fortran codes (MVP: Roadmap to compile the SNAP project (#313) · Issues · lfortran / lfortran · GitLab), but after that here are some ideas:

  • We plan to write a Julia backend (besides the LLVM and C++ backends) that can translate Fortran to Julia. So for people that want to move away from Fortran or just take some Fortran code and use it as a basis and continue development in Julia, this should work great.

  • Julia wrappers: for codes that should stay in Fortran, but just being usable from Julia, the LFortran compiler should generate good wrappers (with native Julia arrays, etc.). So when you are in Julia, let’s say the REPL, you could call any Fortran function / module directly, and LFortran takes care of the details.

  • Julia to Fortran: in order to use Julia libraries from Fortran, it would be nice to call them from Fortran easily. This requires some brainstorming, but I think it is possible at least for a subset. LFortran would infer from the way you call a certain function in Fortran how it must be called from Julia.

  • (The same for C++ and Python)


Hi and many thanks for interacting so nicely with this community! I hope you don’t mind but I just have to ask you: why are you doing this? I understand the motivation for keeping old codes running and developing features in them instead of rewriting them from scratch, but do you actually advocate Fortran for new projects? I ask because to my mind, julia is a strict improvement on Fortran in every aspect (at least at the language level; some tooling is still missing), so I’d be interested to hear your point of view.

(FWIW, you could describe julia in the reverse way as you do: “hey, this fortran thing is fast and has first-class support for arrays and complex numbers, shame it’s so low level and every function has to be twenty lines long, let’s simplify it a bit, and make it interactive while we’re at it. Oh and to do fast untyped math we basically have to do multiple dispatch, so let’s build the language around that.”)


@antoine-levitt thank you.

(Yes, good idea to do it both ways with the language comparisons.)

Regarding why I do this, we tried to explain our motivation for LFortran in particular in the following two blog posts:

I think they answer most of your questions (yes, I advocate Fortran for new projects). The motivation and history behind fortran-lang.org is described in my blog post here:

Fortran is also missing tooling, but we are working on fixing that.

My personal view is that I have no doubts that Fortran has not reached its full potential yet, so it’s hard to say how things would look like once tooling is improved, there is a community (fortran-lang.org), package manager (fpm), standard library (stdlib), LLVM based compilers (LFortran, Flang, Intel ifx, …), it works interactively (Jupyter), etc. Regarding speed, if I was designing a new language that makes it easy for compilers to optimize, it would probably be something like Fortran: as much mathematics in the language itself. Once LFortran matures, I plan to look at that more closely. If anyone of you have some code or benchmark that is faster in Julia than in Fortran, let me know and I’ll have a look.


I guess that makes sense: if your criterion for designing a language is absolutely zero compromises on speed ever, then probably you can’t do much better than Fortran. The problem with this is that not all parts of an application is performance-critical, and at one point you’re going to write a parser, architecture a large application, pass functions around, call other libraries - and then the trouble starts in Fortran. Julia has a different compromise: it makes it possible to write as-fast-as-fortran code, but it doesn’t force you to do it all the time - basically you can switch from writing python-style code in one function to write fortran-style code in another. As a result there are a few performance gotchas, but those are easily learned and worked around. Regarding speed, the performance of optimized julia and fortran is basically equivalent - it comes down to differences in compiler or similar considerations.


Yes, the devil is in the details. :slight_smile: I will have more to say on this performance topic in about a year, right now I am still focusing on basic compilation (just generating correct LLVM code).

I don’t want to spread too thin right now, but down the road I would love to have side by side comparisons of Fortran, Julia, Python/NumPy, C++, etc. I have done this for Fortran/Python about 10 years ago here: Python Fortran Rosetta Stone — Fortran90 1.0 documentation, but it would be nice to add more languages, modernize and also do more complicated examples.


Except one.

Being able to produce small (or not that small) stand-alone executables. IMO this is a major feature that non-interactive language users have troubles to comprehend.


Many things I like about fortran.

One is intent(in) and intent(out), another is writting out all variables explicitly.

This is why so many autodiff scientists like using it to try out new ideas (such as Tapenade).


A different perspective.

I think “Python but fast” is a good way to explain Julia to programmers who have never heard of it. The main differences are

  • speed - fast enough that it doesn’t need C extensions. CPython is notoriously slow on many tasks. I think speed is the biggest difference between CPython and Julia, because it avoids needing C extensions in many cases. The original “Python but fast” is PyPy, whose speed has been hampered by maintaining compatibility with the old CPython C-API; recently the Hpy project has started work on replacing that API. I suspect (without evidence) that if PyPy had been available when the scientific Python stack was being written (around 2000), then Python’s scientific libraries wouldn’t need so many C extensions either, and that stack could’ve been implemented with much more Python and much less C.

  • multiple dispatch - has some ecosystem effects like encouraging more array types. I don’t think this has as much impact yet as it could, mostly because Julia lacks interfaces. Without an interface definition system, APIs are inconsistent, unreliable, and have unclear semantic relationships. I don’t think “automatic interoperability” is scalable in practice under an informal manual model. This is why Clojure has Spec and why Python has protocols/zope interfaces/ABCs.

  • macros - Allow more concise syntax in some cases. Python might get these soon though they often do more harm than good. Julia’s hygiene is complicated.

  • uniform packaging story - Having a single declarative packaging tool makes it easier to statically analyze and manipulate packaging metadata. Python has good packaging systems now with Poetry and Conda, but there’s a ton of existing code that doesn’t use systems like these.

Python and Javascript are maybe the most-used languages in the world, so it makes sense to compare to them when possible. But the comparison is also pretty natural.

On the similarities. I’ll pick some features and compare Julia and Python to alternative choices other languages have made.

  • Easy to start. print("hello") just works. Compare to Java which needs public static void main(String[] args) which can overwhelm a beginner before they even start.

  • Significant focus on scientific applications. Contrast with Common Lisp, a fast lisp with a smaller scientific user focus.

  • Syntax. Mostly M-expressions but with some reserved keywords like continue and while. Contrast with Scheme, which uses S-expressions only.

  • Built-in repl. Contrast with C++, which is often used in scientific applications but doesn’t have a repl.

  • Dynamic typing. Values are tagged with their class at runtime. Contrast with C++ again.

  • Static type annotations. Both have a system for optionally declaring types which helps with reliability and documentation when used. Contrast with C++ which has required static annotations and Clojure which doesn’t have any.

  • Mutability. In both languages, mutable state is widely used. Contrast with Haskell which mostly disallows this.

  • Ability to evaluate code as data. Julia has syntax sugar :(a + b) which can be written in Python as ast.parse("a + b"). Since the distinction between compile time and run time is fuzzy under JIT compilation, these are more similar than they look. Python also has builtins compile() and eval(). Contrast with Go which doesn’t have this.

  • Program distribution. Run under the preinstalled runtime executable. Contrast with Go which makes static executable binaries.

  • Strings. Strings are sequences of code points. Contrast to Swift which uses extended grapheme clusters.

  • Partial extensibility. Users can define the value of the booleanized version of their expression, but can’t control the behavior of if or overload dispatch. Contrast to CLOS which lets users control dispatch.

  • Garbage collection. Allocated space is collected automatically by a garbage collector. Contrast to C and Rust which don’t have this.

  • Batch garbage collection. Latency can be inconsistent under this model, which is relevant in some applications. Contrast to Go, which considers GC latency an “existential threat” and designed its garbage collector to minimize latency.

  • Hard to control low-level performance-sensitive properties. For example, there is currently no way to disallow allocations in either language. Contrast to C, which makes allocations more explicit.

  • Unrestricted use of foreign objects. You can access private data on any object. Contrast to Java which disallows this.

All in all, I don’t think Julia in 2021 is as different from Python as some users might – except for tuned speed – but that’s not necessarily a bad thing: Python is popular for good reason. Julia is immature in comparison and hasn’t yet figured out its story on a lot of things, such as traits and interfaces, which are promising future directions (among many others). Julia’s capabilities are likely to mature over time in ways we haven’t seen yet.


Julia lets you turn off/on GC using gc_disable() and gc_enable(). This can be really useful in some performance sensitive cases.

1 Like

Python has gc.disable() for the same.

I agree with this; also multithreading, debugging and profiling lags behind Fortran. This is what I meant by “tooling”.


i thought multithreading was easier in julia, when i talk to people who use fortran they mention mpi and other demons.