Getting a goals list

[ChrisRackauckas]

Roadmaps are hard and take work. The goal here is to distribute the work a bit. The plan is:

1. Get a list of statements from each of the core maintainers as to what their roadmap plan is
2. Use that information to make a first draft of a roadmap
3. Open a PR so that people can make final edits and changes
4. Have it on the website so then it can be updated yearly / every few years.

Steps 3 and 4 are not as much work, so I believe the issue is just the inertia of getting there. I can help get there, but I'll need the following information.

From each of the core maintainers for Julialang and the standard library, can you share your:

• one year plans (short term goals)
• 3 year plan (medium term plans)
• 5 year plan (speculative long term ideas)

This can be a simple one line sentence, or it can be a whole paragraph story. Mostly this is to get a list of all things that need to enter the final story.

I got "unofficial" permission from @mbauman to ping everyone, so hopefully this isn't bad. Here goes nothing:

• [ ] @JeffBezanson
• [ ] @vtjnash
• [ ] @Keno
• [ ] @gbaraldi
• [ ] @topolarity
• [ ] @yuyichao
• [ ] @aviatesk
• [ ] @c42f
• [ ] @KristofferC
• [x] @StefanKarpinski
• [ ] @IanButterworth
• [x] @tecosaur
• [ ] @mbauman
• [ ] @jishnub
• [ ] @stevengj
• [x] @oscardssmith
• [ ] @d-netto
• [ ] @LilithHafner
• [ ] @maleadt
• [ ] @vchuravy
• [ ] @giordano
• [ ] @DilumAluthge
• [ ] @eschnett
• [ ] @NHDaly
• [x] @jakobnissen

And please anyone I missed that should be considered in this list of "people likely to make major contributions in the near future".

Attempting to start addressing https://discourse.julialang.org/t/where-is-julia-heading-lack-of-clarity-about-priorities-long-term-direction-and-governance/133734.

[KristofferC]

Can we not have this in the julia repo? This repo should be to track things about the code. https://github.com/JuliaLang/Juleps maybe or a new repo.

[ViralBShah]

Let's move the issue to juleps.

[KristofferC]

Moved

[tecosaur]

• Short-term goals:
  • Improve the REPL history and stacktrace experiences, through interactive UIs
  • Introduce terminal colour detection/blending/theming
  • Value-parameterise AnnotatedString
  • Add namespaces to StyledStrings
• Medium-term goals:
  • Make a path type proposal good enough to be seriously considered
  • General polish to StyledStrings
  • Use JuliaLowering and StyledStrings to revamp error display, with heavy inspiration from Error Messages Are Classifiers
• Long-term goals:
  • Supplant REPL.TerminalMenus with a multi-modal approach to dialogues
  • In-REPL documentation browsing

[oscardssmith]

• Medium term goals
  • Investigate the CoreMath https://core-math.gitlabpages.inria.fr/ function implementations to look for speedups in our elementary functions.
  • Improve Julia level escape analysis (primarily making it work for Memory)
  • Improve LLVM level escape analysis for Memory (support for large and non Const size Memory)
