Don’t people google their newly coined acronyms? GRAPE is already Gradient-Ascent-Pulse-Engineering, which is arguably “machine learning” (optimal control)
I think his main point is about strict typing in Fortran. You can add type annotations in Julia but it's almost an anti-pattern if you don't need them e.g. for dispatch. In any case the type annotations in these examples would be quite unnecessary, unlike in Fortran (where as I understand you can at best enable implicit typing but then must use variable names with specific patterns).
I would argue that the strict typing in Fortran is actually a significant hindrance. there's nothing about any of these algorithms that requires double precision (or even contiguous storage), so why should the algorithm randomly restrict it? Annotations of rank (e.g. AbstractMatrix in julia) help document what the code does, but the strict annotations of Fortran are restrictions without value.
Step 1) Write the function using high level abstractions
Step 2) Glance over the generated assembly and make sure that it vectorized the way you wanted.
> Glance over the generated assembly and make sure that it vectorized the way you wanted.
Isn't that sth you would also need to do in Fortran? IMO Julia makes this so easy with its `@code_*` macros and is one of the main reasons why I use it.
If you write Julia similar to Fortran, with explicit argument types and for loops and avoiding allocations it shouldn’t be too far off. Fortran IIRC has a few semantics which might make it more optimal in a few cases like aliasing
But indeed there are almost certainly less performance surprises in Fortran
This is the default workflow in every high-level language. Even if I’m writing explicit SIMD intrinsics in C targeting a specific processor, I still have to benchmark and maybe look at the assembly to make sure it did what I intended (or something better).
I wrote this plugin for Neovim to be able to edit Jupyter notebook .ipynb files directly in Neovim. The native format for notebooks is quasi-binary json. This plugin uses the jupytext tool (https://github.com/mwouts/jupytext) to convert that json to a plain text representation (markdown or code) on the fly, and back to json when the file is saved.
While not a Matlab nor Julia user, I think you may be neglecting the nearly 40 years of code, toolboxes, and countless examples of common engineering problems solved in Matlab. Engineers tend to be more of a practical sort than developers, and just want to apply a known solution to a problem than mess around with newish software languages.
This is true, but even engineers see the advantages of Julia. My engineering school has went from almost pure Matlab usage to many key engineering courses switching to Julia due to its simplicity and friendliness.
It's also SOTA for many engineering applications, particularly for acausal modelling and scientific machine learning (see https://sciml.ai), which has led to big companies like Pfizer adopting it [1]. And for engineers writing novel libraries, it clearly has a strong edge. See for example the work by NASA's JPL [2, 3], the FAA [4] or the CliMa project [5].
Tools are valid regarding a context (when you have a hammer everything is a nail etc.). In the industrial context, Julia is not valid. In the research/education, it is valid. It does not mean that Julia will never be relevant in research.
Our upcoming JuliaCon 2024 has a significant number of industrial talks and a minisymposium. ASML uses Julia quite widely in a definitively industrial context.
What I mean is as a worker or student, I want to know if the tools I spend time on will be relevant in the industry. And I think I have more chance to meet companies working with MATLAB than Julia.
But if I want to work at asml Julia might be a good fit ofc.
One enormous difference is that MATLAB is paid, which, ironically, makes it much much easier to use in a corporate context.
For MATLAB it isn't just toolboxes, but also integrations with other tools. So it depends on what you are trying to do, but if your problem is taking in data, computing, putting out data, Julia can absolutely compete with MATLAB, even on the most practical "I really just want this to just work and look at the results", level.
Being paid does not make it easier to use in a corporate environment, that is nonsense. I specifically tried to ween my Mech E.’s off Matlab because I don’t want to pay for Matlab licenses for our company.
The big win for Matlab seemed to be there are pre-existing solutions/examples for hundreds of common engineering problems that only need to be tweaked for the problem at hand. Engineers like this. They seem pretty happy and productive in Matlab too, so I finally gave up and decided it was my best interests to let them use it.
>Being paid does not make it easier to use in a corporate environment, that is nonsense.
No, it isn't. It is the single biggest issue in getting it into your corporation. I can easily get a 10k Euro PC if I had any reasonable need for it which I could coherently explain to my boss. Getting Julia installed on it would take months of debates with IT and tens of thousands in internal expenses.
It is the same reason why corporations use Redhat, there is nothing about Redhats Linux which makes it inherently superior to e.g. Debian, definitely nothing that would justify the price. But corporations still willingly pay for it.
There are multiple reasons for this. First is support, if you aren't paying someone, there is nobody who will support you. Secondly is liability this is enormous, MATHWORKS is willing to take legal responsibility for their mistakes. That is a very big reason people use MATLAB, in some areas it is basically the only option for that reason. Thirdly paid software is easy to understand to everyone else, you wouldn't imagine how hard it is to tell people that something good is actually free and in fact so free that you can do with it whatever you want. If you aren't part of an enormous organization this might be hard to understand, but for most people free means "trial version" or "scam".
I’m not sure I would consider the scientific computing that Julia targets a “tiny” niche. It’s worth remembering that Python is 30 years older than Julia, and Julia has only been in a really usable state for 4 or 5 years. You can’t expect it to displace Numpy/Scipy/etc overnight. Especially if you include machine learning, where there’s just huge momentum with large corporations having massively invested in Python frameworks for at least 10 years. Subjectively, I’m seeing quite a lot of growth in Julia. It’s certainly a much stronger language than the Python/C++ combination that currently has the biggest market share in that area.
Also, there’s nothing wrong with niches. Julia is undoubtedly less of a general-purpose language like Python, but it very much shines in its domain.
True, but C and Fortran have very different semantics that make them suitable for very different fields. In particular, C does not have great semantics for linear algebra. Also, C has many footguns due to its use of pointers, while Fortran has virtually none.
You still need to learn the tooling, but the tooling is actually pretty similar for Fortran/C/C++ (same compiler/linker toolchain). Libraries aren't that much of a thing in Fortran, but to the extent that they are, this again is similar to C/C++.
C++ and Rust don’t really have good semantics for scientific computing (linear algebra). They’re great for many other domains like “system’s programming”, where Fortran doesn’t compete, of course. The only language that’s similarly (in fact, more) expressive as Fortran for scientific computing today, as well as holding up for performance, is Julia
How has it “not panned out”? Julia has been in a useable state only for a few years, and is still rapidly developing. Prior to Julia 1.0, I would have said Fortran (which I have 15 years experience with) was the most productive language for scientific computing. Today, Julia is, by a wide margin. In fact, our benchmarks show Julia matching or beating Fortran’s performance, to say nothing of the mich increased flexibility.
