<p>As a former Fortran programmer I did a small online review several weeks ago into current trends for scientific programming.</p>
<p>To begin with, despite its age and its sometimes archaic style of programming, because of its huge legacy, Fortran isn't being directed to the trash can in a hurry. It's going to be used for a long time to come.</p>
<p>Like you, others have been looking for an alternative to start the move away from Fortran.</p>
<p>Though very popular, Python is very <strong>slow</strong> when executing programs. The speed of Fortran is another reason why it is still being used.</p>
<p>For astronomical and physics applications, I've seen a number of references state a preference for initially teaching students Fortran but when they get more experienced in their field exposing them to C++.</p>
<p>This comment from 2013, from a <a href="https://www.physicsforums.com/threads/best-programming-language-for-physics.719723/" rel="noreferrer">Physics forum</a> encapsulates the general ideas I seen:</p>
<blockquote>
<p>The older guys use fortran and c++. The younger people use python,java,and c++.</p>
</blockquote>
<p>As with your answer, I think if Julia was more widely used it could have the potential to replace Fortran and possibly Python for scientific computing.</p>

CC BY-SA 4.0
2020-11-12T23:06:45.077Z
Thanks for sharing. I know that Python *could* be optimized by calling into C or Fortran, but I just don't think that such optimization is going to happen with our team. Therefore, I am seeking a language that is *fast by default*. Julia seems to deliver much better on this "fast by default" promise, whereas Python is more like "fast if you have the right optimizations in place".
Mike76
CC BY-SA 4.0
2020-11-12T23:09:29.373Z
For our group, having a gigantic language-community isn't that important, as long as it is a well-maintained language. All we need is NetCDF and basic matrix-operations, so we could give Julia a try even if it isn't as mature as Python.
Mike76
CC BY-SA 4.0
2020-11-12T23:16:50.473Z
@Mike76: If a lot of number crunching is involved, speed of processing is important. From reports of speed bench mark studies I've seen on line, in order of speed, the fastest 3 languages generally are C, C++ & Fortran. Julia is usually in the next tier of languages at positions 4, 5 or 6. I'd recommend Julia.
Fred
CC BY-SA 4.0
2020-11-12T23:20:18.347Z
From what I have seen, Julia is "close to native performance". This seems to be good enough; I am willing to sacrifice a small bit of performance in order to overcome the slow development cycles of C/C++/Fortran.
Mike76
CC BY-SA 4.0
2020-11-12T22:51:43.337Z
2020-11-12T22:51:43.337Z
Fred
<p>Right now, I think that <code>Julia</code> makes the cut, because it provides a great tradeoff between &quot;fast scripting&quot; and &quot;high-performance scientific computing&quot;.
But I am willing to hear other people's opinions, perhaps I have overlooked something.</p>

CC BY-SA 4.0
2020-11-12T22:14:15.680Z
2020-11-12T22:14:15.680Z
Mike76
<p>You could try Haskell, a modern functional language. It's straight forward to use but perhaps its lack of familiarity may a little intimidating for the uninitiated. It now comes with an extensive library.</p>

