This month in Julia world - 2025-03

[Krastanov]

A monthly newsletter, mostly on julia internals, digestible for casual observers. A biased, incomplete, editorialized list of what I found interesting this month, with contributions from the community.

Call for proposals now open for JuliaCon Local Paris.

Tickets are now available for JuliaCon Global 2025 in Pittsburgh.

“Internals” Fora and Core Repos (Slack/Zulip/Discourse/Github):

• Julia 1.12-beta1 is out, check out the release notes.

• In a recent push to reduce invalidations in Base, Neven Sajko has made a flurry of small improvements to inference. This should improve TTFX in Julia 1.13.

• The Julia REPL has autocompletion, which is surprisingly complex and has been the source of many bugs. A complete overhaul based on the new JuliaSyntax parser is on its way, fixing many outstanding bugs.

• LinearAlgebra is part of the Julia system image, contributing to memory consumption and startup time, even when the package is not used. To address this, there has been recent work towards making LinearAlgebra lazily loaded.

• try without a catch block but with a return/break/continue in a finally block is really weird (broken?) in multiple languages. At least it is now properly tracked as an issue. (slack discussion)

• @test is particularly neat in how it forwards kwargs to the function call being tested. This might get added to @assert as well.

• The “performance tips” doc page has been growing in the 1.13 branch. E.g. see new notes on TTFX and on profiling slow precompilation.

• How can you make variable length tuples without allocations.

• Code-coverage might get quite a bit faster thanks to this PR.

• Tools like @code_typed f(some_argument) are great, but it would even nicer if we can just write the type without having to have an actual instance like in @code_typed f(::SomeType). Potentially soon to be available.

• Julia’s tests now include automated checks that new contributions do not cause invalidations, of great use in preventing regressions.

• A lot of changes happened to the internals for the upcoming 1.12, breaking PrecompileTools in the process, but that is now fixed.

• The names of ccallables created by Julia can now be more easily customized.

• Julia’s initialization when started embedded on a thread of another process is getting simpler.

• Considering a variety of different techniques for more efficient waking up of Julia threads when new tasks become available.

• Work on improvements to type inference thanks to interprocedural propagation of slot refinements.

• There have been some significant TTFX/precompilation/invalidation issues with the recently added StyleStrings – otherwise a very impressive tool, enabling much richer text output in julia. A very informative discussion on the difficulties with structuring standard libraries and avoiding piracies and invalidations.

Ecosystem Fora, Maintenance, and Colab Promises (Slack/Zulip/Discourse/Github):

• Julia is now officially supported in Google Colab!!! This includes running Lux & Reactant on TPUs.

• Documenter 1.9 now properly filters by the public keyword, potentially breaking in some edge cases.

• AlgebraOfGraphics.jl has had a lot of recent improvements, including the release of v0.10 as well as a new comprehensive introductory tutorial series.

• BeforeIT.jl - High-Performance Agent-Based Macroeconomics in Julia

• SmithChart.jl - Visualize Smith charts with Makie.jl

• DeviceLayout.jl - CAD for quantum integrated circuits

Julia Autodiff ecosystem:

• DifferentiationInterface.jl had a big release related to significant improvements in allocation-free sophisticated gradient computations. (slack discussion)

• A slightly-breaking ForwardDiff v1 is now released (slack discussion) thanks to finishing a PR on properly dealing with zero-measure edge cases (see related issue)

Mathematica Optimization ecosystem:

• Optim.jl has had some very significant updates and improvements, including now support for DifferentiationInterface.jl.

Notes from other ecosystems:

• Low-level matrix optimization on AMD GPUs

• Benchmark of autodiff tools in various languages

• “Programming Massively Parallel Processors” - a neat book on structuring algorithms for devices like GPUs from first principles

Events:

• The QNumerics summer school on numerical methods in quantum information science is open for registration.

• Rust x Julia Eindhoven Meetup (requires a Meetup account)

See also: French community newsletter, community calendar, minutes of triage meetings

Please feel free to post below with your own interesting finds, or in-depth explanations, or questions about these developments.

If you would like to help with the draft for next month, please drop your short, well formatted, linked notes in this shared document. Some of it might survive by the time of posting

[nsajko]

@Krastanov

• In a recent push to reduce invalidations in Base, Neven Sajko has made a flurry of small improvements to inference. This should improve TTFX in Julia 1.13.

These PRs are getting backported as far back as possible, so improvements should happen for v1.10, v1.11 and v1.12, too

Still need to prepare manual backport PRs for some of them, though.

@Krastanov

• Julia’s tests now include automated checks that new contributions do not cause invalidations, of great use in preventing regressions.

That proposal is a bit speculative, it’s not clear whether it will be merged. I hope one day something like that will be mergeable, but merging it right now might prove to be too annoying to contributors, even though preventing regressions would be valuable. I’m thinking maybe it’d make sense to merge it anyway (after it passes tests on all platforms), but then revert if it proves to be overly annoying.

Also, to be clear, the PR doesn’t attempt to test for any possibility of invalidation of the sysimage (that would require ensuring it’s completely type stable, I think), it just tests that there’s no invalidation when running certain handpicked workloads, where each workload just adds a type and a method involving that type.

In any case it’d also be nice to have data on invalidation for each commit on the Git master branch, then we could have nice visualizations like https://tealquaternion.camdvr.org/ does for benchmarks.

EDIT: another option that crossed my mind, would be to have CI make a comment with data on invalidations before and after, for each PR. That would be less disruptive to the contributing process than testing for invalidation in the test suite.