# What is the advantage of Julia over Fortran?

**URL:** <https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964>\
**Category:** General Usage\
**Tags:** fortran\
**Created:** [August 6, 2021, 9:03pm UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964 "2021-08-06T21:03:32Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 9, 2021, 12:17pm UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/42 "2021-08-09T12:17:47Z")

</div>

> [@ufechner7](#):
>
> Well, ModellingToolkit cannot produce C code for embedded systems. And it has no graphical interface like Simulink…

You named two things that are almost there, the latter though is still a bit in development but should have some form released by the end of the year. See:

[![](https://global.discourse-cdn.com/julialang/original/3X/3/6/368ca9a3a6dbf9d759131c1aedaece7434fecaa5.jpeg "JuliaSim: Machine Learning Accelerated Modeling and Simulation | Chris Rackauckas | JuliaCon2021") ](https://www.youtube.com/watch?v=lNbU5jNp67s)

Control engineers coming from Simulink seem to be the main people adopting right now, since at lot of them are getting a nice ridiculous speedup. [structural\_simplify bug (I think) · Issue #1178 · SciML/ModelingToolkit.jl · GitHub](https://github.com/SciML/ModelingToolkit.jl/issues/1178) is today’s but there was a 2 hour to seconds in waste water management the other day, the NASA launch services one that I mentioned in the video, etc. So it’s still a little in progress but that’s probably one of our biggest near term growth areas. It’s the target market for the set of tools coming out over early 2022.

---

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [August 9, 2021, 12:27pm UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/43 "2021-08-09T12:27:02Z")

</div>

> [@shiroghost](#):
>
> Fortran code will run as it is in 15y. Julia code… I seriously doubt it…

I may have missed a subtlety here, but are you talking about old fortran code running on a new fortran version (and equivalently old julia code running on a new julia version) or are you talking about the old code running on the same old language version, just in the future?

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 9, 2021, 12:30pm UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/44 "2021-08-09T12:30:39Z")

</div>

Just read through this… the two languages are very different with one focusing on dynamism, multiple dispatch, homoiconicity/metaprogramming, and interactivity. The other is has a solid minimal syntax, OOP, and generates very optimized binaries. There are some similarities but they are rather different in workflows and complement each other well. I don’t get all the fuss, I like both and I don’t see how Fortran is a language for something like robust metaprogramming mixed with symbolic arithmetic, while Julia is a bit harder to perfect performance because Fortran just won’t work if it’s not performant. Just two different focuses.

---

<div class="post-metadata">

**Author:** ![oheil](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oheil/32/220745_2.png) [@oheil](https://discourse.julialang.org/u/oheil)\
**Post date:** [August 9, 2021, 12:33pm UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/45 "2021-08-09T12:33:15Z")

</div>

> [@ChrisRackauckas](#):
>
> I don’t get all the fuss, I like both

That’s nearly always the last conclusion when comparing two languages (well, sometimes I only like one of them). 🙂

---

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [August 9, 2021, 12:37pm UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/46 "2021-08-09T12:37:21Z")

</div>

> [@ChrisRackauckas](#):
>
> while Julia is a bit harder to perfect performance because Fortran just won’t work if it’s not performant.

I would say that with Julia it is easier to get a lousy performance. When it comes to “perfecting” performance, it comes down to improving algorithms and implementation details, and with the current tooling and dynamism that is easier with Julia.

---

<div class="post-metadata">

**Author:** ![rafael.guerra](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rafael.guerra/32/216610_2.png) [@rafael.guerra](https://discourse.julialang.org/u/rafael.guerra)\
**Post date:** [August 9, 2021, 12:47pm UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/47 "2021-08-09T12:47:10Z")

</div>

A major advantage of Julia, as reported here in Discourse many times by people with a scientific background but who are not computer scientists nor the best programmers: _after reading a technical article describing some advanced algorithm, a few hours were enough for them to implement concise Julia code whose syntax was identical to the mathematical notation used in the original article._

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [August 9, 2021, 3:20pm UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/48 "2021-08-09T15:20:34Z")

</div>

> [@lmiq](#):
>
> I would say that with Julia it is easier to get a lousy performance. When it comes to “perfecting” performance, it comes down to improving algorithms and implementation details, and with the current tooling and dynamism that is easier with Julia.

Julia also makes it easier to go lower level than is possible in Fortran for really perfecting performance.  
Writing optimized BLAS is a lot easier than Julia than it would be in Fortran IMO.

---

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [August 9, 2021, 6:06pm UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/49 "2021-08-09T18:06:48Z")

</div>

Is JuliaSim a closed-source proprietary commercial product or an open source tool?

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 9, 2021, 6:33pm UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/50 "2021-08-09T18:33:54Z")

</div>

Still proprietary, like Simulink and for similar reasons. Though we should probably keep this thread on topic.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [August 9, 2021, 8:10pm UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/51 "2021-08-09T20:10:10Z")

</div>

A few points regarding compatibility, reproducibility and encodings:

1. We take not making breaking changes in 1.x releases of Julia very seriously. We test _every_ registered package in the entire open source ecosystem with _every_ release to make sure we haven’t accidentally broken anything.

2. We keep [binaries for every Julia release](https://julialang.org/downloads/oldreleases/). As noted, they’re easy to install and use alongside each other. This is notably not the case for most C, C++ or Fortran compilers, which like to assume they own the entire system — if you want to use more than one version of gfortran at the same time, you’re going to need containers. The upshot is that if you need an old Julia version for whatever reason, you can easily install and use an old version just for one specific project.

3. While Julia 2.0 will by definition be somewhat breaking (or it would just be 1.x for some value of x), it seems like FUD to suppose that a release that hasn’t yet been made will change everything and break everyone’s code. Especially given that we’ve said the opposite many times: [the way Julia code looks and feels is done](https://discourse.julialang.org/t/psa-julia-is-not-at-that-stage-of-development-anymore/44872). I’ll say it again: we are not interesting in making gratuitous annoying changes in Julia 2.0. I wrote more about the kinds of changes that are of interest [here](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/47). In short, the vast majority of Julia 1 code will keep working in Julia 2.

4. The way Julia’s package manager works, when you have a Julia project, it gets its own project environment and the manifest file records the exact Julia version (as of Julia 1.7) and the exact version — down to the last bit — of every package dependency (since Julia 1.0) and every binary dependency (since Julia 1.3). You don’t need containers for perfect reproducibility. On the other hand, you cannot achieve this level or reproducibility in C or Fortran without containers — if you code depends on any libraries at all, you are at the mercy of whatever versions of those libraries happen to be installed on your system, and while Fortran the language is very careful about breaking changes, many libraries are not. As a result, you may not be able to compile your project at all, let alone get it to work as it once did. This is not a problem in Julia thanks to manifest files and immutable, content-addressed packages and binary artifacts.

5. Since Julia 1.5, packages and binaries are downloaded from package servers at [pkg.julialang.org](http://pkg.julialang.org) which are maintained by the Julia project and which are backed by a replicated system of storage servers that preserve copies of every package and artifact version that anyone ever installs through the package servers (both registered and _unregistered_ versions of registered packages). That means that if you have a manifest that you instantiated via Julia’s package servers once, you will be able to install it forever. This is completely decoupled from GitHub and will continue to work even if GitHub disappears.

6. ASCII is certainly a venerable standard, but at this point Unicode is no less respectable and is certainly [standardized](https://unicode.org/standard/standard.html). We’re not just making this stuff up. Julia source is UTF-8, which is a [brilliantly designed](https://hackaday.com/2013/09/27/utf-8-the-most-elegant-hack/) and carefully specified superset of the ASCII encoding and rapidly becoming [_the_ encoding](https://w3techs.com/technologies/history_overview/character_encoding/ms/y) that is used everywhere for everything.

---

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [August 9, 2021, 8:22pm UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/52 "2021-08-09T20:22:45Z")

</div>

I suspect the mention of ASCII may have been a typo and ANSI was intended (see [ANSI Standard Fortran](https://en.wikipedia.org/wiki/Fortran#Transition_to_ANSI_Standard_Fortran)), the focus being on community standardization.

The concentration of Julia influence at one company may concern some people with a long-term community focus. PostgreSQL for example has a rule that not too many of the core contributors can be at the same company.

---

<div class="post-metadata">

**Author:** ![CRquantum](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/crquantum/32/27824_2.png) [@CRquantum](https://discourse.julialang.org/u/CRquantum)\
**Post date:** [August 9, 2021, 11:03pm UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/53 "2021-08-09T23:03:37Z")

</div>

> [@lmiq](#):
>
> I would say that with Julia it is easier to get a lousy performance.

Could you perhaps give a little bit more small examples on perhaps why Julia might be easier to get a lousy performance, and how to improve it? Thanks!

---

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [August 10, 2021, 12:12am UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/54 "2021-08-10T00:12:33Z")

</div>

1. Use non-constant global variables. Solution: don’t use them. (In Fortran this is a non-issue because all variables have defined types, although not using them is a good practice anyway).

2. Allocate arrays inside loops. Solution: preallocate and reuse, or use static arrays. (In Fortran, even if a code needs to allocate, it is almost certain that stack allocations will be used and you get the “static arrays” behavior for free).

---

<div class="post-metadata">

**Author:** ![Juliet](https://avatars.discourse-cdn.com/v4/letter/j/97f17d/32.png) [@Juliet](https://discourse.julialang.org/u/Juliet)\
**Post date:** [August 10, 2021, 1:05am UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/55 "2021-08-10T01:05:49Z")

</div>

> [@lmiq](#):
>
> Allocate arrays inside loops. Solution: preallocate and reuse, or use static arrays. (In Fortran, even if a code needs to allocate, it is almost certain that stack allocations will be used and you get the “static arrays” behavior for free).

unless heap allocation is explicitly requested by a compiler flag.

---

<div class="post-metadata">

**Author:** ![amrods](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/amrods/32/2543_2.png) [@amrods](https://discourse.julialang.org/u/amrods)\
**Post date:** [August 10, 2021, 1:05am UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/56 "2021-08-10T01:05:56Z")

</div>

> [@lmiq](#):
>
> Allocate arrays inside loops. Solution: preallocate and reuse

I have read this many times but I don’t know what that means, not being a software developer. Without derailing the conversation, can you quickly point me to anywhere I can learn about that?

---

<div class="post-metadata">

**Author:** ![johnmyleswhite](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnmyleswhite/32/31_2.png) [@johnmyleswhite](https://discourse.julialang.org/u/johnmyleswhite)\
**Post date:** [August 10, 2021, 1:36am UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/57 "2021-08-10T01:36:21Z")

</div>

This is simple enough there may not be a single page focused on this. An example of the reused allocation pattern is that instead of doing this:

```julia
using Statistics
means = zeros(10_000)
for s in 1:10_000
    x = rand(100)
    means[s] = mean(x)
end

```

You should do this:

```julia
using Statistics, Random
means = zeros(10_000)
x = zeros(100)
for s in 1:10_000
    rand!(x)
    means[s] = mean(x)
end

```

Here you go from allocating `x` inside the loop to pre-allocating it and reusing it.

---

<div class="post-metadata">

**Author:** ![amrods](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/amrods/32/2543_2.png) [@amrods](https://discourse.julialang.org/u/amrods)\
**Post date:** [August 10, 2021, 1:50am UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/58 "2021-08-10T01:50:23Z")

</div>

can it be done “manually”, without using `rand!`? (sorry, off topic)

---

<div class="post-metadata">

**Author:** ![CRquantum](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/crquantum/32/27824_2.png) [@CRquantum](https://discourse.julialang.org/u/CRquantum)\
**Post date:** [August 10, 2021, 5:43am UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/59 "2021-08-10T05:43:21Z")

</div>

Since Julia is aiming at writing concise/elegant/beautiful code without sacrificing performance.  
I would wish that Julia be perhaps a little bit more intelligent/powerful in automatically optimizing situations like this 😀

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 10, 2021, 5:49am UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/60 "2021-08-10T05:49:44Z")

</div>

See [https://github.com/JuliaLang/julia/pull/41777](https://github.com/JuliaLang/julia/pull/41777)

---

<div class="post-metadata">

**Author:** ![ranocha](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ranocha/32/35588_2.png) [@ranocha](https://discourse.julialang.org/u/ranocha)\
**Post date:** [August 10, 2021, 6:18am UTC](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964/61 "2021-08-10T06:18:57Z")

</div>

If you’re coming from Fortran to Julia for heavy number crunching, one performance aspect you might notice is just caused by Julia using the LLVM compiler, which doesn’t generate [fused multiply-add (FMA](https://de.wikipedia.org/wiki/Fused_multiply-add)) instructions by default. Thus, you need to opt-in explicitly. Luckily, Julia’s code introspection and manipulation tools make it relatively easy to do, using for example `@fastmath` from Base or `@muladd` from [MuladdMacro](https://github.com/SciML/MuladdMacro.jl). I have described that in a [blog post on optimizing our hyperbolic PDE framework Trixi.jl](https://ranocha.de/blog/Optimizing_EC_Trixi/#step-2-investigating-the-logarithmic-mean-in-fluxo-fortran-and-trixi-julia).  
Nevertheless, I definitely like using Julia (since v0.3 many years ago…) in my daily work as scientist working in numerical analysis and applied mathematics. We describe some of the nice aspects in our [JuliaCon talk on Trixi.jl](https://youtu.be/hoViWRAhCBE). Our team has a strong background in C, C++, and Fortran. Most of us have used an HPC Fortran code before. In our talk, Michael describes why we started to work on a new Julia code ([Trixi.jl](https://github.com/trixi-framework/Trixi.jl)) and what we like about it. We still have a lot to do, in particular on the HPC side, but we’re pretty happy at the moment. Having said this, the Fortran code is of course still in use and will probably stay alive for quite some time.

[Previous page](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964.md?page=2)

[Next page](https://discourse.julialang.org/t/what-is-the-advantage-of-julia-over-fortran/65964.md?page=4)