CC BY-SA 4.0
2020-12-01T00:37:29.230Z
2020-12-01T00:37:29.230Z
Mozibur Ullah
<p>The modern language you are looking for is called modern Fortran 2018. Fortran 2008 and 2018 have everything a numerical computing project would need and so many features that many other languages mentioned here lack (including extremely pleasant array-syntax which has inspired all other languages such as MATLAB, Python, R, Julia, ..., even C++ numerical libraries). It is the only language that has native built-in parallelism and is the only language, along with C, for which the official MPI parallelism standard is released. It has also excellent vendor support for GPU parallel computing and as I heard in SC18, some vendors like NVIDIA/PGI have already started implementing the native parallelism features of Fortran via GPUs.</p>
<p>Modern Fortran is a high-level language comparable to MATLAB and Python, yet 100-500 times faster than both (<a href="https://modelingguru.nasa.gov/docs/DOC-2783" rel="nofollow noreferrer">https://modelingguru.nasa.gov/docs/DOC-2783</a>). Using Coarray Fortran you can seamlessly parallelize your code with minimal effort to run it from your laptop to the largest supercomputers in the world. No other language has such capability at the moment. Fortran is also the only language that has all levels of parallelism, from instruction level to vectorized, concurrent, and coarray-distributed parallel computing. If such features are not considered &quot;modern&quot;, perhaps &quot;post-modern&quot; would be a better description.</p>
<p>Fortran has been a reliable lasting language for almost 3 quarters of a century and has excellent highly-optimized compiler support (Intel, GNU, NAG, IBM, PGI/NVIDIA, ...). If you want to write code that lasts decades, then port your FORTRAN77 code to modern Fortran with minimal effort and save yourself time, energy, money, and computational power.</p>
<p>A good start with modern parallel object-oriented Fortran is &quot;Modern Fortran Explained: Incorporating Fortran 2018&quot; by Metcalf et al.</p>
<p>If you decide to port your code effortlessly to modern Fortran, you can also get help from the official Fortran language website <a href="https://fortran-lang.org/" rel="nofollow noreferrer">https://fortran-lang.org/</a> and the community of programmers on Fortran discourse: <a href="https://fortran-lang.discourse.group/" rel="nofollow noreferrer">https://fortran-lang.discourse.group/</a></p>
<p><strong>Update Nov 17, 2020</strong></p>
<p>Just yesterday <a href="https://developer.nvidia.com/blog/accelerating-fortran-do-concurrent-with-gpus-and-the-nvidia-hpc-sdk/" rel="nofollow noreferrer">NVIDIA released a news post</a> on its GPU implementation of the concurrent features of Fortran 2008 / 2018. Users can now write code in pure modern Fortran and let the compiler automatically offload it to GPUs for thousands-way parallelism.</p>
<p>What is the relevance and importance of this achievement? The <strong>same Fortran code</strong> that a user writes can now be parallelized via GPUs, distributed CPUs, OpenMP threads, or auto-parallelization features of the Fortran compiler depending on the user's platform and compiler choice. All of that complexity is hidden from the user. No need for preprocessing and conditional compilations anymore. This further enhances the excellent existing portability of Fortran programs across platforms and architectures.</p>

CC BY-SA 4.0
2020-11-14T02:59:24.413Z
Thanks for sharing, what a shame that I didn't think about this. My current language is Fortran 90.
Mike76
CC BY-SA 4.0
2020-11-14T03:04:07.267Z
I was in your position 5 years ago, when starting a new large-scale scientific project (almost) from scratch. We had this discussion of choosing between Fortran and C++. The final decision was made in favor of Fortran (2008). and the results have been quite satisfying so far. Its nice powerful syntax truly simplified life for the developers in our team. That said, do not go with any standard below 2003, if you choose Fortran. Fortran 2003 and beyond provide many powerful concepts that make Fortran 90 outdated.
Scientist
CC BY-SA 4.0
2020-11-14T03:19:10.890Z
Thank you for directing me back into the right direction. When asking this question, I was ranting about the bad string support of Fortran 90. But then I looked at our own codebase and realized that there is almost nothing except of vectors and matrices...
Mike76
CC BY-SA 4.0
2020-11-14T03:45:15.350Z
Almost any string operation that you may need is already implemented by the Fortran community. Also, Fortran 2003 and beyond have allocatable strings that are high-level and feel much like Python and MATLAB. For example this code `character(:), allocatable :: string; string = "Fortran"; write(*,*) string; string = string // " 2018"; write(*,*) string; end` is completely valid. Try it here: https://www.tutorialspoint.com/compile_fortran_online.php
Scientist
CC BY-SA 4.0
2020-11-14T03:49:35.077Z
The [Intel Fortran forum](https://community.intel.com/t5/Intel-Fortran-Compiler/bd-p/fortran-compiler) and [Fortran Reddit community](https://www.reddit.com/r/fortran/) are also great for seeking help on Fortran, in particular, the most recent standards.
Scientist
CC BY-SA 4.0
2020-11-14T02:50:59.073Z
2020-11-18T04:29:46.157Z
2020-11-18T04:29:46.157Z
Scientist
<p>Dear earth science community,</p>
<p>I am seeking a language to modernize a large Fortran project that works with geospatial NetCDF files.
The requirements for this language include:</p>
<ul>
<li>A rock-solid NetCDF library (we do not want to reinvent the wheel).</li>
<li>Excellent support for vectors and matrices (e.g. via operator overloading or something similar).</li>
<li>Native performance is needed (compiled or JIT-compiled).</li>
<li>Must be open-source.</li>
<li>Ideally, simple bindings with Fortran (not a strict requirement).</li>
</ul>
<p><code>Python</code> +<code>numpy</code> isn't really an option because of customized number-crunching with native performance.
Even if <code>numpy</code> is implemented in C, the project includes custom algorithms that operate on matrices, and we do not want to write those in C.
I know that Python <em>could</em> be optimized by calling into C or Fortran, but I just don't think that such optimization is going to happen with our team. Therefore, I am seeking a language that is &quot;fast by default&quot;. <code>Julia</code> seems to deliver much better on this &quot;fast by default&quot; promise, whereas Python is more like &quot;fast if you have the right optimizations in place&quot;.</p>
<p><code>Matlab</code> is a non-starter because of its proprietary license.</p>
<p><code>C</code> is a non-starter because it does almost nothing to &quot;modernize&quot; a Fortran codebase.</p>
<p><code>Go</code> is probably not sufficiently well-established for scientific computing?</p>
<p><code>Julia</code> could be a promising option because it combines the ease of Python with native performance.</p>
<p><code>Kotlin</code> might be interesting because it combines the strength of the JVM with the possibility to compile to native code.</p>
<p><code>Swift</code> would be a great language, but I am not sure whether it is sufficiently mature for my targeted domain.</p>
<p><code>C++20</code> and <code>Rust</code> are additional options that might be interesting, but I fear the complexity of those languages (remember that this is for earth scientists, not computer scientists).</p>
<p>Which options would you prefer for a gradual Fortran replacement with NetCDF files?</p>

CC BY-SA 4.0
2020-11-12T20:54:55.613Z
I would give a try to rust. But I think, it is very likely that you will end up with python, independently what advices you get here.
peterh
CC BY-SA 4.0
2020-11-12T20:58:48.573Z
While I agree that Python has a great ecosystem, my group isn't really Python-fanatic. In fact, one of our main requirements is to run fast with custom matrix manipulations, and Python isn't that great for this.
Mike76
CC BY-SA 4.0
2020-11-12T21:01:48.053Z
I think your group is right. There is a python library named tensorflow which can utilize 3d accelerators for complex operations. In practice I have never seen it working correctly and faster as if it would be purely in python :-) In exchange, I think most python libraries are crap, and the language speficially catalyzes the crap solutions.
peterh
CC BY-SA 4.0
2020-11-12T21:10:15.517Z
Well, it might be a viable solution to implement those custom matrix operations in C or whatever and then use Python for everything else. But even then, it is not clear whether this is a real advantage over languages like Julia.
Mike76
CC BY-SA 4.0
2020-11-12T21:13:21.760Z
In fact, I see quick prototyping and the great library ecosystem as Python's main strength, but Python certainly isn't the greatest of all languages, if we consider its weak static analysis and frequency of runtime crashes. Oftentimes, I wish that more static checks were in place so that the Python-code of non-programmers would be less broken.
Mike76
CC BY-SA 4.0
2020-11-12T21:28:38.147Z
Rust is certainly interesting, but I do not really want to introduce concepts like "borrow-checking" to my earth science colleagues. In fact, our current Fortran-codebase is bug-ridden with a whole bunch of memory-leaks, and I would happily accept any garbage collector that removes this hassle altogether.
Mike76
CC BY-SA 4.0
2020-11-13T15:21:02.103Z
I'm curious what requirement you have that isn't satisfied by your current Fortran code, I can't really glean it from the question. (Asking because one day I might run into the same problem!)
Deditos
CC BY-SA 4.0
2020-11-13T16:39:51.540Z
The desired requirements are fast iteration times and a small amount of boilerplate code, and Fortran doesn't really fulfill those requirements. Fortran feels more like C rather than a modern scripting language.
Mike76
CC BY-SA 4.0
2020-11-19T04:11:22.077Z
@Mike76: Fast iteration times and modern scripting languages are pretty much mutually exclusive.  Plus Fortran is easy to understand, Python is not, at least IMHO.
jamesqf
CC BY-SA 4.0
2020-11-19T17:16:08.863Z
I agree that Python can be hard to read in large codebases. In fact, I have seen Python-projects with >10 functions of the exact same name, and the IDE doesn't know which one is right. However, I had the same problems with same-named Fortran interfaces. Of course, this is not a serious showstopper, but it slows me down when I am reading code from other people.
Mike76
CC BY-SA 4.0
2020-11-19T17:18:48.440Z
Python is actually quite good with respect to fast iteration times, and the fact that Python is not traditionally compiled helps to speedup iteration times. Nonetheless, I have some other gripes about Python.
Mike76
CC BY-SA 4.0
2020-12-01T16:10:36.950Z
Do you want to run on Win/ Linux/ Mac??? Win and Linux both do C# which is one of the easiest and most versatile languages currently, it's used for most PC games and many science apps. it has pretty good GPU access for parallel processing.
bandybabboon
CC BY-SA 4.0
2020-12-08T20:48:32.277Z
C# is certainly a versatile option, because it is an option for almost everything. Currently, I am running only on Linux. But compiling for Windows/Mac should be doable because I don't want a hardlock into a specific OS. In general, the idea of writing a software only for one specific OS seems pretty outdated to me.
Mike76
<software><netcdf>
Language to modernize a scientific Fortran codebase
Mike76
# Language to modernize a scientific Fortran codebase

(Asked by: username_0 on 2020-11-12)

Dear earth science community,

I am seeking a language to modernize a large Fortran project that works with geospatial NetCDF files.
The requirements for this language include:

* A rock-solid NetCDF library (we do not want to reinvent the wheel).
* Excellent support for vectors and matrices (e.g. via operator overloading or something similar).
* Native performance is needed (compiled or JIT-compiled).
* Must be open-source.
* Ideally, simple bindings with Fortran (not a strict requirement).

`Python` +`numpy` isn't really an option because of customized number-crunching with native performance.
Even if `numpy` is implemented in C, the project includes custom algorithms that operate on matrices, and we do not want to write those in C.
I know that Python *could* be optimized by calling into C or Fortran, but I just don't think that such optimization is going to happen with our team. Therefore, I am seeking a language that is "fast by default". `Julia` seems to deliver much better on this "fast by default" promise, whereas Python is more like "fast if you have the right optimizations in place".

`Matlab` is a non-starter because of its proprietary license.

`C` is a non-starter because it does almost nothing to "modernize" a Fortran codebase.

`Go` is probably not sufficiently well-established for scientific computing?

`Julia` could be a promising option because it combines the ease of Python with native performance.

`Kotlin` might be interesting because it combines the strength of the JVM with the possibility to compile to native code.

`Swift` would be a great language, but I am not sure whether it is sufficiently mature for my targeted domain.

`C++20` and `Rust` are additional options that might be interesting, but I fear the complexity of those languages (remember that this is for earth scientists, not computer scientists).

Which options would you prefer for a gradual Fortran replacement with NetCDF files?

**Tags:** software, netcdf

> **Comments:**
> **username_1**: I would give a try to rust. But I think, it is very likely that you will end up with python, independently what advices you get here.  
> **username_0**: While I agree that Python has a great ecosystem, my group isn't really Python-fanatic. In fact, one of our main requirements is to run fast with custom matrix manipulations, and Python isn't that great for this.  
> **username_1**: I think your group is right. There is a python library named tensorflow which can utilize 3d accelerators for complex operations. In practice I have never seen it working correctly and faster as if it would be purely in python :-) In exchange, I think most python libraries are crap, and the language speficially catalyzes the crap solutions.  
> **username_0**: Well, it might be a viable solution to implement those custom matrix operations in C or whatever and then use Python for everything else. But even then, it is not clear whether this is a real advantage over languages like Julia.  
> **username_0**: In fact, I see quick prototyping and the great library ecosystem as Python's main strength, but Python certainly isn't the greatest of all languages, if we consider its weak static analysis and frequency of runtime crashes. Oftentimes, I wish that more static checks were in place so that the Python-code of non-programmers would be less broken.  
> **username_0**: Rust is certainly interesting, but I do not really want to introduce concepts like "borrow-checking" to my earth science colleagues. In fact, our current Fortran-codebase is bug-ridden with a whole bunch of memory-leaks, and I would happily accept any garbage collector that removes this hassle altogether.  
> **username_2**: I'm curious what requirement you have that isn't satisfied by your current Fortran code, I can't really glean it from the question. (Asking because one day I might run into the same problem!)  
> **username_0**: The desired requirements are fast iteration times and a small amount of boilerplate code, and Fortran doesn't really fulfill those requirements. Fortran feels more like C rather than a modern scripting language.  
> **username_3**: @username_0: Fast iteration times and modern scripting languages are pretty much mutually exclusive.  Plus Fortran is easy to understand, Python is not, at least IMHO.  
> **username_0**: I agree that Python can be hard to read in large codebases. In fact, I have seen Python-projects with >10 functions of the exact same name, and the IDE doesn't know which one is right. However, I had the same problems with same-named Fortran interfaces. Of course, this is not a serious showstopper, but it slows me down when I am reading code from other people.  
> **username_0**: Python is actually quite good with respect to fast iteration times, and the fact that Python is not traditionally compiled helps to speedup iteration times. Nonetheless, I have some other gripes about Python.  
> **username_4**: Do you want to run on Win/ Linux/ Mac??? Win and Linux both do C# which is one of the easiest and most versatile languages currently, it's used for most PC games and many science apps. it has pretty good GPU access for parallel processing.  
> **username_0**: C# is certainly a versatile option, because it is an option for almost everything. Currently, I am running only on Linux. But compiling for Windows/Mac should be doable because I don't want a hardlock into a specific OS. In general, the idea of writing a software only for one specific OS seems pretty outdated to me.  

