Julia 1.12 highlights

https://julialang.org/blog/2025/10/julia-1.12-highlights/

by pella • 10 months ago

194 94 10 months ago

alhirzel• 10 months ago

Has anyone tried the `--trim` option? I wonder how well it works in "real life".

pavon2• 10 months ago

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.

postflopclarity5• 10 months ago

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)

ChrisRackauckas2• 10 months ago

v1.13 already has a good number of improvements to trim in the cases which are less analyzable, but even then I think the best thing for the package ecosystem is to start to become really good for trim, JETLS, etc. through statically checking things.

ChrisRackauckas2• 10 months ago

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.

jakobnissen3• 10 months ago

So much goodness in this release. Struct redefinition combined with Revise.jl makes development much smoother. Package apps are also an amazing (and long awaited) feature!

I can't wait to try out trimming and see how well it actually works in its current experimental instantiation.

clickety_clack• 10 months ago

I wish a) that I was a Julia programmer and b) that Julia had taken off instead of python for ML. I’m always jealous when I scan the docs.

culi2• 10 months ago

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

williamstein• 10 months ago

Some small additional details: 23 years not 30. Also, I think Julia was started as much in response to Octave/Matlab’s shortcomings. I don’t know if it is written down, but I was told a big impetus was that Edelman had just sold his star-p company to Microsoft, and star-p was based around octave/matlab.

- https://julialang.org/blog/2012/02/why-we-created-julia/

gooodvibes• 10 months ago

When Julia came out neither Python nor data science and ML had the popularity they have today. Even 7-8 years ago people we're still having Python vs R debates.

doctoboggan3• 10 months ago

How's the Julia ecosystem these days? I used it for a couple of years in the early days (2013-2016ish) and things initially felt like they were going somewhere, but since then I haven't seen it make much inroads.

Any thoughts from someone more plugged in to the community today?

pjmlp8• 10 months ago

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

https://juliahub.com/case-studies

doctoboggan3• 10 months ago

One of those case studies is me at my former company. We ended up moving away from Julia

ofrzeta2• 10 months ago

There's only one case study from 2025, though.

SatvikBeri3• 10 months ago

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.

nextos2• 10 months ago

What kind of library stack do you use? Julia has lots of interesting niche libraries for online inference, e.g. Gen.jl, which can be quite relevant for a hedge fund.

If you can't talk about library stacks, it'd be at least interesting to hear your thoughts about how you minimize memory allocation.

TimorousBestie2• 10 months ago

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.

csvance4• 10 months ago

Mine did the same for image processing but coming from python/numpy/numba. We initially looked at using Rust or C++ but I'm glad we chose to stick it out with Julia despite some initial setbacks. Numerical code flows and read so nicely in Julia. It's also awesome seeing the core language continuously improve so much.

zerr• 10 months ago

How do you deploy it?

nextos2• 10 months ago

Can you elaborate on what libraries, platform, and tooling you use?

__atx__• 10 months ago

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.

moelf• 10 months ago

on a macMini (i.e. fast RAM), time to display:

- Plots.jl, 1.4 seconds (include package loading)

- CairoMakie.jl, 4 seconds (including package loading)

julia> @time @eval (using Plots; display(plot(rand(3))))

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

j_maffe• 10 months ago

That was fixed in 1.9. Indeed it makes a huge difference now that you can quickly run for the first time.

pavon2• 10 months ago

On a 5 year old i5-8600, with Samsung PM871b SSD:

  $ 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

Not a super fair test since everything was already hot in i/o cache, but still shows how much things have improved.

electroly2• 10 months ago

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!

postflopclarity5• 10 months ago

just to be fair, the very first words in the README for JuliaFormatter is a warning that v2 is broken, and users should stick to v1. so it is not a "subtle" codebase-destroyer so much as a "loud" codebase-destroyer.

currymj• 10 months ago

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.

gugagore2• 10 months ago

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

This is true. As far as I understand it, there is not a type theory basis for Julia's design (type theory seems to have little to say about subtyping type lattices). Relatedly, another comment mentioned that Julia needs sum types.

csvance4• 10 months ago

I work in the medical device industry and most people on my team have engineering degrees and extensive experience with Matlab. Pretty much all of them would flip their table if they had to write numerical/scientific code in Rust, even though it arguably has a more robust type system.

csvance4• 10 months ago

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.

cyberax• 10 months ago

I think Julia missed the boat with Python totally dominating the AI area.

