Startup time is not the only issue with Julia. Its error messages are long-winded and cryptic, and its manpages can be quite sketchy.
Even so, Julia is a good tool for intensive computation, and I think it will continue to replace Fortran for some such work.
Balance is the key. I use R all day long for data analysis, and don't really see Julia as competitive for such work. However, when it comes to numerical modelling, Julia competes well with Fortran and C/C++.
I think Julia should be thought of as a Fortran replacement for overnight/overweek jobs, not an R replacement for interactive work.
YMMV. For me, Julia is a wonderful replacement of Python/numpy/scipy/pandas/Jax/Tensorflow/cython/sympy that I use mainly for interactive work. I am a fairly competent Python developer and know how to do idiomatic high-performance Python. I needed to learn new idioms and workflows when switching to Julia, but I am drastically more productive in it, both in interactive and in batch work.
I will attempt to, but do let me know if this is not the type of examples you meant:
Julia idioms: Multimethods and multiple dispatch instead of python/java style OOP; Loops are fast, with zero-cost-abstractions and automatic SIMD, unlike python's need for vectorized libraries; "type-inferability" is incredibly important for good performance, which is quite different from python's duck typing (but the language is dynamic, so it is still an option); measuring how often your code allocates is the most trivial way to increase its performance by an order of magnitude.
Julia workflow: you *have* to change your workflow, compared to coming from python, otherwise the latency of the compiler would cause you deep enraging frustration: e.g. use Revise.jl/Pluto.jl/REPL, organize your code so that small pieces can be recompiled without having to restart your session; keep your workspace clean and your computational pipeline organized, so that reproducibility testing is easy.
I'm curious what made you more productive. Was it not having to use those vectorized libraries?
I write machine learning code, so anything compute intensive is done with specialized libraries and the Python glue code usually has little overhead. Sometimes when writing complicated pipelines I spend a lot of effort on optimizing data transfers (between CPU and GPUs, between GPUs on the same server, between GPUs on different servers in a cluster, etc), but that effort has little to do with Python limitations (or so I think).
- I actually like vectorized code, I find it easier to read, but especially in python, vectorized code still has some fixed overhead that can be prohibitive for smallish vectors.
- Some of the numerical code I run is not easy to batch, so tools like tensorflow are cumbersome. With Julia it is easy to make fast non-allocating code while writing in easy to read style like in Python. In Python you need to use C/Cython/Numba to achieve this, but then you lose interoperability with other Python packages. E.g. auto-diff through fast cython code does not work, while autodiff through my equally fast non-batched Julia code is trivial.
- Ecosystem: I work with differential equations a lot. Julia's SciML library (and its DifferentialEquations.jl sub-library) is light years ahead compared to any other tool in Python/R/Mathematica/Matlab/Maple. Speaking of python, solving differential equations in python feels like I am using technology that is quarter of a century old.
- In python I might write a nice and legible slowish implementation of something and then piece by piece I will start replacing it with cython. That requires a lot of boilerplate. In Julia I just write the slowish implementation with the same ease with which I would do it in python, but then I need to perform extremely minimal profile-guided changes with zero boilerplate to achieve the cython/numba type of performance. And again, I do not lose interoperability with other parts of the ecosystem when I do that.
- It is trivial to inspect the actual machine code that was generated for every single function you write. It is trivial to inspect exactly where allocations happen. Most of the ecosystem is in pure Julia, so it is trivial to edit fairly foundational pieces of the ecosystem and submit patches. On the other hand, the levels of abstraction in something like Jax/Tensorflow/Numba makes it relatively difficult to contribute.
- It is wild how much code reuse you can have with the multiple dispatch paradigm. Say I find someone's pet project on performing a complicated linear algebra algorithm. That code was probably written just to work with Float64, but thanks to multiple dispatch the compiler can generate specializations for esoteric higher-precision real number representations, or real numbers with error bars, or unitful numbers. I still need to do some sanity checks, because hidden assumptions might be problematic, but this level of interoperability is possible only with multiple dispatch (thinking of it as one of the "standard solutions" for the Expression Problem[1] really helped; [2] was also informative). I think the GPU libraries for Julia are a good example of multiple dispatch working well in that sense.
I'm kind of on the fence with Julia, never used it in anger. But to me it seems much more of a Matlab or Python replacement than a Fortran replacement? Meaning that (in my perhaps limited view) it's main usefulness is in making algorithm development much faster and smoother.
However, once a new very fast algorithm has been discovered and tested and everyone agrees it is good, someone will probably implement it in Fortran or C or even assembly and optimize the shit out of it.
One thing that supports this view is that there are several Julia packages that are wrappers around existing C/Fortran/C++ libraries, and basically no examples (that I know) of people porting existing libraries to Julia.
As with the others, I'll strongly disagree and chime in with a few examples off the top of my head:
- ITensors.jl : They started moving from a C++ to Julia a couple years ago and now their webpage doesn't even mention their original C++ implementation on its homepage anymore https://itensor.org/
- DifferentialEquations.jl : This has many state of the art differentiatial equation solving facilities in it, many of which are improvements over old Fortran libraries.
- SpecialFunctions.jl, Julia's own libm, Bessels.jl, SLEEFPirates.jl : Many core math functions have ancient Fortran or C implementations from OpenLibm or whatever, and they're being progressively replaced with better, faster versions written in pure julia that outperform the old versions.
> One thing that supports this view is that there are several Julia packages that are wrappers around existing C/Fortran/C++ libraries
That's an understandable misconception. But the reason these packages use C/Fortran libraries is because they're already there, and writing a wrapper is much easier than rewriting the library in Julia. It's not a performance thing, it's a person-hours thing and wanting to use the libraries right now.
On the one hand, this means you have binary dependencies and FFI you have to manage.
On the other hand, it saves you a lot of niggly optimization work and dealing with edge cases, which the C/Fortran libraries have already gone through and done for you.
Once the former starts to outweight the latter and/or more person-hours become available, the libraries start to get ported to be fully in Julia. And the tools available in the ecosystem and the compiler codegen are good enough that there's no artifical performance ceiling due to being in Julia i.e. you do get performance equivalent to being in C or Fortran.
> One thing that supports this view is that there are several Julia packages that are wrappers around existing C/Fortran/C++ libraries, and basically no examples (that I know) of people porting existing libraries to Julia.
This is totally off-base :-)
There’s even discussion of implementing a lot of linear algebra stuff in Julia, instead of just falling back to BLAS (for very good reasons), see eg https://youtu.be/KQ8nvlURX4M
Those wrappers are just to bootstrap the ecosystem for immediate usefulness.
So, over time, I expect Julia to become better and better for everything from exploratory development to workhorse numerical computing infrastructure. Once compiled binaries are feasible, I wouldn’t be surprised if other languages start wrapping algorithms implemented in Julia.
Even so, Julia is a good tool for intensive computation, and I think it will continue to replace Fortran for some such work.
Balance is the key. I use R all day long for data analysis, and don't really see Julia as competitive for such work. However, when it comes to numerical modelling, Julia competes well with Fortran and C/C++.
I think Julia should be thought of as a Fortran replacement for overnight/overweek jobs, not an R replacement for interactive work.