I am from Fortran (high performance modern Fortran) to Julia.
May I just straightforwardly ask a question to you guys, so,
What is the advantage of Julia over Fortran?
I mean, modern Fortran seems is not that bad, and the performance is not very bad either. In many ways the code may even look kind of similar with Julia.
So,
what is the advantage of Julia?
I feel Julia is similar with R, Python, or Matlab, it is easy to perhaps handle files IO, draw plots.
It also have many packages which are easy to install and use.
Also, the performance may be faster than R, Python, or Matlab.
But usually does it have performance advantage over Fortran?
Perhaps Julian can some day replace R, Python or Matlab,
but will it replace Fortran or C/C++ in high performance area?
Is there any big company begin to support Julia? Intel, AMD, Nvidia, Microsoft, Google…?
like, Intel have Intel Fortran/C all these years (now become Intel OneAPI, and it has continue to release new version every year in the almost last two decades)
I mean if big companies involved, it can usually bring, say the least, better IDE, better performance, etc.
usually discussion started this vague won’t yield productive discussion. would you want to be more specific?
in short dynamic is a good plus, package manager is also huge, how do I just use a package that solves differential equations and plot it in Jupiter via trial and error in Fortran?
It won’t have a clear performance advantage over fortran, but it won’t have a disadvantage, and at least for me, having an interactive workflow is life changing. Debugging and development in general are more fun and productive. I feel like I can do more in less time with Julia than I could in C/C++. I don’t have much experience with fortran but the ideas apply.
My short answer is that Julia can require (literally) exponentially less code than Fortran. Let’s suppose you want to solve a linear differential equation by taking the matrix exponential. In Julia this will be exp(A).
In Fortran, you would have to call a different function for every combination of matrix type and element type A could have. This means that if you want to do this in another function, you will have to copy paste it to write a bunch of additional versions for each type of A.
Then someone comes along with a new GPU architecture, and your code is broken in Fortran. In Julia, as long as the language supports the new GPU architecture, your code probably will too.
Expecting that one language will replace others is not realistic. Maybe Julia will become more popular than other languages, but replacing is unlikely. Except Matlab, that one I think is in risk, given the alternatives.
You seem to have a good idea of the advantages of Julia: nice development environment, good code base, the possibility of doing Python-like stuff and Fortran-like stuff in the same language. The package manager, documentation tools, GPU support are much better in Julia for now. Julia also allows generic programming, which allows for a high level of code reuse. The tooling around Julia is also great for aiding development.
Fortran is a good language for numerical computing. With a very simple syntax that does not allow the user to make mistakes that compromise performance too much, something common in Julia particularly for new users. With the development of LFortran it will gain many is the benefits of a an interactive development environment. And high level languages interface with it as easily as with C. So, I think that investing in learning Fortran is still valid and Fortran will continue to be an important player in cientĂfic computing. It is not going anywhere.
One other practical advantage that it is that when a collaborator gives me Julia code I can (sometimes) actually read it. I am really not capable with Fortran at all and you say that modern Fortran sort of looks like higher-level code, so maybe this isn’t true for more capable Fortran programmers. But I’ve definitely had several experiences where I look at an applied math paper and think “oh wow, neat, I’d like to look at the code for that” and then go take a look and find it completely inscrutable. I’m sure that’s plenty my fault and I don’t mean to say that as a knock on Fortran. But I might go so far as to opine that the average applied mathematician, who is not a software engineer, is more likely to write readable Julia than readable Fortran. And while I love code performance as much as the next person, I try to maintain perspective of the fact that I am an academic researcher and not a software engineer, so readability and collaborative ease are pretty high priorities for me, even if they come at the cost of some speed (although to my knowledge they haven’t, at least for my applications).
With all that said, if you like using Fortran and don’t find some of the more verbose or boilerplate-heavy things annoying, then I’m not sure I’d be all that pushy in trying to convince you to adopt Julia. It sounds like you’ve got a tool you like and that’s great.
I’m also a bit concerned that this thread will read like some hardcore evangelism. While I can’t speak for other people, I would guess that they’re more sharing why they were excited to pick up this tool than they are actively trying to talk somebody else, who I assume is a complete stranger, into using it. So I hope that this thread doesn’t end up feeling like a dogpile.
I’m currently in the processes of adopting Julia, and my background is Modern Fortran. I would say that the main allure of Julia for me is the promise of a smoother workflow, especially in potential collaborations. The Julia ecosystem also seems to be much faster at adapting than Fortran, which I guess is due to the completely different philosophies - no Fortran change will ever break old code and “there’s no need to fix what isn’t broken”. Though it simply amazes me that I managed to run into multiple issues with Fortran Coarrays (at least with the compiler I used), for example, which have been in the language longer than Julia existed. It feels like there is just not enough demand for the Fortran 2008+ features in our community for them to be truly stable (and I used one of the bigger compilers). Again, this is just my own experience.
And as other people in the thread have already mentioned, you have a lot of boilerplate with Fortran. I have had cases where I had to write what is essentially the same code multiple times because I wanted to handle multiple array ranks. While there are testing frameworks out there for Fortran, they can be problematic to set up, and I don’t think I’ve seen any Fortran projects using CI.
Those are the main reasons I’m trying out the switch, but as you can see, those are personal and also project-dependent. If I were stuck working with a large existing Fortran codebase and didn’t want to use the newest quality-of-life features, I don’t think I would switch.
There is a disadvantage to Fortran: you can’t compile to a small executable by now. Depending on your use case, this can be a breaking issue. I believe it will be solved some day, but not tomorrow.
(Edited because of bad english: I mean, Julia can’t yet compile to reasonable small standalone executables)
FORTRAN has had, and continues to have, a lot of money invested in its development. Any new computer technologies that come along – multithreading, SIMD, multiprocessing, GPUs – it gets supported by Fortran. Even some support for Unicode. Fortran’s immune system also appears to have kept the OOP virus at bay as well.
That leaves interactivity – but now there is LFortran for that!
Hmm … that would leave personal preference for syntax?
Ask us about a different language – we’ll probably find it easier to say something nasty.
Do you know, like, is there any big company are going to support Julia? Intel, AMD, Nvidia, Microsoft, Google…?
like, Intel have Intel Fortran/C all these years (now become Intel OneAPI and it is free, and it has continue to release new version every year in the almost last two decades)
I mean if big companies involved, it can usually bring, say the least, better IDE, better performance, etc.
Not currently, according to a recent talk by one of the Julia creators @StefanKarpinski. (On youtube somewhere, not sure which talk it was.) But there is Julia Computing (small company) and Julia Lab (academic lab).
Another thing to keep in mind is that we all certainly will have to learn to some extent more than one, probably many languages. As a learning experience, I think Julia is one of the best, at least for people like me that have not a deep background in computer science. One learns many important concepts that allow one to be better coders in all the other languages. After learning Julia it becomes trasparent why a Python code may be slow and how numba and stuff can help an can be used. These ideas were never even a subject of conversation in the Fortran communities I come from.
In my personal opinion, the right questions to be asked now are not “Does Julia have performance advantage over Fortran?”, but “Does Fortran have performance advantage over Julia?”, and not “Will Julia replace Fortran or C/C++ in high performance area?”, but “Do we need to stay in C/C++ or Fortran for high performance area?”
The correct answers to the right questions are “No” and “No”.
It is outdated to suspect that Fortran (or C/C++) is faster than Julia.
To the best of my understanding, when the code is written correctly, Julia and Fortran are about the same speed of computation. We cannot say that one is faster than the other.
OP asks about Julias advantage over Fortran.
There are some advantages as others pointed out.
What I meant is, there is a very important disadvantage if someone thinks about switching from Fortran to Julia, that is, Julia can’t yet compile to reasonable sized standalone executables. This may be surprising for somebody coming from Fortran, so I brought it up for OP to take it into account.
I do not think that Matlab is in any danger. Neither now nor in near future. Well, perhaps when it comes to “merely” solving whatever equations and optimization problems on a desktop computer and plotting the solutions, there are indeed serious alternatives, including Julia. Some of them (including Julia) are even better performing and more convenient, I agree.
But in some engineering domains such (offline) computational tasks form just a fraction of the practical everyday use. In particular, control engineers use Matlab – actually its graphical frontend for modeling and simulation of dynamical systems called Simulink (and Simscape and Stateflow) – not just for performing some offline computation on a PC but for generating a C/C++ code that is then intended for compilation on an embedded platform and for running in real time, processing the data from sensors and producing commands for actuators every fraction of a millisecond, possibly by solving some optimization problems, complying with whatever industrial standards (the core products for this are Simulink Coder and Embedded Coder). Untill such real-time code generation capabilities are available in Julia, there’s no way to abandon Matlab and Simulink, at least for us, control engineers, I am afraid.
