This month in Julia World - 2026-07

Community Newsletter
1

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

If you want to receive the newsletter as an email, subscribe to the Community–Newsletter category on Discourse.

Current status (as of July 30th): Julia release is 1.12.6, Julia LTS is 1.10.11. The 1.13.0-rc1 is available for testing. The master branch is at 1.14.0-DEV.2851.

Core repos

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

  • fetch(::Task) is now well-inferred, thanks to work by Jameson. This feature has been requested for years, and its absence has been the motivation for the package StableTasks.jl. This has been achieved through two changes: First, the compiler now separately tracks the inferred return type per-task, and automatically typeasserts fetch. Second, tasks now can carry a CodeInstance which is invoked directly when the task starts, avoiding a dynamic dispatch (which therefore should make fetch trimmable). Most users will experience this as task-heavy concurrent programs becoming slightly more type stable.

  • Keno has continued work on adding cancellation to Julia, first mentioned in the December 2025 version of this newsletter. Now, cancellation has a .NET-like cancellation token API. Cancellation means that a user has the ability to stop a running Task from the outside in a controlled manner, by having it raise an exception. While it sounds simple in principle (just jump to the task and throw an exception), a proper implementation needs to make sure cancellation does not leave the cancelled Task’s code itself in an undefined state. There is also scheduling bookkeeping related to cancellation: The scheduler needs to know not to re-schedule a cancelled task, all tasks waiting for the cancelled task need to be cancelled themselves, and so on. A common use case for cancellation is interrupting a computation with Ctrl-C; the considerations above explain why this cannot be done consistently by current versions of Julia.

  • Meanwhile, Ian has been working to improve Ctrl-C interruption somewhat on current master, before a new cancellation API with well-defined semantics lands [1, 2].

  • Patrick Häcker has given us a @methods macro that returns all applicable methods. You can pass it variables (such as @methods isvalid('a', 1)) or a signature (such as @methods isvalid(::AbstractChar, ::Integer)) and it returns a list of matching methods.

  • Julia now has explicitly wrapping integer arithmetic functions like -%, +%, *% etc., thanks to work by Keno. It is part of the documented semantics of integer arithmetic in Julia that bit-integers overflow with two’s complement (i.e. wrapping) due to performance reasons. However, in most uses of integer arithmetic, overflow is a bug and not intentional behavior. The new explicitly-wrapping functions signal that wrapping overflow for this operation is semantically expected, e.g. in some cryptographic functions. This enables a future mechanism where authors can opt-in to checking all ordinary arithmetic e.g. during testing, while not checking the explicitly wrapping ones. Such an opt-in mechanism is tentatively provided as Base.Experimental.@make_all_arithmetic_checked.

  • Due to work by Max Horn, Julia now supports odd-sized primitive types, such as 11-bit primitives. This was previously disabled partly due to LLVM’s support for these types being buggy. However, because such types are common in the Zig language, Zig developers have improved LLVM support to the point where it is now acceptably working. Long term future follow-up work could be support for odd-sized bit-integers, and niche optimizations for Julia Unions, such that e.g. a Union{Nothing, Int31} could be stored inline in 32 bits.

  • Keno’s work on improving binding semantics continues as he works on supporting changing the type of typed globals: [PR1, PR2]. One current blocker seems to be whether this can be done without slowing down compiler performance too much.

  • Atomics in Julia used to be provided through the Atomic type. In recent years, per-field atomics have been favored instead, as they have better (safer, more flexible, and faster) semantics, especially after recent performance improvements and the addition of reference-assignment syntax to per-field atomics. A new PR by Jameson makes the old Atomic type support the new reference-assignment syntax. At this point, Atomic is simply a normal mutable struct with an atomic field, and its methods forward to the per-field atomic API. Almost all uses of Atomic are better done by using an atomic field directly instead of the Atomic wrapper, analogous to how most mutation of structs should be done using a mutable struct instead of mutating a Base.RefValue wrapper in an immutable struct. A planned future change aims to deprecate non-@atomic assignment to Atomic, as it is a footgun that too easily results in a silently non-atomic operation.

  • James Wrigley has added a new Base-internal mechanism that selectively disables world-splitting for a function. It is a more aggressive version of the existing Base.Experimental.@max_methods which merely reduces the world splitting threshold.

  • code_warntype now highlights type unstable or union-split SSA values in red and yellow, respectively, thanks to a PR by Lars Göttgens. This is a small, but noticeable, readability improvement that has been requested for a long time.

  • Ian Butterworth has pointed Claude and GPT-5.6-sol at the Profile standard library for some deep cleaning, including significant performance improvements, especially to the memory profiler which got a 59x speedup when recording allocations, as well as a long list of bugfixes.

  • JuliaLowering is maturing and looks like it might become ready for Julia v1.14 (no promises though)! Recent changes, all by Em Chu, include: tonnes of bugfixes, syntax versioning, and a remarkable PR which improves JuliaLowering performance around 4x while being net negative 700 LOC! The performance changes should make JuliaLowering faster than the existing flisp lowering, and should speed up JETLS noticeably. Syntax versioning was first mentioned in the December 2025 version of this newsletter and probably deserves its own writeup.

  • JETLS is also maturing. A recent application of JETLS to Base exposed many bugs and blemishes in Base code, highlighting how a good Julia language server could improve code across the ecosystem. JETLS author Shuhei Kadowaki will present the current state of JETLS at JuliaCon this year.

  • Cody Tapscott’s original TypedCallable PR is now being revived, this time backed by a new (internal) DispatchTrampoline mechanism, also authored by Cody. A x::TypedCallable{A, B} wraps any callable f(::A)::B, and calling x calls f through dynamic dispatch. However, TypedCallable’s dynamic dispatch is faster than ordinary dynamic dispatch, and fully inferrable and trimmable, if A and B are concrete, and f itself is inferrable. This allows code where dynamic dispatch is unavoidable to still be inferred and trimmed, and is therefore an important step towards making trimming more widely usable.

  • A very experimental PR by Oscar aims to replace malloc with a home-rolled allocator for Julia allocation paths. Julia would still use malloc for e.g. externally managed allocations. The idea behind home-rolling an allocator is presumably to integrate it with Julia’s GC, which would provide the allocator more information about Julia’s allocation patterns and would improve performance.

  • Keno made an experimental PR that introduces the enum keyword. For now, the proposed Julian enums are only integer-like (like existing Julia @enums, but unlike Rust’s enum), but the keyword may be enhanced in the future to a fully-fledged generic sum type, like the Moshi.jl package currently provides. Authors may declare an enum extensible, in which case downstream packages can add more variants to an enum. The compiler will then update the type at load time such that it remains a bitstype. This proposal is still very early and no doubt the semantics will have to be worked out in detail.

  • In another of Keno’s ambitious experimental PRs, he introduces UnifiedIR, a new package that contains a new type of intermediate representation (IR) of Julia code. The main purpose of UnifiedIR is to unify and simplify several existing Julia IRs into one unified type, and to make this type more amenable to external users working on it. The PR itself provides the new IR, along with utilities to work on it. The main implication of a feature like this will probably be that it makes Julia metaprogramming and compiler hooks easier to work with and more stable. The PR itself is a 30 kLOC AI-generated prototype, so is intended to provide a basis for design discussion, and is very far from being ready to merge.

  • In the December 2025 newsletter we mentioned Keno’s AI-generated prototype of match statements and declared exceptions. He has now opened version 2 of the prototype, with improvements over the former. You can experiment with it yourself by cloning and building the branch.

  • In yet another speculative PR, this time by Julius Krumbiegel, world splitting is disabled by default. As expected, this greatly reduces invalidations, but also greatly reduces runtime speed as many previously-inferred call sites now infer as Any. As part of the PR, some of the regressions in the compiler were fixed by type-stabilization. However, it is not clear whether impacted code in general would be just as easy to migrate, nor are the load time improvements clear; the PR shows modest load time improvements, but since the code loading code itself is affected by the runtime degradations, these results are difficult to interpret.

  • Julia has a TOML parser, but some environment loading code predates the TOML parser and makes use of a stateless, regex-based parser. As a result, environment parsing is handled by two different parsers in two different ways. A new PR by Kristoffer centralizes the environment parsing code and parses the environment more eagerly. Besides simplifying the parsing logic, the results are stored in memory after parsing and can be queried much more efficiently.

  • In JuliaCon 2025, Stefan Karpinski presented a new resolver for Pkg. This resolver is now being tidied up and made ready for integration into Pkg. The main advantage of the new resolver is expected to be the ability to solve for other goals than the newest packages. For example, compat tests need the oldest compatible packages, and users may prefer packages they already have precompiled. The new resolver should also give more legible errors when a solution cannot be found.

  • Julia developers need usage statistics about packages in order to obtain funding and to know what is worth working on. However, Julia’s package servers do not collect telemetry data on package downloads due to community pushback over privacy concerns. A new protocol based on HyperLogLog and public key cryptography enables the Pkg servers to estimate the number of package users without collecting any information that can be used to track any individual user or even small group of users. This is not a matter of encrypting personally identifiable information, but instead estimating cardinality from statistical patterns in non-identifiable information. A new draft PR adds this protocol to Pkg. The protocol itself has also been discussed on Discourse.

  • The Memory PR back in Julia 1.11 severely regressed compile times by moving foundational Array operations from C to Julia. A new PR by Gabriel claws a bit of it back by removing redundant double-boundschecks that resulted from both the Array and its underlying MemoryRef performing boundschecks. This PR is an interesting example of the tension that results from moving lower level abstractions into Julia from C. On one hand, it may improve performance by enabling Julia level optimization deeper through the call stack. On the other hand, it results in more Julia-level code being generated and therefore harms compile times.