• Long term goals
  • Vectorized intrinsics (https://github.com/JuliaLang/julia/pull/55118)

[adienes]

don't mean to intrude myself into the curated list of folks above, but just to share what I'm interested spending my volunteer time on over the near future:

short term:

• continue auditing / bugfixing integer math functions in Base that are susceptible to internal overflow
• continue being a human StaleBot by clicking sort:updated-asc and then clicking close 😄

long term:

• help https://github.com/JuliaLang/julia/issues/51423 progress. this might involve starting with ideas like https://github.com/JuliaLang/julia/issues/32956 or https://github.com/JuliaLang/julia/issues/53751
• create on-ramps to help users experiment with a global max_methods=0 world by a potential runtime flag --world-splitting=no, distribution via juliaup, etc.

[ChrisRackauckas]

Oh no thanks for adding, I thought I had you in the list!

[jakobnissen]

I would like to work on overhauling (non-breaking, obviously) the IO interface:

• WIP proposal: hackmd.io/UgeBwtIkTTipkgZSQnXc8w
• Very WIP implementation in Base: https://github.com/JuliaLang/julia/pull/57982
• (Breaking) Implementation in a package to show the vision: https://github.com/BioJulia/BufferIO.jl

Whether this is likely to happen, and therefore deserve a spot in the roadmap depends on two factors:

1. Whether I can get buy-in / design involvement from someone with commit rights such that the design can get approved and PRs actually gets merged/rejected and does not bogged down in a 6 month indecisive deadwater per PR.
2. My job situation in the near future, which I will know more about in a few weeks.

This is just to flag it as an idea of mine. I'll attempt move on it in December or early in the new year.

[bvdmitri]

Thanks, @ChrisRackauckas, for opening the issue based on the discussion on Discourse! I’m genuinely curious to see the big picture of what everyone is working on. I think it’s fair to give people a week or two — some might be on vacation or just busy. After that, we can compile a “Plans for 2026” blog post and share it through the Julia newsletter.

I also think it’s important to emphasize that this isn’t about making promises or guaranteeing that someone will be able to execute their ideas. Everyone understands that personal circumstances, work commitments, or other factors can affect what’s possible, especially in a volunteer-driven project. The goal is simply to get a clear picture of what’s currently on the table and what the general direction looks like — even if that direction evolves over time.

Looking a bit further ahead, after the "Plans 2026" blogpost, would it make sense to start with something very simple, similar to Rust’s RFCs? It could be a minimal website with a sidebar — each RFC links to related issues, PRs, and discussions (for example, on Discourse). The goal would be to have a single source of truth. We could easily use Documenter.jl for this purpose and this repository, where each RFC is a Markdown page. Right now, people often use HackMD for similar ideas. Documenter would automatically generate a simple website with a sidebar where each item represents a proposal, and the Markdown could include links to relevant discussions.

As for adding new RFCs and managing them, perhaps we could adopt a model similar to package registration. For instance, when someone adds a new RFC, it could have a short cooldown period (three days as with package registration) during which others can flag or block it before it appears on the main website — mainly to filter out spam or inappropriate content. Once an RFC is published, the original author could update it freely, while edits from others would again go through a short cooldown (again three days) for review.

This approach would make the system mostly self-regulating, minimizing the need for manual moderation. And, similar to package registration, a small trusted group could still have merge rights to step in when necessary.

What do you think about this approach?

[StefanKarpinski]

When I get the bandwidth and motivation to do any of these (in no particular order):

• Finish Resolver.jl and finish integrating it into Pkg. The main hold up here is figuring out how to give better error messages when something is unresolvable.
• I have a clever idea for estimating unique Pkg client counts with provable anonymity that uses HyperLogLog over RSA rings. When I manage to write that up I want to get feedback on it and if people are into it, we could implement it in Pkg clients and then start getting accurate client count estimates for Pkg servers.
• Investigate replacing libcurl in Downloads with aws-c-http. Using libcurl has been a pretty big disappointment: (1) still not threadsafe despite endless attempts to make it so; (2) abysmal performance. Just punting all the download work to aws-c-http and letting it manage its own thread pool seems potentially better on both fronts.
• Finish implementing correct floating-point ranges. High-level algorithm is designed, efficient implementation is the next step, then surgically putting it into Base.
• Work with @staticfloat on finishing and deploying more efficient package/artifact downloads in Pkg via content-chunked compression a la casync. This replaces an older idea of serving diffs wrt to specific older versions.
• Redo our pkg server log system. We use Snowflake. It's expensive and not really what we need. I want something that people can actively run queries against and get answers immediately instead of generating a bunch of reports that no one actually cares about.
• Big rewrite of Pkg. This is pie in the sky and maybe a bad idea, but I really want to completely rewrite the Pkg code base.

[JeffBezanson]

See https://github.com/JuliaLang/Juleps/issues/59

[brainandforce]

Also not one of the people mentioned in the list, but I talked with others mentioned here at JuliaCon 2025 about the implementation of NTuple - currently something like NTuple{8, Float64} expands to Tuple{Float64, Float64, Float64, Float64, Float64, Float64, Float64, Float64} and it's needlessly hard on the compiler (from what I understand, it's doing a ton of unnecessary type checking). Considering how many parts of the Julia ecosystem are built on StaticArrays, which itself is built on NTuple and can be the source of long (pre)compilation times, any improvements here would have a huge positive impact.

Perhaps this also overlaps/is subsumed by @oscardssmith's mention of vectorization intrinsics - I'm not an expert on where this would fit into the greater roadmap.

[mbauman]

