# This month in Julia World - 2026-10

**URL:** <https://discourse.julialang.org/t/this-month-in-julia-world-2026-10/141631>\
**Category:** Newsletter\
**Created:** [November 1, 2026, 12:36pm UTC](https://discourse.julialang.org/t/this-month-in-julia-world-2026-10/141631 "2026-11-01T12:36:53Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![jakobnissen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jakobnissen/32/13477_2.png) [@jakobnissen](https://discourse.julialang.org/u/jakobnissen)\
**Post date:** [November 1, 2026, 12:36pm UTC](https://discourse.julialang.org/t/this-month-in-julia-world-2026-10/141631/1 "2026-11-01T12:36:53Z")

</div>

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](https://discourse.julialang.org/c/community/news/66).

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](https://hackmd.io/@stefan/Hk9CHPzMbe/edit). Some of it might survive by the time of posting

I am pulling back from writing these monthly newsletters for the foreseeable future, because my personal life suddenly got very busy: Like Stefan who edited the newsletter before me, I also had a baby! I hope someone, or several people, will step up to continue the newsletter.

### General

Current status (as of 2026-11-01): The latest Julia release is 1.13.3, and the LTS release is 1.10.12. The master branch is at 1.15.0-DEV.318, and Julia 1.14-alpha2 is available for testing.

Julia development is accelerating. The number of opened PRs to JuliaLang/julia went from 297 in July, 282 in August (where JuliaCon took out about a week’s time), 435 in September, and 752 in October. A year ago, the repo merged less than 50 commits a week, now it merges around 125. Kristoffer Carlsson alone has opened more than 100 PRs to JuliaLang/julia in October.

This is probably partially because AI agents speed up development in general, but may also be because AI agents facilitate a workflow where a developer does a deep dive into a subject and makes a spree of smaller PRs related to that subject. For this reason, some of the many changes this month is not easily summarized by single PRs that I can link to.

### Core repos

- Ian Butterworth and Kristoffer Carlsson have been working hard improving latency: They have been improving significantly on [the Julia performance tracker](https://perf.julialang.org/?tab=overview) to instrument where to look. Then, they have contributed dozes of latency-reducing PRs to Julia this month. All their PRs have not yet landed, but it is already clear that Julia 1.14 will have load times, precompile times and hot-cache script run times 30-50% lower than Julia 1.10, making 1.14 the fastest Julia release by far. This has been achieved incrementally, via a large number of PRs, many improving compile times by just a few percent. There are too many PRs to list them individually, but one PR especially stands out: [#63656](https://github.com/JuliaLang/julia/pull/63656), which cut load times by about 30%. In my opinion, Ian’s and Kristoffer’s efforts may result in the greatest user experience improvement in Julia since its 1.0 release in 2018.

- Jacob Quinn and Kristoffer Carlsson has brought some of the parsing infrastructure from Parsers.jl to Base Julia. This includes [speeding up decimal integer parsing](https://github.com/JuliaLang/julia/pull/63615), [hex parsing](https://github.com/JuliaLang/julia/pull/63765), re-implementing [float parsing in Julia](https://github.com/JuliaLang/julia/pull/63808), and [speeding up UUID parsing](https://github.com/JuliaLang/julia/pull/63970) and [Bool parsing](https://github.com/JuliaLang/julia/pull/63971). The new code lives in a Base.Parsers, and has an API different from `Base.parse`, which [is still not public](https://github.com/JuliaLang/julia/pull/63969). The main benefit of the new API is that its failure return value tells the user what specific parsing failure occurred. This allows users to e.g. pick a wider type if integer parsing failed due to overflow.

- At JuliaCon 2025 more than a year ago, Stefan Karpinski [revealed](https://www.youtube.com/watch?v=Vab6en-6o6c) his new [SAT-based package resolver](https://github.com/JuliaLang/Resolver.jl). This [now powers Pkg.jl](https://github.com/JuliaLang/Pkg.jl/pull/4738). It’s faster, provides pareto-optimal solutions, and gives better resolution conflict messages. It can also be upgraded later to allow resolving for other orderings, like choosing the oldest packages or optimizing for minimal download.

- Julia’s installed size has grown significantly over time, from about 600 MB in Julia 1.10, to over 1,000 MB on Julia 1.13, and pushing 1,250 MB on nightly a month ago. To combat this, Kristoffer Carlsson has built [a Rust CLI tool](https://github.com/KristofferC/pkgimg) to inspect package- and system images, allowing him to see what bloats the images. He has also [started tracking these sizes on perf.julialang.org](https://github.com/JuliaCI/julia-ci-timing/pull/53). Using the tool, he has made a large number of PRs to reduce the installation size, which is now down to 668 MB on nightly. There are too many PRs to mention them all, but particularly notable changes include [no longer distributing boundschecked stdlib images](https://github.com/JuliaLang/julia/pull/60054), and [removing full debug info from the runtime](https://github.com/JuliaLang/julia/pull/63641).

- LLVM [has been updated to v23](https://github.com/JuliaLang/julia/pull/63626), and support for any previous version [has been dropped](https://github.com/JuliaLang/julia/pull/63627). LLVM 23 is slightly (perhaps 5%) faster than previous versions, and this LLVM update is among the many changes that has led to the great latency reduction in Julia this month.

- Oscar Smith is attempting to [replace the trignometry functions’ implementations with new ones](https://github.com/JuliaLang/julia/pull/63544) that are both faster and more accurate. He is also attempting [the same for log functions](https://github.com/JuliaLang/julia/pull/63547). Neither PR is merged yet, so there may be unresolved performance or correctness issues.

- Miles Cranmer has been busy [modelling Julia source code in the proof assistant software Lean](https://github.com/MilesCranmer/julia-in-lean). It works like a kind of analytical property testing: For a method like `reverse(::OrdinalRange)`, properties like “the input has the same number of elements as the output” are written down as lemmas together with lemmas describing its implementation, and Lean then tries to either analytically prove that the property must be correct, or else it finds a counterexample. So far, this has led to uncovering more than 400 bugs in Base (about 100 manually verified so far), and many more in packages subjected to the analysis. Miles has written [a Discouse post on the subject](https://discourse.julialang.org/t/formalizing-julia-in-lean-and-finding-400-bugs-in-base/140243) which contains some interesting discussion. In the last few days, Miles’ AI agent has begun filing issues and PRs against Julia Base: So far, 108 issues, and 107 PRs. Now, human work is needed for reviewing these PRs to make sure the AI identified the problem correctly and found the right solution. Jameson particularly has been putting in bunch of reviews, but there is still much work to be done, and you can contribute by searching for [open PRs by “MilesCranmerBot”](https://github.com/JuliaLang/julia/pulls?q=is%3Apr+state%3Aopen+author%3AMilesCranmerBot), and taking stewardship of a PR.

- Julia provides green-thread concurrency through the Task type, which are under conflicting demands: One one hand, tasks must “just work”, and so interact with GC and the JIT compiler, allow per-task exception handling, fork the RNG, track cancellation and much more. On the other hand, since they’re, by design, the only concurrency primitive, tasks must be lightweight. The “lightweight” part has never really been achieved. [Polyester.jl](https://github.com/JuliaSIMD/Polyester.jl) provides cheap threads (get it?) by spawning a small set of `Task`s and reusing them. Tasks are designed to be single-use, so Polyester achieves this by reaching into Julia internals. This causes headaches: Several packages now _rely_ on Polyester’s speed, yet it breaks on every other Julia release. After [yet another breakage](https://github.com/trixi-framework/Trixi.jl/issues/3367). Valentin Churavy got fed up with this, and wrote [ThreadTeams.jl](https://github.com/vchuravy/ThreadTeams.jl), a new package that extends OhMyThreads.jl with Polyester-like cheap threads, except on more solid foundations. See also [the discussion on Slack](https://julialang.slack.com/archives/C67TK21LJ/p1791956272691609), where at least some Polyester’s users are looking forward to a more stable subsitute.

- Separately, Valentin and Gabriel Baraldi are working on making Tasks faster [[1](https://github.com/JuliaLang/julia/pull/63801), [2](https://github.com/JuliaLang/julia/pull/62284)], but their work has not beed merged yet.

- We’ve had `const` fields in mutable structs for years now (thanks, Jameson!), but remarkably, the compiler was never updated to infer `:consistent` or `:inaccessiblememory` for const field loads. Well, [Cody Tapscott fixed that](https://github.com/JuliaLang/julia/pull/63886).

- Julia can sometimes stack allocate `Memory`, but not very often, and there has long been interest in improving this. Tim Besard [refactored the Memory allocation intrinsic](https://github.com/JuliaLang/julia/pull/63672) such that the decision of whether to stack- or heap allocate happens later, which allows some LLVM optimizations to make it stack allocatable in situations it wouldn’t have otherwise. Tim also teased more work on this in the future.

- Tim Besard has been submitting a series of PRs to improve RISCV support to Julia: [[1](https://github.com/JuliaLang/julia/pull/64071), [2](https://github.com/JuliaLang/julia/pull/64069), [3](https://github.com/JuliaLang/julia/pull/64066), [4](https://github.com/JuliaLang/julia/pull/64072)]. He has also made a large number of compiler fixes this month (about 50) which may or may not apply to RISCV. Julia currently has tier 3 support (meaning: limitied support, things may not work correctly) for Linux on RISCV.

- One major limitation of trimmed binaries right now is that external libraries need to be bundled with the binary. That means you can’t just download an executable and run it - you must download a directory with the executable and a bunch of libraries. Also, the trimming process can’t see which libraries your program is using, so the bundle must include all libraries in your environment. This includes chonkers ones like BLAS, even if they’re not used. Gabriel Baraldi and Cody Tapscott has been working on improving the situation: [Gabriel’s PR](https://github.com/JuliaLang/julia/pull/63618) allows libjulia-internal to be statically linked. [Cody’s (unmerged) PR](https://github.com/JuliaLang/julia/pull/64469) allows the compiler to emit a JSON with every `ccall`’d library. [A WIP JuliaC PR](https://github.com/JuliaLang/JuliaC.jl/pull/182) can then statically link libjulia-internal, and to remove any library not in the JSON from the bundle. Maybe in a few Julia releases, Julia apps can trimmed to single, relocatable executables?

- Gabriel Baraldi and Kristoffer Carlsson has been working on optimizing the garbage collector, contributing [around 20 fixes and optimizations the last month](https://github.com/JuliaLang/julia/pulls?q=is%3Apr+%22gc%3A%22+in%3Atitle+created%3A2026-10-01..2026-10-31). I don’t have an overview of the overall impact of these contributions, as GC speed is not tracked on [perf.julialang.org](http://perf.julialang.org). Individual PRs showed great improvements in microbenchmarks, usually highlighting better behaviour in some pathological case. Shuhei Kadowaki also [opened a PR that allows threads to share partially free pages](https://github.com/JuliaLang/julia/pull/63512), which should help with heap fragmentation, reducing memory usage.

- `reinterpret` can be used to load values of type `T` from an `AbstractArray{S}`. When used on dense arrays (like `Vector`), it uses `unsafe_load(::Ptr{T})` internally. But the compiler has trouble tracking alias information through arbitrary pointer loads and stores: How does it know that you store into only the data part of the array and don’t use the pointer to mutate the normal fields of the array, like its length? Also, using pointers require a distinct `GC.@preserve` for every load/store, which may hinder autovectorization. These compiler details have shown up as `Base.ReinterpretArray` being surprisingly slow. Andy Dienes has been working on this for some time, and now he is proposing a new pair of builtins which allow storing/loading a T from a `MemoryRef{S}`. This builtin will have special compiler support like the existing `Core.memoryrefset!`, and could be used to make `reinterpret` of arrays faster, as demonstrated by Andy in [[1](https://github.com/JuliaLang/julia/pull/63576), [2](https://github.com/JuliaLang/julia/pull/63577), [3](https://github.com/JuliaLang/julia/pull/63578), [4](https://github.com/JuliaLang/julia/pull/63579)]

- Julia [now has functions `Base.Filesystem.trylockfile` and `Base.Filesystem.unlockfile`](https://github.com/JuliaLang/julia/pull/63613). The former tries to lock a file returning `true` if the lock could be taken, or `false` if it could not. This API allows files to be used as locks, which allows locks between distinct Julia processes. An example use case is a command-line program where only one instance may be running at a time.

- It [was discovered](https://github.com/JuliaLang/julia/issues/63769) that `pop!(::Set)` was accidentally linear instead of constant time. This was [fixed by Kristoffer Carlsson](https://github.com/JuliaLang/julia/pull/63821) by adding an extra field to `Dict`. It also spurred Oscar Smith to [attempt a PR with a new Dict implementation](https://github.com/JuliaLang/julia/pull/63809), which is more similar to Python’s. However, the `Dict` implementation is difficult to improve on because it must be fast across a wide array of usage patterns. It’s also used to often throughout Base and the stdlibs that an implementation with compiles to more code may increase latency broadly across Julia, so code size must remain small. Finally, there is a lot of prior art on hash map implementations, which means there are many candidate implementations that must be considered. Oscars PR remains unmerged.

- On x86 and ARM, floating point environment (“fpenv”, controlling rounding mode and which float operations cause hardware exceptions (“traps”)) is crontrolled directly by the CPU via values in special registers. The OS makes sure to track fpenv per thread. Unfortunately, that doesn’t work for Julia because Julia can schedule tasks on arbitrary threads and then migrate tasks between threads. That means, for example, a task may be spawned in one fpenv and then suddenly switch thread with another fpenv, causing float behaviour to spontaneously change from the point of view of the task. Even worse, user code may change the trap settings, and then execute code in the Julia runtime (e.g. the compiler), which may not handle these traps [and so crashes](https://github.com/JuliaLang/julia/issues/63570). Jameson has [pitched a PR](https://github.com/JuliaLang/julia/pull/63848) to make Julia’s runtime track fpenv per task, and to always disable trapping when running code in the Julia runtime, which should solve the issue. But there is some discussion in the PR: Perhaps having fpenv a dynamic global-ish property [is just fundamentally bad, broken design](https://github.com/JuliaLang/julia/pull/63848#issuecomment-6426027908), and the semantics [should instead happen on a per-function level](https://github.com/JuliaLang/julia/issues/51277#issuecomment-1716941223) (i.e. different functions, or args controlling behaviour)? Also, do we want to make `Task`s even heavier and more expensive to switch by having them track fpenv? Or maybe it’s best to have Jameson’s fix in Julia for now, and then discuss better fpenv design later?

- A series of PRs by Tim Besard [[1](https://github.com/JuliaLang/julia/pull/63162), [2](https://github.com/JuliaLang/julia/pull/63214), [3](https://github.com/JuliaLang/julia/pull/63179) and probably more] adds profile-guided optimized (PGO) Julia builds to MacOS and Windows. PGO Linux builds were already supported back in 2024 [thanks to Zentrik](https://github.com/JuliaLang/julia/pull/54107). PGO works by measuring a program’s execution during a real work load. These measurements can then inform the compiler how the program should be better optimized (e.g. which functions profit from inlining, how should code be layed out in the binary, etc). The program is then re-compiled with this information, which typically produces a more optimized binary. PGO builds for 1.14 are already available from juliaup using the `+opt` suffixes, e.g. `juliaup add alpha+opt`, and may be the default builds of Julia releases in the future. PGO builds has around 10% lower compile times, and so PGO is one of the larger contributions to latency reduction for Julia 1.14.

- The implementation of `===` for [UnionAll types](https://docs.julialang.org/en/v1/manual/types/#UnionAll-Types) is unsound due to `UnionAll`’s layout. `UnionAll` is an immutable struct containing a body and a mutable `TypeVar`, yet `===` unexpectedly [computed a notion of type equivalence instead of actual object identity](https://github.com/JuliaLang/julia/issues/53593). Not only could that lead to the contradictory result `ua1 === ua2 && ua1.var != ua2.var`; it also meant the compiler was free to swap/replace two `UnionAll` that actually had distinct layouts. Some months ago, Keno pitched [a PR trying to fix this](https://github.com/JuliaLang/julia/pull/63530) by restructuring `UnionAll` to a more sensible layout. Beside fixing compiler unsoundness, hopefully this will also lead to performance improvements. The PR is large, with ~9k AI-generated LOC, and with open questions of backward compatibility due to Julia’s introspection, and so is being split up to smaller pieces that can be reviewed more easily [[1](https://github.com/JuliaLang/julia/pull/63768), [2](https://github.com/JuliaLang/julia/pull/63932), [3](https://github.com/JuliaLang/julia/pull/63768)].

- Tim Besard has pitched [a prototype PR](https://github.com/JuliaLang/julia/pull/63828) for computed traits in Julia. The main issue it seek to solve is Julia’s monophyletic types: a fundamental problem in Julia’s type system which causes heaps of practical issues. Traits has been discussed for years, and one of the main problems has been conceiving of a trait system that works well alongside the existing type system. See also [Tim’s brief design document](https://github.com/JuliaLang/julia/blob/tb/trait-dispatch/doc/src/devdocs/trait-slots.md).

### Other community news

- [TensorMixedStates.jl 2.0](https://discourse.julialang.org/t/ann-tensormixedstates-jl-2-0-closed-and-open-quantum-systems-with-matrix-product-states/140266), a rewrite of the library, simulates closed and open quantum systems with matrix product states on top of ITensor, density matrices and Lindblad equations included.

- Christos Lillis has [published a game](https://discourse.julialang.org/t/rocket-plumber-a-rocket-engine-and-spaceship-building-game-im-making-with-julia/140135) developed in Julia called [rocket plumber](https://rocketplumbergame.com/).

- The talks from JuliaCon 2026 [are being released on YouTube](https://discourse.julialang.org/t/juliacon-global-2026-videos/139963) now. Four videos are being released every day. You can see them on the [JuliaLang YouTube account page](https://www.youtube.com/@TheJuliaLanguage/videos).

- Caroll Vance has written [an excellent blog post](https://csvance.dev/posts/2026-10-22-reactant-end-to-end/) decribing how we replaced PyTorch with a Julia stack with Reactant and Enzyme. There is some [discussion on Discourse](https://discourse.julialang.org/t/blog-replacing-pytorch-with-julia-and-reactant-one-year-in/140158), but the blog is well worth reading in its full.

---

<div class="post-metadata">

**Author:** ![moble](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/moble/32/23535_2.png) [@moble](https://discourse.julialang.org/u/moble)\
**Post date:** [November 1, 2026, 2:50pm UTC](https://discourse.julialang.org/t/this-month-in-julia-world-2026-10/141631/2 "2026-11-01T14:50:27Z")

</div>

Congrats on the baby! Thanks for all the good work you’ve put in on the newsletter.

---

<div class="post-metadata">

**Author:** ![sylvaticus](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaticus/32/203883_2.png) [@sylvaticus](https://discourse.julialang.org/u/sylvaticus)\
**Post date:** [November 1, 2026, 4:04pm UTC](https://discourse.julialang.org/t/this-month-in-julia-world-2026-10/141631/3 "2026-11-01T16:04:12Z")

</div>

Now the question is how the AI effect, that for Julia seems to be huge (memory, size, bugs..), compare with other languages used for data analysis like Python or R..

---

<div class="post-metadata">

**Author:** ![rafael.guerra](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rafael.guerra/32/216610_2.png) [@rafael.guerra](https://discourse.julialang.org/u/rafael.guerra)\
**Post date:** [November 1, 2026, 4:20pm UTC](https://discourse.julialang.org/t/this-month-in-julia-world-2026-10/141631/4 "2026-11-01T16:20:28Z")

</div>

Kristoffer Carlsson’s slimming of Julia, from 1,250 MB down to 668 MB, puts Ozempic to shame.