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
• @StefanKarpinski
• @IanButterworth
• @tecosaur
• @mbauman
• @jishnub
• @stevengj
• @oscardssmith
• @d-netto
• @LilithHafner
• @maleadt
• @vchuravy
• @giordano
• @DilumAluthge
• @eschnett
• @NHDaly
• @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 (Add support for intrinsics for NTuple{VecElement} julia#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 It is too hard to reason about when Julia specializes arguments julia#51423 progress. this might involve starting with ideas like Broadcast calls on functions passed as args don't force specialization julia#32956 or specialize on exact Vararg number for all calls that are not via _apply? julia#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: WIP / RFC: Define IO reading interface julia#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 #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.