A colleague of mine has been working with FORTRAN for decades, and currently operates a successful business using a model developed in the FORTRAN 2018 standard. They expressed curiosity regarding Rust, along the lines of "my daughter says it's all the rage".
The model performs a series of intensive calculations over a spatial extent (LiDAR data), and the business model operates by marketing this service to different areas. The model runs rarely, and FORTRAN is already reasonably fast, so while I can confidently claim Rust can be as fast or faster, this fails to disqualify Rust but does not give it a leg up.
"Rust is memory-safe, eliminating whole classes of common memory-related bugs," I add. But my colleague shrugs and says "this program has been pretty stable for 12 years now, I don't spend much time dealing with that."
When it comes to the microservice contribution that I intend to make to the model, the question naturally arises whether it would be better to implement it in FORTRAN, or split off the particular set of functions I am contributing into a Rust library. I am unfamiliar with the build process for FORTRAN, do any of you know if Rust and FORTRAN play nicely together?
Based on the FFI section in the Rust book and this FORTRAN FFI example, it appears that I can create a normal library crate and make the functions of interest available through a FFI. Is it this easy? Should I be reading the Rust FFI guide by @Michael-F-Bryan?
I would say that introducing additional languages to existing projects should be avoided unless there is a very large gain in using the new language. It doesn't sound like there is such a large gain for your purpose.
Note that for strict numerics, I wouldn't be at all surprised if FORTRAN is as fast or faster than Rust.
For things that are mostly about loading a large dataset and running a bunch of math over it, FORTRAN is probably a great choice. Its semantics are made to fit well for that, and the implementations are probably extra-good at optimizing the indexing+math stuff. (And LLVM is pretty good at that, but maybe not quite as good. And Rust hasn't exposed a bunch of things like "I want the approximate version of these float operations" that FORTRAN probably has.)
Rust was originally created as a language for the next-generation web browser. The closer your problem is to this use case – large attack surface, untrusted inputs, fine-grained concurrency, hard constraints on tail latency – the better Rust will work.
As other people have pointed out, batch numerical computation on well-structured, trusted data doesn't really play to these strengths. Fortran would probably do better than Rust.
Can you go into more detail on this microservice? How will it be called?
Yes, FFI in Rust is pretty straightforward. I think the hard part will be convincing your coworkers to accept it
I would be wary of introducing a new language to a large project. Even if using FFI to bolt it in is dead easy. In doing that one has doubled the difficulty of any one understanding what is going on in the code, they now have two languages to learn. Then there are just practical complications in building the program.
There would have to be very compelling reasons to take this on.
I'm not clear on what you mean by "micro-service". I typically take that to mean some independent program that takes requests over a network, crunches on producing some result and returns a response over the network. If one really has a reason to use a different language then doing so as a micro-service seems like a clean way to do so.
I don't particularly see any particular reason why Rust should be any slower than FORTRAN. Although I can imagine there are FORTRAN libraries that are very well optimised and likely a lot of effort to rewrite in Rust. Or even use from Rust.
This is a bit of an aside, but one of the traditional reasons for FORTRAN being faster at serious numeric processing than C etc. is due to C arrays decaying to pointers, and C’s weak pointer aliasing rules. Having to assume that output arrays may overlap input arrays prevents the compiler from making certain optimizations, such as vectorization. (C added the restrict keyword to help mitigate this.)
Rust doesn’t have these problems and in theory could match FORTRAN. I’d certainly be interested to see how Rust/FORTRAN performance compares as LLVM’s no-aliasing optimizations stabilize.
Anyway that said, I totally agree with the other comments above.
Greetings, I stumbled upon this question on the web and thought it would be good to share some resources regarding Fortran in the hope that you find it helpful as Fortran resources are rather scarce.
Beginning with Fortran 2003, the standard added significant powerful formal C-Fortran Interoperability (CFI) features via iso_c_binding module and the bind(C) attribute among other features. These along with the latest CFI additions to the Fortran 2018, make the language interoperable with any language that can interoperate with C, including Rust, in a standardized portable way.
Intel Fortran Forum which currently has over 130,000 questions and answer by many Fortran experts who live in the forum (On a side note, Intel Fortran compiler is now available free of charge on all platforms: Windows, Linux, macOS).
.... to be continued
People have prudently warned on this thread about the dangers of introducing a new programming language to a project. But that seems unavoidable given the description of this project and the strengths and weaknesses of Fortran. Who writes web services in Fortran? There are lots of systems where some optimized numeric routines are implemented in Fortran and the rest of the system is in C++ and/or Python. Numpy for example. If the Fortran model can be wrapped in a library and called from some language that is good at web services maybe that would make more sense than writing an HTTP server in Fortran.
Thank you to everyone for responding so thoughtfully. As @lambda-fairy notes, batch numerical computation on well-structured, trusted data presents an interesting use case, as many of the common "elevator pitch" arguments for Rust do not apply. Although "as fast or faster" may be more of an aspirational goal, even if it were true I appreciate the pragmatic advice of @alice and others to not complicate the model with multiple languages. This makes the links from @shahmoradi particularly helpful, although "go learn FORTRAN" was not what I was expecting to hear.
In the Rust forum, I am especially pleased and impressed at the lack of knee-jerk responses in favor of Rust, without clear regard for consequences. I am sure my colleague will enjoy reading the thread as well. Apparently there is a large amount of legacy code in the scientific community chugging away in FORTRAN...
One factor that may be interesting is the potential future development and maintenance of this software if the business model isn't centered on just a few knowledgeable persons. Finding suitable Fortran programmers might be harder than finding Rust programmers now, and even more so a few years down the road.
However, this argument would probably strongly suggest Python as a serious alternative, as that language is pretty extensively used in the scientific community, with many excellent libraries available.
Regarding your microservice idea, are you sure you know what a microservice is? Microservices are typically loosely coupled, with the main advantage of being able to be independently deployed and scaled up on demand. This doesn't really match a model that runs rarely
It looks like your plan is actually to build a library to be linked into the Fortran code, which is likely to create much more hassle than it's worth. Linking foreign language libraries only makes sense when you have large pre-existing libraries that you want to utilize (as in the Python case mentioned above).
A possible approach would be to wrap the Fortran code into a library that may be used from Python (all of Python's performance advantages come from wrapped libraries, the language itself isn't particularly fast) or Rust. However, you would need to have a solid case to do this.
So even if this forum is focused on Rust, I would not suggest to invest significant resources just because your colleague's daughter says it's all the rage...
I think this is an important part of the way of building a good reputation/credibility. Specially nowadays, when it seems impossible to hear 3 sentences without some agenda behind. "Incredibly fast", "amazingly ease to reason about" etc. Such sectarian/marketing attitudes create a so high spectation that it unavoidably leads to frustration with the language in the long run.
Fortran (currently) has the fastest numeric implementation AFAIK and there is no problem with that.