Which is a shame, because now Python has all the same problems with the long startup time. On my computer, it takes almost 15 seconds just to import all the machine-learning libraries. And I have to do that on every app relaunch.

csvance4• 10 months ago

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 ;)

andyferris2• 10 months ago

Revise can work on your server for hot reloading if you need it - you copy your new code files in place over the old ones.

Of course there are caveats - it won't update actively running code, but if your code it's structured reasonably and you are aware of Revise's API and the very basics of Julia's world age you can do it pretty easily IME.

sundarurfriend3• 10 months ago

For example, the all-inference benchmarks improve by about 10%, an LLVM-heavy workload shows a similar ~10% gain, and building corecompiler.ji improves by 13–16% with BOLT. When combined with PGO and LTO, total improvements of up to ~23% have been observed.
To build a BOLT-optimized Julia, run the following commands

Is BOLT the default build (eg. fetched by juliaup) on the supported Linux x86_64 and aarch64? I'm assuming not, based on the wording here, but I'm interested in what the blocker is and whether there's plans to make it part of the default build process. Is it considered as yet immature? Are there other downsides to it than the harmless warnings the post mentions?

adgjlsfhk12• 10 months ago

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...

sundarurfriend3• 10 months ago

Juliaup can now install PR builds IIRC, so having someone make a PR that just changes the Makefile to do this BOLT based build would be an option too. Less potentially disruptive than making it the default straight off, while still being much more convenient to the user than having to do custom compilation.

doppioandante• 10 months ago

Being able to redefine structs is what I always wanted when prototyping using Revise.jl :) great to have it

Archit3ch3• 10 months ago

This is it. Anyone who's anyone has been waiting for the 1.12 release with the (admittedly experimental) juliac compiler with the --trim feature. This will allow you to create small, redistributable binaries.

ModernMech3• 10 months ago

How small are we talking?

adgjlsfhk12• 10 months ago

~1MB for hello world (almost all of which is runtime), fairly complicated simulations in ~50 MB (solving 500 state ODEs with implicit solvers)

wolvesechoes4• 10 months ago

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.

Archit3ch3• 10 months ago

Honest take: yes, it's not ready. When I tried it, the generated binary crashed.

For what it's worth, I am able to generate a non-small (>1 GiB) binary with 1.11 that runs on other people's machines. Not shipping in production, but it could be if you're willing to put in the effort. So in a sense, PackageCompiler.jl is all you need. ;)

pepa65• 10 months ago

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

Archit3ch3• 10 months ago

Disclaimer: this is early, experimental, subject to change, etc. Notably, there are reports that it doesn't work in Windows. It works here on Mac, but YMMV.

1) Install juliaup following the instructions for your platform from julialang.org

2) Install julia 1.12 with `juliaup add 1.12` and switch to it `juliaup default 1.12`.

3) Start a standard julia 1.12 REPL with `julia --project=.` This is the "Outer" project that will do the compiling (PackageCompiler.jl terminology, might not be necessary now that juliac can run from the command line).

4) Install juliac with `] app add JuliaC`. The ']' character opens the package manager. You might need to add Julia's app location to your PATH in .zshrc with `export PATH="/home/ccp/.julia/bin:$PATH"` and restart your shell (I had this already from earlier attempts with 1.12 beta).

5) Create a new project with `] generate AppProject`. This is the "Inner" project that will be compiled. Put the example AppProject code from the julia 1.12 announcement in src/AppProject.jl

6) Run the example command `juliac --output-exe app_test_exe --bundle build --trim=safe --experimental ./AppProject` while in the "Outer" directory. You should be able to run it as in the announcement `./build/bin/app_test_exe`

blindseer4• 10 months ago

I'm excited to see `--trim` finally make it, but it only works when all code from entrypoints are statically inferrable. In any non-toy Julia program that's not going to be the case. Julia sorely needs a static mode and a static analyzer that can check for correctness. It also needs better sum type support and better error messages (static and runtime).

In 2020, I thought Julia would be _the_ language to use in 2025. Today I think that won't happen until 2030, if even then. The community is growing too slowly, core packages have extremely few maintainers, and Python and Rust are sucking the air out of the room. This talk at JuliaCon was a good summary of how developers using Rust are so much more productive in Rust than in Julia that they switched away from Julia:

https://www.youtube.com/watch?v=gspuMS1hSQo

Which is pretty telling. It takes a overcoming a certain inertia to move from any language.

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

tagrun3• 10 months ago

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?

