I don’t think this is really related to funding, to be honest. If someone has the time and resources to implement a change in the language (for example, by submitting a PR with an improvement), then they certainly have the time and resources to first write up a proposal outlining their idea. Writing a proposal is significantly cheaper and far less time-consuming than actually implementing the change.
Hi @bvdmitri , thanks for bringing this up.
The best source I know to get an overview where Julia is heading is through @Krastanov 's monthly newsletter. A big thanks for compiling this, it’s awesome. And the same for the turing team’s newsletter.
But I whole-heartedly agree that a central roadmap for language development would be helpful in many ways. For one, it would guide developer effort along areas that the community deems high priority and that there is demand for. Second, planing security would also drive language adoption in the corporate world.
I’m a bit bummed at the moment to basically see JAX and pytorch/triton eat julia’s lunch. (Very personal opinion). Maybe the situation would be different with more corporate support and Julia core staff at bigger companies.
To @mikmoore and @mihalybaci s point - I think that having a clear roadmap for language development can may turn this situation around. Let’s say I want to use Julia for a certain project and Julia supports the basic features for the minimum requirements. Now after some project revisions, target shifts. And suddenly Julia doesn’t have the tooling. If there was a roadmap where tooling or development in adjacent areas of the original project scope were on the roadmap, I would have an easier time de-resking that project.
To be concrete, I can do simple ML projects in Julia. They work fine. But many advanced features, like model deployment, centralized logging are only supported through the work of motivated individuals. For example, MPC support, MLflow, ONNX etc. A feature roadmap may help as a catalyst for focusing efforts into key areas where there is community agreement that the language should develop in.
Another point is static compilation. I can play around with it, and probably find some cool use for it. But it’s not production ready. Should I keep working with it, waiting for the situation get better? Or will it be abandoned? Without a roadmap for this feature, I’d probably just don’t touch it and move on to another language.
4 Likes
Maybe a clear community roadmap would help to get such funding?
6 Likes
Proposals make me think Juleps, which I refer to as something I think we should do more of. My comment about funding was largely in regard to roadmaps, because funding is a big deal for being confident you’ll actually be able to set aside enough time to work on something without life getting in the way.*
*See: all of my in-progress work.
I think it is very much related to funding. People have jobs, studies, and a life which gets in the way of writing your proposal, submitting that PR, or developing that idea for improving the language. On the other hand, if you have funding, this becomes someone’s job and it will get done.
3 Likes
You touched on the exact pain point that might have started this entire discussion 
That’s precisely the kind of problem I’m facing right now — compilation is painful, and deployment is even more so.
One day I see something new called juliac. Naturally, I get curious and start digging in — I watch videos, read forum threads and pull requests, even experiment with it myself using its unstable API. But after all that, I still can’t find a clear explanation, direction, or instructions on how to actually use it (despite it being prominently mentioned in the Julia changelog). So, I finally have to ask: what’s the plan?
Apparently, juliac isn’t meant to replace PackageCompiler and isn’t an improvement at this stage — that’s fine and clear. But then I read this discussion, and see that PackageCompiler itself isn’t a core component and might or might not be maintained consistently.
So again, there seems to be a lack of cohesive vision — and that raises so many questions:
• How should Julia projects be compiled today — with PackageCompiler or juliac?
• Will one eventually replace the other?
• Should developers start migrating, or stay put?
• What’s the long-term plan? Why does Julia need two separate tools for binary compilation?
I tried searching through issues and discussions to find these answers, but they’re scattered or missing altogether. It feels like all of this could be clarified through a centralized proposal for juliac — one that lays out the motivation, roadmap, and relationship with existing tools.
4 Likes
Then perhaps Julia might not be right tool for you at this moment and you use something else and just come back to Julia to check progress occasionally?
There is also a danger in a roadmap as well, especially for a mostly volunteer organization that can have small bus factors. Let’s say the core developers lay out a roadmap that predicts a working juliac by Dec 2026, so you start using Julia on that information. Then one of the developers leaves for a new job and can no longer work on juliac, and the project gets delayed indefinitely until someone else develops enough expertise to finish the job. Now it’s mid-2027, and a polished juliac is nowhere in sight. How are you feeling about Julia’s roadmap?
Which goes back to my point, it would not be wise to choose a language based on what it could be rather than what it is.
3 Likes
Since Rust is a programming language without a BDFL or a company driving its development, it is a good comparison with Julia. Rust developers write blog posts about what they do very often.
- Blog post about the work done on the package manager
This Development-cycle in Cargo: 1.90 | Inside Rust Blog - Blog post about priorities for the next 6 months
Project goals for 2025H2 | Rust Blog - Blog post about adding new core developers
Announcing seven new members of the compiler team | Inside Rust Blog
I hope that the Julia core developers will write more blog posts explaining what they are doing.
6 Likes
It’s not about me. It’s about the hundreds of thousands of developers who face the same questions and don’t find the answers. Julia is losing many of those developers — they move on to other tools because the information they need isn’t easily available.
In my case, “trying something else and coming back later” isn’t really an option — I already have a running Julia-based stack that requires ongoing maintenance.
I don’t think that’s a strong argument against having a roadmap. Plans can (and should) evolve — there’s nothing wrong with adjusting them as circumstances change. The COVID pandemic, for instance, disrupted everyone’s plans, yet organizations still planned, adapted, and moved forward.
Also, if we are referring to wiki, what you’re suggesting is that its okay not to have a plan due to some small probability event. That is a bad argument.
Then one of the developers leaves for a new job and can no longer work
Again you’re making stuff up, is that happened? What if that doesn’t happen?
Every organization, volunteer-based or not, faces similar challenges, and that hasn’t stopped others from publishing or maintaining roadmaps. I believe the Julia community and core team do have plans and ideas — my suggestion is simply to make them more visible and centralized. Other communities have found effective ways to do this; I see no reason Julia couldn’t do the same.
6 Likes
That’s not how I would interpret that quote at all. It’s making the narrower claim that the release schedules of PackageCompiler and the Julia language are not going to be intertwined. This has more to do with making sure that Julia has a consistent release schedule and isn’t blocked by PackageCompiler, for the time being.
To add to what others are saying, looking at actual progress is probably a better indicator of where things are heading than formal roadmaps. This year’s Juliacon had lots of exciting developments about static compilation and tooling, and the presentations outlined future plans that seemed promising. Seems like good enough to go off of, even if its not a blog post.
Does Julia suit your needs now? If not, don’t use it.
3 Likes
That statement is not supported by many real world examples (Python, C++, Rust, etc). Are we seriously suggesting having no plan is better than having a plan?
6 Likes
If it is some medium-sized feature, you can open an issue, publish your proposal here on discourse, try to find somebody who would implement it, or start it yourself.
If it is something needing man-years of work - then it’s about the money, alas.
All the languages you listed - C++, Python, JavaScript, Rust, Go, Swift - have much larger developer and user base, and/or are projects started and supported by large corporations.
But what about the languages which are in comparable situation with Julia? How do they coordinate their development?
P.S.
Yes, just make a plan,
try to be a big shot!
And then make a second plan,
neither one will work.
(B. Brecht)
1 Like
(deleted by author)
As a positive example how a roadmap and regular information can help developers, take a look at the TuringLang newsletter:
Julia 1.12
With the release of 1.12 comes some very nice things and some broken things. Particle samplers (SMC and PG) currently do not work on 1.12, and Enzyme and Mooncake will both not run. Fixes are being worked on, but it may well take until 1.12.1 before everything is in order. If you use any of the above three, you may want to stay with 1.11 for now.
Regular updates on what is being worked on, issues on the developers minds etc, makes me much more confident to work with this package. It also creates a pull and language adaption.
Just seeing being written out that Mooncake and Enzyme are being worked on motivates me to work with these packages more. I need to understand how I should prioritize my efforts. And this sentence tells me exactly that.
On a larger scale, a language roadmap could have the same effect: Guide people in their time allocation to make a better Julia next year and the years ahead.
But realistically, if some people feel the need to explore how a Julia Roadmap would work - how best to approach this?
7 Likes
Are we seriously suggesting having no plan is better than having a plan?
I’m not suggesting that at all. So far this discussion has been pretty descriptive, not prescriptive, about the difficulties with creating a unified Julia roadmap. Reading this thread, it seems like you have gotten a number of answers along the same lines.
A unified is not the same as centralized or organized. What I’m suggesting is that it would be great to have a centralized place for planning, long-term direction, visions — something like Python’s PEP process.
The challenges Julia is facing are not unique. Even Zig is doing roadmaps where the bus factors is like one and the funding is also very limited. Many other communities learned how to communicate long term plans and their vision efficiently. Or at least they are trying to do so. It is also very beneficial for the community to have this clear vision.
I still don’t see a strong reason why the Julia community couldn’t adopt similar practices — perhaps adapting the best parts from others and doing it even better.
7 Likes
Look at this from @tecosaur. Isn’t this great? Wouldn’t it be even more great to have a centralized place for such proposals? Very very nice. I wish Julia had more of this in some kind of central place.
4 Likes
I 100% agree, and I never said or suggested that there shouldn’t be a roadmap. A roadmap could be interesting. I am simply saying that the presence/absence of a roadmap should not be a determining factor when picking a language. Then I threw in the “bus factor” argument to point to the fact the team of core devs is smaller than Python, so getting any sort of “here’s what’s next” is not so simple.
I have been on this forum for 8 years, and no one has ever suggested before that the “lack of a roadmap” made them dump the language, so this is a pretty wild exaggeration.
For what it’s worth, I also looked at the Python PEP page that you pointed to and it’s not a roadmap either. It’s a list of feature requests that may or may not happen. It isn’t that different than looking at the Julia github page for new features. But I don’t see anything about, “here is what we imagine for Python in 5-years”.
1 Like
I think the “community” is a bit too defensive here. Take the example of static copilation: I think it is pretty clear that everyone wants that, and there is progress in this front. Would be in any sense detrimental to have that listed in a “Julia roadmap” page, explaining that it is a desirable feature, with an explanation, eventually updated, of its current status?
14 Likes
I’d say it would be a mistake to look at these as some sort of “road map”. They are a tool for developers to present their ideas and get feedback from other developers. Different developers use different places and mechanisms for this:
Some of mine (HackMD):
Some have used this GitHub org:
Some write it in a julia issue (or in PRs):
The point is that these posts should not be taken as an intention to inform “the public” about anything, nor should they be taken as an indication that some specific thing may happen in the future (take Juleps/StructuredConcurrency.md at master · JuliaLang/Juleps · GitHub for example). Since these documents are made for developers, it is also probably better to let the developers decide where they are posted and how they collect feedback on their proposal.
A more formalized process where you have to go through a big process to get things going would, in my view, not be beneficial for the quality or velocity of the project. (But I realize it is fun to read these things).
4 Likes