Other community news

  • The Julia VSCode extension has released version 1.224. The new version is both much faster and more memory efficient, and its language server also exhibits far fewer false positives. These changes are due to extensive changes in the extension’s internals, which are now powered by the JuliaWorkspaces.jl and Salsa.jl packages. Sebastian Pfitzner, the core maintainer of the Julia VSCode extension, will give a talk at JuliaCon 2026 about this rehaul of the extension’s internals.

  • The Revise.jl package is a staple for all Julia developers. The new version 3.16.1 brings important improvements: Thanks to heroic optimization work by Tim Holy, struct revision is finally fast, and will become enabled by default in the next minor release. Revise is also more robust now: It runs in a frozen world age, so its methods now cannot be invalidated. In preparation for the release, Tim has resolved most of Revise’s open issues, such as revisions that didn’t work correctly, so Revise should work correctly in more edge cases. Finally, the new version also brings new features.

  • Wired Magazine released a short article about Julia. In it, the author briefly presents Julia and its raison d’être, and its failure to become a popular language.

  • Fons van der Plas is quitting as Pluto maintainer. Fons was the main developer behind Pluto.jl, which has helped countless students learn Julia - beside being a great and novel notebook framework. We wish Fons all the best for his future ventures, and are grateful for all the work he put in the Julia ecosystem over the years.

2

Jakob, Thanks for continuing the tradition of: This month in Julia World. It means so much to a casual Julia programming like myself. The amount of detail in the description for each topic if spot on…Archie