If you have been programming for a while, there’s a good chance you have lived through breaking changes in ecosystems which may have left a bad taste in your mouth. Many people I have met speak disparagingly of the transition the Python ecosystem went through from version 2.X to 3.0. While most would likely agree that it was worth it in the long run, this transition still consumed a significant amount of resources for the ecosystem.
But what about Julia? Does having a 1.X version give people the idea that the ecosystem is still too immature? Would a 2.0 release spark mass adoption and be the catalyst for Julia becoming a top 5 programming language?
In this article, we will explore why Julia is unlikely to get a 2.0 release anytime soon and why that is actually a good thing for current and prospective Julia developers.
In the early days of the Julia ecosystem, much of the criticism of Julia stemmed from the volatility of the ecosystem. The language’s core API would change which left developers scrambling to adapt to changes. These frequent changes prevented industry adopters from having confidence in the language which was why many initial use cases were academic or hobby projects.
As the path to 1.0 and stability got closer, the core development team released Julia 0.7 which was the bridge to Julia 1.0 and included many warnings about how the API would change in the new version. On a personal note, this time period was exactly when I started using Julia. My first experience with the language was working through deprecation warnings and updating the syntax for a large Julia project I was working on at NASA.
The forthcoming major Julia release is Julia 1.9. This version will likely be around in 3–4 months given the current release schedule. You can read about what the proposed changes are on GitHub:
One big change that I am personally excited about is:
@kwdef is now exported and added to the public API ([#46273])
This is a long-standing open request from the community that was previously something you had to use an external package to accomplish. Another new feature that is being added is:
New pkgversion(m::Module) function to get the version of the package that loaded a given module, similar to pkgdir(m::Module). ([#45607])
This should give users more context on what versions are being loaded into certain modules which was something that you used to have to tediously figure out.
All of this is to say that there are still lots of amazing new features, bug fixes, and improvements coming in each new Julia major version.
Well, after Julia 1.9 is….. Julia 1.10 😄. No really! Core Julia developer and co-creator of Julia Jeff Bezanson said at JuliaCon this year:
“There is no 2.0 plan. There’s no date, there’s no spec for it. There really is no such plan in the works. If anyone ever thinks of something that sounds like a good idea but would be breaking, we just tag it 2.0 as an issue and leave it for if or when that happens.”
If you want to see the type of issues that are being thought about for 2.0, check out:
As you can see, the details are rather scarce since most ideas that are being proposed can be implemented without breaking changes.
The stability of Julia is something users and developers have grown to love over the years (especially for those who lived through the early Julia days with constant changes). From a design perspective, it truly speaks to the high-quality decisions that were made that we have made it all the way to 1.8.1 now (4 years since 1.0 was released) without breaking changes.
Jeff goes on to say further that:
“But as for me personally, of the things that I would want to see, I don’t believe any of them really require breaking changes. Anything that I can see we should do can be done in a 1.X non-breaking way. So I don’t see a need for 2.0 right now.”
This could obviously change over time as the needs and opinions of the core Julia team changes, but developers today can rest easy knowing that if they invest time, money, and intellectual capital into building systems with Julia, the API will be stable for years to come.
While I do personally think a 2.0 release would bring a lot of great visibility to the language, it is probably better to keep things as stable as possible while the ecosystem continues to grow exponentially. One small counter-point is that if there was going to be a 2.0 release, doing it sooner rather than later is likely better since the longer we wait for this, the more Julia code will have to be updated to make things work. Hopefully, if the day ever comes, Keno Fischer can reboot the Julia FemtoCleaner which automatically updated deprecated syntax for you.
What do you think about Julia 2.0? Drop a comment below and let me know!