wolvesechoes4• 10 months ago

Python has useful and rich ecosystem that grows every day. Julia is mostly pile of broken promises (it neither reads as Python, nor it runs as C, at least not without significant effort required to produce curated benchmarks) and desperate hype generators.

blindseer4• 10 months ago

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

To clarify exactly where I'm coming from, I'm going to expand on my thoughts here.

What is Julia's central conceit? It aims to solve "the two language" problem, i.e. the problem where prototyping or rapid development is done in a dynamic and interactive language like Python or MATLAB, and then moved for production to a faster and less flexible language like Rust or C++.

This is exactly what the speaker in the talk addresses. They are still using Julia for prototyping, but their production use of Julia was replaced with Rust. I've heard several more anecdotal stories of the exact same thing occurring. Here's another high profile instance of Julia not making it to production:

https://discourse.julialang.org/t/julia-used-to-prototype-wh...

Julia is failing at its core conceit.

Julia as a community have to start thinking about what makes a language successful in production.

Quote from the talk:

"(developers) really love writing Rust ... and I get where they are coming from, especially around the tooling."

Julia's tooling is ... just not good. Try working several hundred thousand line project in Julia and it is painful for so many reasons.

If you don't have a REPL open all the time with the state of your program loaded in the REPL and in your head, Julia becomes painful to work in. The language server crashes all the time, completion is slow, linting has so many false positives, TDD is barebones etc. It's far too easy to write type unstable code. And the worst part is you can write code that you think is type stable, but with a minor refactor your performance can just completely tank. Optimizing for maintaining Julia code over a long period of time with a team just feels futile.

That said, is Python perfect? Absolutely not. There's so many things I wish were different.

But Python was designed (or at the very least evolved) to be a glue language. Being able to write user friendly interfaces to performant C or C++ code was the reason the language took off the way it did.

And the Python language keeps evolving to make it easier to write correct Python code. Type hinting is awesome and Python has much better error messages (static and runtime). I'm far more productive prototyping in Python, even if executing code is slower. When I want to make it fast, it is almost trivial to use PyO3 with Rust to make what I want to run fast. Rust is starting to build up packages used for scientific computing. There's also Numba and Cython, which are pretty awesome and have saved me in a pickle.

As a glue language Python is amazing. And jumping into a million line project still feels practical (Julia's `include` feature alone would prevent this from being tenable). The community is growing still, and projects like `uv` and `ty` are only going to make Python proliferate more.

I do think Julia is ideal for an individual researcher, where one person can keep every line of code in their head and for code that is written to be thrown away. But I'm certainly not betting the near future on this language.

wrathofmonads3• 10 months ago

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.

throwawaymaths2• 10 months ago

actually I think it sort of was, I remember berkeley squeezing a ton of perf out of their cray for a crazy task because it was easy to specialize some wild semi-sparse matrix computations onto an architecture with strange memory/cache bottlenecks, while being guaranteed that the results are still okay.

mccoyb2• 10 months ago

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.

jakobnissen3• 10 months ago

I basically agree with subtyping (but not multiple dispatch). More importantly, I think it's important to recognize that Julia has a niche that literally no one can compete with - interactive, dynamic and high performance.

Like, what exactly is the alternative? Python? Too slow. Static languages? Unusable for interactive exploration and data science.

That leaves you with hybrids, like Python/Cython, or Python/Rust or Numba, but taken on their own term, these are absolutely terrible languages. Python/Rust is not safe (due to FFI), certainly not pleasant to develop in, and no matter how you cut your code between the languages, you always lose. You always want your Python part to be in Rust so you get static analysis, safety and speed. You always want your Rust part to be in Python, so you can experiment with it easier and introspect.

pjmlp8• 10 months ago

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.

andyferris2• 10 months ago

Wow, there are so many amazing practical improvements in this release. It's better at both interactive use _and_ ahead-of-time compilation use. Workspaces and apps and trimmed binaries are massive - letting it easily do things normally done in other languages. It will be interesting so see what "traditional" desktop software will come out of that (CLI tools? GUI apps?).

I am so excited - well done everyone!

__grob• 10 months ago

This is a fantastic release, been looking forward to --trim since the 2024 JuliaCon presentation. All of the other features look like fantastic QoL additions too - especially redefinition of structs and the introduction of apps.

Congrats Julia team!

zahlman• 10 months ago

Somehow I thought Julia had been around for much longer than this.

Julia 1.12 highlights

Related Stories