---

## 4 answers

### Answer by username_7 on 2020-11-14. Score: 12 | Accepted answer

The modern language you are looking for is called modern Fortran 2018. Fortran 2008 and 2018 have everything a numerical computing project would need and so many features that many other languages mentioned here lack (including extremely pleasant array-syntax which has inspired all other languages such as MATLAB, Python, R, Julia, ..., even C++ numerical libraries). It is the only language that has native built-in parallelism and is the only language, along with C, for which the official MPI parallelism standard is released. It has also excellent vendor support for GPU parallel computing and as I heard in SC18, some vendors like NVIDIA/PGI have already started implementing the native parallelism features of Fortran via GPUs.

Modern Fortran is a high-level language comparable to MATLAB and Python, yet 100-500 times faster than both (<https://modelingguru.nasa.gov/docs/DOC-2783>). Using Coarray Fortran you can seamlessly parallelize your code with minimal effort to run it from your laptop to the largest supercomputers in the world. No other language has such capability at the moment. Fortran is also the only language that has all levels of parallelism, from instruction level to vectorized, concurrent, and coarray-distributed parallel computing. If such features are not considered "modern", perhaps "post-modern" would be a better description.

Fortran has been a reliable lasting language for almost 3 quarters of a century and has excellent highly-optimized compiler support (Intel, GNU, NAG, IBM, PGI/NVIDIA, ...). If you want to write code that lasts decades, then port your FORTRAN77 code to modern Fortran with minimal effort and save yourself time, energy, money, and computational power.

A good start with modern parallel object-oriented Fortran is "Modern Fortran Explained: Incorporating Fortran 2018" by Metcalf et al.

If you decide to port your code effortlessly to modern Fortran, you can also get help from the official Fortran language website <https://fortran-lang.org/> and the community of programmers on Fortran discourse: <https://fortran-lang.discourse.group/>

**Update Nov 17, 2020**

Just yesterday [NVIDIA released a news post](https://developer.nvidia.com/blog/accelerating-fortran-do-concurrent-with-gpus-and-the-nvidia-hpc-sdk/) on its GPU implementation of the concurrent features of Fortran 2008 / 2018. Users can now write code in pure modern Fortran and let the compiler automatically offload it to GPUs for thousands-way parallelism.

What is the relevance and importance of this achievement? The **same Fortran code** that a user writes can now be parallelized via GPUs, distributed CPUs, OpenMP threads, or auto-parallelization features of the Fortran compiler depending on the user's platform and compiler choice. All of that complexity is hidden from the user. No need for preprocessing and conditional compilations anymore. This further enhances the excellent existing portability of Fortran programs across platforms and architectures.

> **Comments:**
> **username_0**: Thanks for sharing, what a shame that I didn't think about this. My current language is Fortran 90.  
> **username_7**: I was in your position 5 years ago, when starting a new large-scale scientific project (almost) from scratch. We had this discussion of choosing between Fortran and C++. The final decision was made in favor of Fortran (2008). and the results have been quite satisfying so far. Its nice powerful syntax truly simplified life for the developers in our team. That said, do not go with any standard below 2003, if you choose Fortran. Fortran 2003 and beyond provide many powerful concepts that make Fortran 90 outdated.  
> **username_0**: Thank you for directing me back into the right direction. When asking this question, I was ranting about the bad string support of Fortran 90. But then I looked at our own codebase and realized that there is almost nothing except of vectors and matrices...  
> **username_7**: Almost any string operation that you may need is already implemented by the Fortran community. Also, Fortran 2003 and beyond have allocatable strings that are high-level and feel much like Python and MATLAB. For example this code `character(:), allocatable :: string; string = "Fortran"; write(*,*) string; string = string // " 2018"; write(*,*) string; end` is completely valid. Try it here: https://www.tutorialspoint.com/compile_fortran_online.php  
> **username_7**: The [Intel Fortran forum](https://community.intel.com/t5/Intel-Fortran-Compiler/bd-p/fortran-compiler) and [Fortran Reddit community](https://www.reddit.com/r/fortran/) are also great for seeking help on Fortran, in particular, the most recent standards.  

---

### Answer by username_5 on 2020-11-12. Score: 8

As a former Fortran programmer I did a small online review several weeks ago into current trends for scientific programming.

To begin with, despite its age and its sometimes archaic style of programming, because of its huge legacy, Fortran isn't being directed to the trash can in a hurry. It's going to be used for a long time to come.

Like you, others have been looking for an alternative to start the move away from Fortran.

Though very popular, Python is very **slow** when executing programs. The speed of Fortran is another reason why it is still being used.

For astronomical and physics applications, I've seen a number of references state a preference for initially teaching students Fortran but when they get more experienced in their field exposing them to C++.

This comment from 2013, from a [Physics forum](https://www.physicsforums.com/threads/best-programming-language-for-physics.719723/) encapsulates the general ideas I seen:

> The older guys use fortran and c++. The younger people use python,java,and c++.

As with your answer, I think if Julia was more widely used it could have the potential to replace Fortran and possibly Python for scientific computing.

> **Comments:**
> **username_0**: Thanks for sharing. I know that Python *could* be optimized by calling into C or Fortran, but I just don't think that such optimization is going to happen with our team. Therefore, I am seeking a language that is *fast by default*. Julia seems to deliver much better on this "fast by default" promise, whereas Python is more like "fast if you have the right optimizations in place".  
> **username_0**: For our group, having a gigantic language-community isn't that important, as long as it is a well-maintained language. All we need is NetCDF and basic matrix-operations, so we could give Julia a try even if it isn't as mature as Python.  
> **username_5**: @username_0: If a lot of number crunching is involved, speed of processing is important. From reports of speed bench mark studies I've seen on line, in order of speed, the fastest 3 languages generally are C, C++ & Fortran. Julia is usually in the next tier of languages at positions 4, 5 or 6. I'd recommend Julia.  
> **username_0**: From what I have seen, Julia is "close to native performance". This seems to be good enough; I am willing to sacrifice a small bit of performance in order to overcome the slow development cycles of C/C++/Fortran.  

---

### Answer by username_0 on 2020-11-12. Score: 1

Right now, I think that `Julia` makes the cut, because it provides a great tradeoff between "fast scripting" and "high-performance scientific computing".
But I am willing to hear other people's opinions, perhaps I have overlooked something.


---

### Answer by username_6 on 2020-12-01. Score: 0

You could try Haskell, a modern functional language. It's straight forward to use but perhaps its lack of familiarity may a little intimidating for the uninitiated. It now comes with an extensive library.


---

