Julia 1.12 highlights

My company (a hedge fund) has been using Julia for our major data/numeric pipelines for 4 years. It's been great. Very easy to translate math/algorithms into code, lots of syntactical niceties, parallelism/concurrency is easy, macros for the very rare cases you need them. It's easy to get high performance and possible to get extremely high performance.

It does have some well-known issues (like slow startup/compilation time) but if you're using it for long-running data pipelines it's great.

In my experience starting with Julia in 2025, the main thing missing from the ecosystem tends to be boring glue type packages, like a production grade gRPC client/server. I heard HTTP.jl is also slow, but I havn't sufficiently dug into this myself. At least we have an excellent ProtoBuf implementation so you can roll your own performant RPC protocol.

As for the actual numerical stuff I tend to roll my own implementations of most algorithms to better control relevant tradeoffs. There are sometimes issues where a particular algorithm is implemented by a Julia package, but has performance issues / bugs in edge cases. For example, in my testing I wasn't able to get ImageContrastAdjustment CLAHE to run very fast and it had an issue where it throws an exception with an image of all zeros. You also can't easily call the OpenCV version as CLAHE is implemented in OpenCV using an object which doesn't have a binding available in Julia. After not getting anywhere within the ecosystem I just wrote my own optimized CLAHE implementation in Julia which I'm very happy with, this is truly where Julia shines. It's worth noting however that there are many excellent packages to build on such as InterprocessCommunication, ResumableFunctions, StaticArrays, ThreadPinning, Makie, and more. If you don't mind filling in some gaps here and there its completely serviceable.

As for the core language and runtime we are deploying a Julia service to production next release and haven't had any stability/GC/runtime issues after a fairly extensive testing period. All of the Python code we replaced led to a ~40% speedup while improvements to numerical precision led to measurably improved predictions. Development with Revise takes some getting used to but once you get familiar with it you will miss it in other languages. All in all it feels like the language is in a good place currently and is only getting better. I'd like to eventually contribute back to help with some of the ecosystem gaps that impacted me.

Disclaimer: I am not plugged into the community.

The other day that old article "Why I no longer recommend Julia" got passed around. On the very same day I encountered my own bug in the Julia ecosystem, in JuliaFormatter, that silently poisoned my results. I went to the GitHub issues and someone else encountered it on the same day. I'm sure they will fix it (they haven't yet, JuliaFormatter at this very moment is a subtle codebase-destroyer) but as a newcomer to the ecosystem I am not prepared to understand which bog standard packages can be trusted and which cannot. As an experiment I switched to R and the language is absolute filth compared to Julia, but I haven't seen anyone complain about bugs (the opposite, in fact) and the packages install fast without needing to ship prebuilt sysimages like I do in Julia. Those are the only two good things about R but they're really important.

I think Julia will get there once they have more time in the oven for everything to stabilize and become battle hardened, and then Julia will be a force to be reckoned with. An actually good language for analysis! Amazing!

Going well, regardless of the regular doom and gloom comments on HN.

https://juliahub.com/case-studies

for many types of scientific computing, there's a case to be made it is the best language available. often this type of computing would be in scientific/engineering organizations and not in most software companies. this is its best niche, an important one, but not visible to people with SWE jobs making most software.

it can be used for deep learning but you probably shouldn't, currently, except as a small piece of a large problem where you want Julia for other reasons (e.g. scientific machine learning). They do keep improving this and it will probably be great eventually.

i don't know what the experience is like using it for traditional data science tasks. the plotting libraries are actually pretty nicely designed and no longer have horrible compilation delays.

people who like type systems tend to dislike Julia's type system.

they still have the problem of important packages being maintained by PhD students who graduate and disappear.

as a language it promises a lot and mostly delivers, but those compromises where it can't deliver can be really frustrating. this also produces a social dynamic of disillusioned former true believers.

My shop just moved back to Julia for digital signal processing and it’s accelerated development considerably over our old but mature internal C++ ecosystem.

I do wonder in particular about the startup time "time-to-plot" issue. I last used Julia about 2021-ish to develop some signal processing code, and restarting the entire application could have easily taken tens of seconds. Both static precompilation and hot reloading were in early development and did not really work well at the time.

  $ time julia -e "exit"
  real    0m0.156s
  user    0m0.096s
  sys     0m0.100s

  $ time julia -e "using Plots"
  real    0m1.219s
  user    0m0.981s
  sys     0m0.408s

  $ time julia -e "using Plots; display(plot(rand(10)))"
  real    0m1.581s
  user    0m1.160s
  sys     0m0.400s

  1.477268 seconds (1.40 M allocations: 89.648 MiB, 2.70% gc time, 7.16% compilation time: 5% of which was recompilation)

I don't think Julia was designed for pure overhead projects in memory-constrained environments, or for squeezing out that last 2% of hardware performance to cut costs, like C++, Rust or Zig.

