Other lang communities have public roadmaps e.g. rust, go, ruby, etc I’m wondering if there’s a version for Julia I can take a look. It would help immensely, particularly in terms of transparency, community, etc. Thanks.
11 Likes
i don’t know if its official, in the sense its not at the front page of the JuliaLang org, but this post is an idea:
2 Likes
Can you post some links to such roadmaps? The only one I can find is this one for Rust:
Which appears to be more of a “statement of general intentions” than an actual roadmap. I cannot find any roadmap documents for Go or Ruby.
2 Likes
I really like the VS Code roadmap. It is high level, i.e. not a detailed plan of upcoming work. More like a vision statement for the next 12 months.
I think a short writeup along the lines of what you wrote originall here say every 12 months or so would be awesome.
12 Likes
I second what @davidanthoff said, except that is still a bit too detailed for me. 5 item maximum! But yes more like a vision statement or intentions rather than a detailed action plan.
Forward guidance – it’s good enough for the Federal Reserve, why not Julia?
1 Like
Aight, here’s our roadmap:
- Become the best
editorprogramming languagefor anyone who relies on accessibility features - Improve performance, scalability, and security of
VS CodeJulia and its extensions - Tackle some of the most wanted and most emotional user features (done!)
- Polishing and a constant trickle of design refreshments
- Incrementally improve already existing features
- Responsibly enable extensions that have broader extensibility requirements
- Tackle a couple of big rocks that push the boundaries of what
VS CodeJulia can do
31 Likes
You picked the one paragraph from that page that is pretty useless from the VS Code roadmap 
Everything below that paragraph is super useful.
2 Likes
But more seriously, we’re still working through that same list of compiler work, although a lot of it has gotten done. There’s a lot of in-progress Pkg work, which is outlined here. That is maybe half done, half still in progress. Most everything else is just fixing issues and deciding on features as they come up. I’m kind of unclear on what kind of guidance people are interested in. Everything seems to boil down to: try to make things better that are not great while not breaking things that are good.
6 Likes
I think a simple post that updates that old list would be great. It could be an update which parts are done, which are still open, what the core team sees as priorities etc. Having a link to the Pkg plan in that would be great.
I don’t think such a post would contain any information that isn’t somewhere already. But for folks that don’t roam github issues obsessively, having a short kind of “here is an update on my post from a year ago” would be great. Your post back then got a lot of likes, I think it was exactly the kind of information folks are looking for. So I think doing something like that once a year would be great.
8 Likes
Here’s a very detailed one for Ruby:
Rust just changed to themes in order to get the working groups to come up with their internal details, but once those are set the roadmap becomes quite detailed.
I don’t think there’s a right or wrong way to approach roadmaps. But for a community to say contribute, I’d be nice to know what’s there to work on and perhaps the rationality behind it. Makes sense?
Sure, that seems reasonable. I guess I’m the one who’ll have to do this.
6 Likes
Hehe, yes, I think so I mean, I could write something if you promise that you commit to what I’m writing down 
4 Likes
As far as I can tell, that’s just a bug tracker link. We have that as well:
If you want to know what’s planned to go into specific releases, there are milestones for those, for example Julia 1.4 and Julia 1.5. I should point out that these links are not terribly useful because we don’t do feature-based releases (anymore), we do timed releases, which means that whatever new features are merged to master by the feature freeze date for a release, those features go into the release; anything that doesn’t goes in a later one.
4 Likes
For reference, here’s a pseudo-roadmap about Go: Proposals for Go 1.15 - The Go Programming Language and this one for go 2: Toward Go 2 - The Go Programming Language
For both the Ruby and go communities these roadmaps predate/followed by some sort of keynote during conference. I’m new to Julia so I’m just trying to figure out how it operates and be able to help.
1 Like
I’m probably sounding like a broken record at this point, but task views (a la CRAN task views) could be a good start to this. A living document of what is available for a certain aspect of the ecosystem and goals would distribute labor so one person isn’t responsible for all of it.
For example, there could be a “task view” for package and project management that includes relevant packages and current community efforts and goals.
3 Likes
Fixing every single issue is of course always the plan, but it’s obviously not going to get done in our lifetimes, so it’s all a question of priorities. Is the core team prioritizing fixing core infrastructure (performance of captured variables in closures, eliding views allocations, compilation time…), tooling (debugger, Pkg, package compiler…), multithreading (composability, performance…), ease of use, specific applications…? Are any of these “wontfix” for the time being? The old list was useful for that. Also some idea of what breaking changes will be in julia 2.0 and what timeframe (if any) is scheduled for it.
2 Likes
I am not sure what those words mean in this context. Can you clarify?
Especially about transparency — pretty much all the work is out there in the open already: discussion happens in issues and pull requests, and keeping an eye on the latter is a good way to follow what is going on. Which part of Julia’s development do you consider not to be transparent enough?
Short- and medium-term goals are best followed using milestones, eg for 1.5 you see a couple of outstanding issues.
It is difficult to plan very much ahead, because priorities shift and new issues come up. Because of this, I am skeptical about the utility of lists (in blog posts etc) as roadmaps: they will either be very vague, or get outdated very quickly.
5 Likes
I mean transparency in the purest sense of the word. Projects of this kind have different forms of transparency. For the context I’m referring to I’m concentrating mainly on the rational of thinking behind what’s to be included in the next version. Access to the code is one form of transparency, but it doesn’t explicitly tell me the “what, why or how” of what’s beyond the original thesis from which the project stems from or the videos from the Juliaconfs of past year.
The impetus behind those decisions is important for many reasons depending on who you are what your plans are in utilizing Julia. One that’s simple to relate to is duplication of effort. Julia has a direct relationship with the LLVM. For all the greatness that LLVM brings to the table in terms of machine created code, it’s slooooow. From a malleability point of view I could say, well I could go about making compilation faster in Julia from Julia or from the LLVM. If I know what the core team is thinking about tackling that issue I’m better equipped to make a decision as to where allocate my efforts. There are plenty of other examples I can give - and I’m sure others here have their reasons as well - but I think this one is fairly easy to comprehend.
Hope that makes sense.
2 Likes
The typescript roadmap is a pretty amazing living document: https://github.com/microsoft/TypeScript/wiki/Roadmap
3 Likes