I know I know I know that this same refrain has probably been said nonstop since Julia's first day after launch, but the language really is getting noticeably better every single release. Each of the releases I've been around for (so 1.8-1.11, and now on nightly, 1.12) is adding meaningful new features, performance improvements, and addressing many of the oldest and sharpest pain points
the `--trim` feature coming in 1.12 will still be considered experimental, and if I had to take a guess won't be considered "stable" until 1.14 or so, but I'm really excited to see it picked up around the ecosystem!
I’m kind of sad, because I think I have completed the journey from advocating for Julia at my first job to becoming a full-blown hater. I have complaints about the type system and the general failure of a good autograd library to emerge as the standard/default.
But my main complaint about Julia is its general approach to memory management. You are encouraged to think about how memory is being allocated e.g. by using StaticArrays for smaller, immutable arrays, or pre-allocating the arrays and operating on them in-place. But you don’t actually have control over allocations, and it’s easy for some type instability to cause unnecessary allocations - even after you stick a bunch of type annotations which should give the compiler sufficient information to force type stability or at least crash/fail to type check.
At this point I think people are better off investing their time/efforts into Rust for computationally heavy workloads on the CPU (polars for data frame stuff, ndarray for numpy functionality, Enzyme for autodiff) and using torch/jax for GPU-centric work (also, it’s significantly easier to write python bindings for rust libraries than C++ or Julia libs).
Small static binaries could be an killer-feature for Julia.
While I always had an eye on Julia and it is a lovely language, especially the multiply dispatch and general lispy-ness in spirit, I never really had a good use case for it.
Python always was the better choice due to the stronger ecosystem and faster launch time. Rarely did I need the extra performance Julia offered. But Python is annoying to deploy so Julia starts to seem tempting, at least for smaller projects where you don't want to do a complex docker setup.
The article describes Julia as "a general-purpose programming language aimed at science, engineering, and related arenas of technical computing".
I think this is about right. If you are going to solve differential equations or run some numerical weather codes or solve an integer program or simulate an electrical circuit, it would be a good idea to consider Julia rather than reaching for Fortran, C++, or MATLAB. It is a much nicer language and still very fast.
My experience is that people who want to use Julia for data science and especially for deep learning, usually find that you can get the job done, but often it's easier to use PyTorch or Jax and just accept the limitations of Python.
Julia is still such an absolute joy to use. I have a dream that somehow, Torch.jl, which attempts to provide a julia interface to pytorch, will magically take off. Python is ok, but julia is just so fast, fun, and easy to scale.
I'm happy to see static compilation in the works! If static compilation takes off, and people are able to build Python packages that are secretly just compiled Julia code, I can see a world where more people opt to using Julia over C or C++. Though writing Rust libraries that work as Python packages is a joy and Julia would still have competition.
Julia biggest problem at the moment is growth. Julia has suffered from not having exponential growth, and has either maintained a small linear growth or has fallen in popularity. Search online on YouTube for tutorials, on Twitch for WatchPeopleCode, or on GitHub for benchmarks; and Julia is not even in the room where the conversation is happening - there just isn't any mindshare.
And for good reason. There are so many ergonomic challenges when using Julia in a large codebase and in a large team. Julia has no formal interfaces, LSP suggestions that are often just wrong, and no option types. This just makes writing Julia code a drag. And it makes it quite difficult to advocate to developers experienced with languages that offer these features.
Additionally, the core conceit pushed by Julia advocates is that the language is fast. This is true in controlled benchmarks but in real-world scenarios and in practice it is a real pain to write and maintain code that is fast for high velocity teams because it requires a lot of discipline and a strong understanding of memory allocation and assumptions the Julia can and cannot make. You can write code that is blazingly fast, and then you make a change somewhere else in your program and suddenly your code crawls to a halt. We've had test code that goes from taking 10 minutes to run to over 2 hours because of type instability in a single line of code. Finding this was non-trivial. For reference, if this were uncaught our production version would have gone from 8 hours to 4 days.
The lack of growth really hurts the language. Search for pretty much any topic under the sun and you'll find a Python package and possibly even a Rust crate. In Julia you are usually writing one from scratch. Packages are essential to data processing are contributor strained. If you have a somewhat unpopular open source code code you rely on that doesn't work quite work the way you want it to, you might think I'll just submit a PR but it can languish for months to a year.
The Julia community needs to look at what programming languages are offering that Julia developers want and will benefit from. The software world changing very quickly and Julia needs to change too to keep up.
I just love pythons ease of use, and the few times I've tried Julia it has felt clanky in comparison, and then Jax just makes everything so amazingly fast.
> The next major Julia release, 1.12, is likely to appear in mid-2025. It will finally include the ability to generate static binaries of a reasonable size, appropriate for distribution.
I would be thrilled if Julia had this in early days, but now it is a little too late. I have jumped the boat.
New horizons for Julia
(lwn.net)203 points by leephillips 22 hours ago | 68 comments
Comments
the `--trim` feature coming in 1.12 will still be considered experimental, and if I had to take a guess won't be considered "stable" until 1.14 or so, but I'm really excited to see it picked up around the ecosystem!
But my main complaint about Julia is its general approach to memory management. You are encouraged to think about how memory is being allocated e.g. by using StaticArrays for smaller, immutable arrays, or pre-allocating the arrays and operating on them in-place. But you don’t actually have control over allocations, and it’s easy for some type instability to cause unnecessary allocations - even after you stick a bunch of type annotations which should give the compiler sufficient information to force type stability or at least crash/fail to type check.
At this point I think people are better off investing their time/efforts into Rust for computationally heavy workloads on the CPU (polars for data frame stuff, ndarray for numpy functionality, Enzyme for autodiff) and using torch/jax for GPU-centric work (also, it’s significantly easier to write python bindings for rust libraries than C++ or Julia libs).
While I always had an eye on Julia and it is a lovely language, especially the multiply dispatch and general lispy-ness in spirit, I never really had a good use case for it.
Python always was the better choice due to the stronger ecosystem and faster launch time. Rarely did I need the extra performance Julia offered. But Python is annoying to deploy so Julia starts to seem tempting, at least for smaller projects where you don't want to do a complex docker setup.
Julia is for sure prioritizing the right things.
I think this is about right. If you are going to solve differential equations or run some numerical weather codes or solve an integer program or simulate an electrical circuit, it would be a good idea to consider Julia rather than reaching for Fortran, C++, or MATLAB. It is a much nicer language and still very fast.
My experience is that people who want to use Julia for data science and especially for deep learning, usually find that you can get the job done, but often it's easier to use PyTorch or Jax and just accept the limitations of Python.
currently if in a file i have
and I execute this file, I will get an errorJulia biggest problem at the moment is growth. Julia has suffered from not having exponential growth, and has either maintained a small linear growth or has fallen in popularity. Search online on YouTube for tutorials, on Twitch for WatchPeopleCode, or on GitHub for benchmarks; and Julia is not even in the room where the conversation is happening - there just isn't any mindshare.
And for good reason. There are so many ergonomic challenges when using Julia in a large codebase and in a large team. Julia has no formal interfaces, LSP suggestions that are often just wrong, and no option types. This just makes writing Julia code a drag. And it makes it quite difficult to advocate to developers experienced with languages that offer these features.
Additionally, the core conceit pushed by Julia advocates is that the language is fast. This is true in controlled benchmarks but in real-world scenarios and in practice it is a real pain to write and maintain code that is fast for high velocity teams because it requires a lot of discipline and a strong understanding of memory allocation and assumptions the Julia can and cannot make. You can write code that is blazingly fast, and then you make a change somewhere else in your program and suddenly your code crawls to a halt. We've had test code that goes from taking 10 minutes to run to over 2 hours because of type instability in a single line of code. Finding this was non-trivial. For reference, if this were uncaught our production version would have gone from 8 hours to 4 days.
The lack of growth really hurts the language. Search for pretty much any topic under the sun and you'll find a Python package and possibly even a Rust crate. In Julia you are usually writing one from scratch. Packages are essential to data processing are contributor strained. If you have a somewhat unpopular open source code code you rely on that doesn't work quite work the way you want it to, you might think I'll just submit a PR but it can languish for months to a year.
The Julia community needs to look at what programming languages are offering that Julia developers want and will benefit from. The software world changing very quickly and Julia needs to change too to keep up.
I just love pythons ease of use, and the few times I've tried Julia it has felt clanky in comparison, and then Jax just makes everything so amazingly fast.
I would be thrilled if Julia had this in early days, but now it is a little too late. I have jumped the boat.