I like to use the language of goals rather than roadmaps. Small nit, but I think it's important, especially as this can easily lead towards increased negative burdens on the efforts. Rust has had lots of public discussions around their goal-setting initiatives — it'd be great to look towards those (e.g., https://smallcultfollowing.com/babysteps/blog/2023/11/28/project-goals/).

Personally, my primary short term goal isn't language-oriented, but rather an ecosystem wide shoring up of dependencies and securities. It'll does have direct impacts on Julia itself, though.

My aspirational goal is to complete the pairwise reduction refactor.

[oscardssmith]

Perhaps this also overlaps/is subsumed by @oscardssmith's mention of vectorization intrinsics - I'm not an expert on where this would fit into the greater roadmap.

This is totally unrelated. The vectorized intrinsics PR is just about letting intrinsics like add_float work on types like NTuple{8, VecElement{Float64}} rather than Float64 and friends that it works on now. This doesn't require any changes to how we represent the NTuple. As such, my PR would help the runtime and simplify the code necessary to express SIMD patterns, but wouldn't do anything to make inference of them more efficient.

[andyferris]

Considering how many parts of the Julia ecosystem are built on StaticArrays

Also not one of the people on the list, but I thought I might note there are various different improvements/additions to Julia that could make StaticArrays simpler to implement and potentially easier on the compiler. Off the top of my head, here are a few directions that would help:

1. structs and mutable structs with Varargs fields (or similar) massively improves the usefulness of mutable static arrays, and simplifies all static arrays
2. Memory escape analysis that understands sizing and can bring it to the stack - means we can use standard for loops to accumulate results instead of generated functions everywhere.
3. Mutable tuples (invariant in type parameters, supporting Varargs) is an alternative that can get a lot of the benefits of 1 and 2.
4. Versions of Memory that are sized (by a type parameter?) - mutable and immutable flavours - is another alternative (with the most benefits).

Any one of these would be enough to trigger a rewrite (or partial rewrite) of StaticArrays. Some (like the last) would ultimately be powerful enough to delete StaticArrays altogether in favour of what comes out-of-the-box in Julia (or at least remove the need for generated functions and Varargs/NTuple from the package).

the implementation of NTuple - currently something like NTuple{8, Float64} expands to Tuple{Float64, Float64, Float64, Float64, Float64, Float64, Float64, Float64} and it's needlessly hard on the compiler

Personally, I'd wonder if # 4 is both simpler and better than fiddling with tuples / varargs / ntuple. C, Rust, Zig and many other languages have this datatype built in. Swift recently added InlineArray for exactly this purpose. They all tend to use a type parameter for the size, and another for the type (and arguably these are C's only type parameters). (I'd love to be able to dig into Julia internals and work on this myself - but sadly I've struggled to find the time!).

[giordano]

About 4, at JuliaCon @RomeoV showed interested in building a statically sized array on top of FixedSizeArrays.jl.

[eschnett]

One-year plan:

• Use new standard MPI ABI to simplify using Julia with MPI on HPC systems (MPI would be as simple as CUDA)

Three-year plan: Make Julia run well on distributed HPC systems, including

• Startup (precompiling etc.)
• Memory management (run kernels without GC, synchronize GCs across nodes)
• Code generation for large kernels with many variables

Five-year plan:

• Make type-generic code in large applications less brittle (could be changes to core language, or Holy traits, or a battery of tests, whatever it takes)

[bvdmitri]

Thanks to people who added their thoughts already! Pinging this thread just as a reminder for more people to share their plans so we can get a better picture :)

[bvdmitri]

I will poke people in this thread once again, just in case. There is some material for where Julia is heading, though only few people from the list have replied...

[ViralBShah]

This only pings people who have already responded - and not others who have not seen this.

[ParadaCarleton]

The key thing I'd like to see discussed in this issue/thread is a promise to implement interfaces. This has been a major pain point for about a decade now and I know many Julia devs who'd be willing to work on it if the devs pledged to accept it (there's at least 4 package implementations). The lack of interfaces is one of the big issues that keeps me from using Julia for work.

[c42f]

I love that @mbauman mentioned goals over roadmaps. I've got so many things I'd be curious to work on but having dedicated time to do that is unpredictable. I'd broadly split my work up into (1) the compiler frontend and (2) random projects I'm curious about.

The compiler frontend / related projects

I'm currently working on integrating JuliaLowering into the Julia compiler as the default lowering implementation. This is the only project I currently have time(/money) allocated for, so we should be able to get this one done.

An obvious continuation of that project would be to bring JuliaLowering's new macro system to users while keeping old macros working. There's also some other bits of frontend maintenance work like bringing https://github.com/JuliaLang/JuliaSyntax.jl/pull/524 to reality.

Other extensions of this work would be to push precise code provenance outward into the ecosystem and compiler in various directions. For example:

• Getting precise provenance into inference, through codegen and down into DWARF debug info
• Building infrastructure so that Revise can become a stdlib
• Relatedly, a fast debugger (mostly this would be working on a fast interpreter)

A lot of these are big projects and I don't know what I'll be able to work on and what other people plan to take up.

Random projects

I've been specific above, but I'm personally interested in a certain flavor of project more than having big long term plans. I'll just give one example of a random project I find particularly intriguing: A quality implementation of sum types is a full tour from semantic design through to implementing syntax, lowering, codegen, runtime and GC changes.