So @bvdmitri, I’m hearing two things from you here:
You’d like to know a little bit about what folks are working on for future Julia releases. Fair!
You have some currently un-met requirement around AOT compilation that you’d like to know if it’ll be implemented at some point. Also fair!
On the first point, I think it’d be very cool to do a survey of core devs and ask what their goals might be for the Julia language in 2026. That’s very fitting for an end-of-year blog. The only way the retrospective release blog posts happen is because Kristoffer and a few others run around harping on devs to describe some of the cool work they’ve done. I imagine folks might — if given the impetus and location — help contribute to such a blog post that briefly describes some high-level goals or features or even just sketchy work-efforts. Those could point towards working groups or calls or wip PRs or prototype packages or the like.
But I don’t think that’ll satisfy you (or more importantly your manager) for the second point. I don’t know what your requirements are here.
That’s a bit confusing to me. From what I understand, the ability to compile code is one of the key features of Julia — it’s central to addressing the “two-language problem.” The idea is that you can both write code easily and ship it easily. If either of these aspects doesn’t work, we end up needing two languages again, which seems contrary to Julia’s stated vision.
PackageCompiler is even highlighted on the main Julia website as one of the core tools enabling this workflow.
So releasing a new version where compilation is broken feels problematic. It gives the impression of a lack of alignment on what’s essential to Julia’s vision. Can Julia really be released with PackageCompiler in a broken state? Who makes that decision, and where can we read the rationale behind it?
Or maybe juliac is now the primary way to compile? No. Its not replacing at the moment. So again, whats the vision? Maybe someone can explain it here - but the main problem is the lack of centralized place explaining such things.
Julia compiles the code always, that is a different thing, which is creating static binaries. Most Julia software is deployed as Julia packages and do not use static compilation. Even if that is a desirable feature, it is a niche feature which must not block the development of the language, and PackageCompiler.jl is one package providing that. (which, by the way, I never used and guess that the vast majority of julia users and developers never used, it is not an essential part of the language, at all). There are other very important packages in the ecosystem that have to follow the Julia language release to not be broken because they depend on the language internals, and not always these packages manage to catchup in time to work with the release candidates before the release.
Shipping of a pre-compiled binary blob generated from julia code that is then run on another machine has not really been a core julia idea (since with Julia you always have a compiler available).
However, there are different venues in progress for it:
JuliaC for creating programs that will only need the julia runtime but not its compiler
PackageCompiler that can bundle things in a sysimage but ships the full julia runtime and compiler to support JIT.
Discussions about distributing package images to avoid local package precompilation
The “core” experience of Julia is however julia itself and its packages that you add and work with locally (together with Project + Manifests for reproducing your environment on other machines).
Traditionally, the two uses referred to in Julia discussions of the two-language problem are prototyping and performance, not writing and shipping (any code must be written in the language it is shipped in at some point).
I seldom hear people complaining that Python code is too difficult to ship. Julia is no harder (my understanding is that its package management is significantly better than Python’s, in fact). The main thing that makes Julia harder in practice is that Python is probably already installed on the target system and Julia is not.
you’re, of course, free to speculate and appeal to your personal experience but it’s worth noting that compilation into binaries is the second biggest pain points of the entire community (see slide 8). And PackageCompiler is the only semi-reliable way to do so
You have you personal opinion. You think it’s not essential. I have mine. I think it is essential (and I backed it up with the Julia’s developer survey - it supports my understanding of things I believe).
But the discussion is shifting towards a very specific thing. I also want to re-iterate once again that my intention here isn’t to debate compilation details. Yes I mentioned compilation specifically, it is important to me personally, but it would also be fine for me to see that this is not a priority for example. But where I can see that or read that? The broader point I’m trying to make is that it is extremely hard to deduct what is priority and what is not. No vision. No roadmap. Call it anyhow you prefer. How should I deduct that something like PackageCompiler is not a priority when its literally listed on the website? Everything what is on the website must be important, right? No? Why? Where to know what is a priority longterm then? Does the Julia developer survey not make it a priority?
I hope though that there’s general agreement that it would be very helpful to have a central, accessible source outlining Julia’s long-term priorities and direction. It would make the ecosystem easier to navigate and give both new and experienced users a clearer sense of where the language is going.
I can provide some anecdotal evidence. I used to work for a start up with a small team of data scientists (<5). While Julia is my go-to language for basically everything, the team always preferred Python even though all of them knew about Julia and its benefits. The reasoning was exactly what the OP mentioned – that the manager was unable to see the viability of Julia as a long term project (and we are talking about a few years ago) and maintenance of the code. For projects in which I was the sole developer, I actually did end up using Julia to showcase the language to the company. But for anything that was more team-based or required collaboration with other units in the company, it was Python.
But I think this is natural. The expectation that there be a governing body, with a 2,5,10 year roadmap, proposals etc right away is not reasonable (well not unless there is Big Money backing it). I do think we are getting there though. The State of Julia talks, the monthly newsletter, the blog posts (the Memory one was great) are all indicative of a larger roadmap – though I do agree with you @bvdmitri that it’s scattered.
In my head, it feels like the Julia core devs have to get some “big ticket” itemsout of the way (such as static compilation, threading, etc) after which a “roadmap” might be easier to officially propose and maintain. Perhaps 2026 is the year for that.
It would be great if next month there was a blog post about the core developers’ goals for 2026. Besides increasing communication between the core developers and the Julia community, it could also boost donations.
In addition to the blog post with next year’s goals, it would also be great to have posts with updates (every three or six months), indicating whether there has been any progress or not. If it is reported that some projects are stalled due to a lack of funding or developers to continue them, there may be someone willing to offer help (financial or technical) to get the project moving forward.
I believe the Julia-lang blog could communicate better what is happening in the Julia ecosystem in general, and in Julia development in particular. The blog could give greater recognition to those who work to improve Julia ecosystem.
I think an undervalued aspect of having plans centralized and in the open is that a conversation starts to happen around them and it can gain much more momentum. Gaps and neglected aspects can be identified. Also it could be a big magnet for talented people looking for great projects to work on, people that work on languages for their own sake, not just as a tool to get their main job done.
I support this! Would be great! Perhaps newsletter from @Krastanov is also a good place to raise awareness of such posts (cross-linking to the Julia-lang blog?)
FWIW I’m among the people that voted for that, and I would certainly find useful and fantastic to have that feature. It would bring Julia to a whole different level of utility. But that doesn’t make it a core part of it.
JuliaC is advertised as “experimental”. It’s not even described as an alpha release that would imply eventual beta and stable releases. It’s something that only has a future if the “experiment” succeeds, if I interpret the language literally. That’s probably how much you can realistically expect when planning for the future.
I personally resonate with the point raised. It is not only hard to be aware new features/improvements of Julia but it lacks the official/formal resource to learn and thus adapt the new features.
For example, I am quite confused the workspace feature announced with Julia 1.12. It seems quite promising and useful but I cannot find a concrete location to learn it. I also see a bunch of posts querying what is the workspace and how to use it.
With a clear planning doc for such major (and very good) feature addition, I see it is not only helpful for industry entities to make decision but also benefits normal/private users.
I’ll just offer that, as a relative newcomer, it took me a long time to figure this out. The constant messaging about “static compilation is coming!” because it is a “community priority” really blurred the point that:
Knowing this then allows you to see why this is the case and where this feature really is headed:
That’s the kind of clarity a roadmap really needs to provide. While I’d love a “what core developers are planning to contribute” blog post, the footnotes on what we’re not doing and what it never will be would be helpful to newcomers. To the OP’s point, while I kinda figured all of this out after some immersion with the language and community, this is the first thread I’ve encountered where these things are explicitly stated. Any roadmap that talks about, for example, static compilation, probably ought to be just as clear that we’re probably never talking about the same thing you do in C, and whatever it ends up being, it probably means some combination of a constrained version of the language and a pretty large runtime deployment.
We somehow never agreed on what a roadmap really is, and people’s expectations for it have varied incredibly widely from developer-user communication to deciding whether to use the language in the first place. PEP was brought up as an example, and I’ll give my 2 cents on what it is and isn’t. It’s a very good place to see the big plans and there’s a very nice index of their approval status with associated Python versions. It’s not announcing 2, 5, etc-year plans, nor does it detail implementation progress. If we look at the accepted and open PEPs, some don’t have associated versions, a few outlived their associated minor version, and none of them offer deadlines. It could be because strict deadlines for unsolved problems are basically empty promises. I think several commenters were spot-on about using a tool when it’s ready to be used, not demanding predictions for production. I wouldn’t risk a job on a prediction even if reasonably argued by a developer or if a big corporation funded a big full-time team to implement all the features we want (I wish).
I also broadly agree with the idea that core developers could communicate goals and WIPs in a better way than a small fraction of archived JuliaCon talks, the rare blogposts, or a couple experimental points in release highlights. Discourse, Github, or a chatbot to regurgitate their discussions were never where core developers announced their intentions to the public, so I’m not surprised those didn’t give answers either. It’s worth pointing out that the core language and developer communications are not actually why people use languages. Most practical libraries are not on any language’s core developers’ radar, so focusing entirely on core Julia development isn’t going to help people decide if Julia is useful. Going back to Python for example, even high-performance Python users are looking at independently developed and funded projects, not CPython’s experimental and comparatively limited JIT.
You’d have to watch a JuliaCon talk to learn a couple developer’s perspectives, but the short answer to those first 2 questions is yes. It doesn’t appear to be a solid fundamental feature because it’s not. Julia was designed for JIT compilation in interactive workflows, and caching compiled code at all has been a complicated and ongoing work in progress.
Shipping a binary started with a largely independent project PackageCompiler shortly before Julia’s v1 release, and it’s not used often because it bundles the relatively massive Julia runtime and all loaded packages. It’s not even how caching compiled code works for interactive workflows. JuliaC, an experimental and very incomplete feature released just last month, aims to trim a binary and still support a large part of the language. However, there will be additional limitations no matter how much it improves; for example, removing the JIT compiler means we can’t use the archetypically dynamic eval at runtime.
I would contest the comments that JuliaC is not a core feature by this point because core developers are obviously prioritizing its development, but they probably meant that shipping AOT-compiled binaries was never part of Julia’s initial pitch or releases. It was also never part of any official description of the two-language problem, and the two-language problem does not imply or assert that we shouldn’t ever use two (or more) languages. If you read otherwise, then you were severely misinformed; anybody can write or generate a blogpost. Exaggerating the context of the two-language problem is so common, it topped my personal misconception list.
Broadly speaking, there is always work on improving compilation and performance. Nobody can centralize all the ideas and work on such a broad topic even if there’s a Github issue naming it. Currently that issue just has a disagreement about whether to keep the issue open as a searchable indicator or to close it for not being tied to a specific release (worth pointing out there are plenty of open long-term issues without an associated release). In any case, improvements will far likely be incrementally implemented in countless scattered pull requests, which you really don’t need or want to read, and that issue might only provide updated benchmarks if kept open. A benchmark with contributions from the wider ecosystem would probably be more informative than Documenter alone.