Julia is the language to use in 2025 if what you’re looking for is a JIT-compiled, multiple-dispatch language that lets you write high-performance technical computing code to run on a cluster or on your laptop for quick experimentation, while also being metaprogrammable and highly interactive, whether for modelling, simulation, optimisation, image processing etc.

Telling what? Did you actually listen to the talk that you linked to, or read the top comment there by Chris Rackauckas?

> Given all that, outside of depending heavily on DifferentialEquations.jl, I don't know why someone would pick Julia over Python + Rust.

See his last slide. And no, they didn't replace their Julia use in its entirety with Rust, despite his organization being a Rust shop. Considering Rust as a replacement for Julia makes as much sense to me as to considering C as a replacement for Mathematica; Julia and Mathematica are domain specific (scientific computation) languages, not general systems programming languages.

Neither Julia nor Mathematica is a good fit for embedded device programming.

I also find it amusing how you criticize Julia while praising Python (which was originally a "toy" scripting language succeeding ABC, but found some accidental "gaps" to fit in historically) within the narrative that you built.

> In any non-toy Julia program that's not going to be the case.

Why?

These are exactly the feelings that I left with from the community in ~2021 (along with the AD story, which never really materialized _within_ Julia - Enzyme had to come from outside Julia to “save it” - or materialized in a way (Zygote) whose compilation times were absolutely unacceptable compared to competitors like JAX)

More and more over time, I’ve begun to think that the method JIT architecture is a mistake, that subtyping is a mistake.

Subtyping makes abundant sense when paired with multiple dispatch — so perhaps my qualms are not precise there … but it also seems like several designs for static interfaces have sort of bounced off the type system. Not sure, and can’t defend my claims very well.

Julia has much right, but a few things feel wrong in ways that spiral up to the limitations in features like this one.

Anyways, excited to check back next year to see myself proven wrong.

There is no "_the_ language to use", I always pick the language based on the project delivery requirements, like what is tier 1 support on a specific SDK, not pick the project based on the language.

Python predates Julia by 3 decades. In many ways Julia is a response to Python's shortcomings. Julia could've never taken off "instead of" python but it clearly hopes to become the mature and more performant alternative eventually

If it is experimental it doesn't allow to create small, redistributable binaries, but allows to hope it will create such binaries.

Though it is quite a progress after years of insisting that this additional package PackageCompiler.jl is all you need.

Very hard to find out how to even get a `juliac` binary unfortunately...

How small are we talking?

BOLT isn't on by default. The main problem is that no one has tested it much (because you can only get it by building your own Julia). We should try distributing BOLT by default. It should just work...

We use it for binary deployments via building simulations into the FMI standard (i.e. building FMUs) https://fmi-standard.org/. We still need to get libraries updated for getting the smallest possible trim when using the more computationally difficult implicit methods, but at least the stack is matured for simple methods like explicit RK and Rosenbrock-type solvers already. For folks interested in --trim on SciML, the PR to watch is https://github.com/SciML/NonlinearSolve.jl/pull/665 which is currently held up by https://github.com/SciML/SciMLBase.jl/pull/1074 which is the last remaining nugget to get the vast majority of the SciML solver set trimming well. So hopefully very soon for anyone interested in this part of the world. Note that does not include inverse problems in the binary as part of small trim.

But all of this is more about maturing the ecosystem to be more amenable to static compilation and analysis. The whole SciML stack had an initiative starting at the beginning of this summer to add JET.jl testing for type inference everywhere and enforcing this to pass as part of standard unit tests, and using AllocCheck.jl for static allocation-free testing of inner solver loops. With this we have been growing the surface of tools that have static and real-time guarantees. Not done yet, some had to be marked as `@test_broken` for having some branch that can allocate if condition number hits a numerical fallback and such, but generally it's getting locked down. Think of it as "prototype in Julia, deploy in Rust", except instead of re-writing into Rust we're just locking down the behavior with incrementally enforcing the package internals to satisfy more and more static guarantees.

I've tried it on some of my julia code. The lack of support for dynamic dispatch severely limits the use of existing libraries. I spent a couple days pruning out dependencies that caused problems, before hitting some that I decided would be more effort to re-implement than I wanted to spend.

So for now we will continue rewriting code that needs to run on small systems rather than deploy the entire julia environment, but I am excited about the progress that has been made in creating standalone executables, and can't wait to see what the next release holds.

it works well --- IF your code is already written in a manner amenable to static analysis. if your coding style is highly dynamic it will probably be difficult to use this feature for the time being (although UX should of course improve over time)

Waiting 15+ seconds to test small changes to my PyTorch training code on NFS is rather annoying. I know there are ways to work around it, but sometimes I wish we could have a training workflow similar to how Revise works. Make changes to the code, Revise patches it, then run it via a REPL on the main node. Not sure if Revise actually works in a distributed context, but that would be amazing if it did. No need to start/fork a million new Python processes every single time.

Of course I would also rather be doing all of the above in Julia instead of Python ;)