[HN Gopher] Julia 1.12 highlights
___________________________________________________________________
Julia 1.12 highlights
Author : pella
Score : 131 points
Date : 2025-10-08 18:42 UTC (4 hours ago)
(HTM) web link (julialang.org)
(TXT) w3m dump (julialang.org)
| alhirzel wrote:
| Has anyone tried the `--trim` option? I wonder how well it works
| in "real life".
| pavon wrote:
| 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.
| postflopclarity wrote:
| 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)
| jakobnissen wrote:
| 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 wrote:
| 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.
| culi wrote:
| 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 wrote:
| 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 wrote:
| 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.
| SatvikBeri wrote:
| In 2012, python was already well-established in ML, though
| not as dominant as it is today. scikit-learn was already
| well-established and Theano was pretty popular. Most of the
| top entries on Kaggle were C++ or Python.
| doctoboggan wrote:
| 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?
| pjmlp wrote:
| Going well, regardless of the regular doom and gloom comments
| on HN.
|
| https://juliahub.com/case-studies
| doctoboggan wrote:
| One of those case studies is me at my former company. We
| ended up moving away from Julia
| pjmlp wrote:
| Because of Julia flaws, or management decisions completely
| unrelated to the tooling?
| doctoboggan wrote:
| We were a startup and I was the "management", but it was
| mostly for HR reasons. The original dev who convinced me
| to try Julia ended up leaving, and when we pivoted to a
| new niche that required a rethinking of the codebase, we
| took the opportunity to re-write in C# (mostly because a
| we _needed_ C# to develop a plugin, and it would simplify
| things if everything was C#).
| SatvikBeri wrote:
| 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.
| nextos wrote:
| What kind of library stack do you use? Julia has lots of
| interesting niche libraries for online inference, e.g.
| Gen.jl.
| TimorousBestie wrote:
| 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.
| csvance wrote:
| 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 wrote:
| How do you deploy it?
| TimorousBestie wrote:
| StaticCompiler.jl is the main workhorse.
| __atx__ wrote:
| 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 wrote:
| 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 wrote:
| That was fixed in 1.9. Indeed it makes a huge difference now
| that you can quickly run for the first time.
| pavon wrote:
| 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.
| electroly wrote:
| 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!
| postflopclarity wrote:
| 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.
| electroly wrote:
| That's fair, and my bug _was_ in 2.x, but it doesn 't
| really make me feel better. If anything, I feel worse
| knowing this is OffsetArrays again--the ecosystem made
| cross-cutting changes that it doesn't have the manpower to
| absorb across the board, so everything is just buggy
| everywhere as a result. This is now a pattern.
|
| The codebase destruction warning was not super loud,
| though. Obviously I missed it despite using JuliaFormatter
| constantly. It doesn't get printed when you install the
| package nor when you use it. It's not on the docs webpage
| for JuliaFormatter. 2.x is still the version you get when
| you install JuliaFormatter without specifying a version.
| The disclaimer is only in the GitHub readme, and I was
| reading the docs. What other packages have disclaimers that
| I'm not seeing because I'm "only" reading the user
| documentation and not the GitHub developer readme?
| postflopclarity wrote:
| > so everything is just buggy everywhere as a result
|
| I don't think this is an accurate summary. the bug here
| is that JuliaFormatter should put a <=1.9 compatibility
| bound in its Project.toml if it isn't correct with
| JuliaSyntax.jl
|
| OffsetArrays was different because it exposed a bunch of
| buggy and common code patterns that relied on (incorrect)
| assumptions about the array interface.
| currymj wrote:
| 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.
| cyberax wrote:
| 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.
| csvance wrote:
| 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 ;)
| andyferris wrote:
| 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.
| sundarurfriend wrote:
| > 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?
| doppioandante wrote:
| Being able to redefine structs is what I always wanted when
| prototyping using Revise.jl :) great to have it
| Archit3ch wrote:
| 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.
| ModernMech wrote:
| How small are we talking?
| blindseer wrote:
| 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.
| tagrun wrote:
| 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. 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 succeeding ABC,
| but found some accidental "gaps" to fit in historically) within
| the narrative that you built.
| wolvesechoes wrote:
| 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.
| wrathofmonads wrote:
| 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.
| mccoyb wrote:
| 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.
| andyferris wrote:
| 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 wrote:
| 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!
___________________________________________________________________
(page generated 2025-10-08 23:00 UTC)