# Is Julia 2.0 needed?
**URL:** https://discourse.julialang.org/t/is-julia-2-0-needed/120842
**Category:** Internals & Design
**Created:** [October 3, 2024, 7:45am UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842 "2024-10-03T07:45:57Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Kirby\_Zhang](https://discourse.julialang.org/u/Kirby_Zhang)
#### Post date: [October 3, 2024, 7:45am UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/1 "2024-10-03T07:45:57Z")
Python made a big break by going from Python2 to Python3. I haven’t seen much talk about Julia 2.0; the last threads that kind of referenced were from already from 2018.
If 2.0 ever comes, I would like Julia to have several features:
- class inheritance and interface inheritance
- permanently fixing type piracy and invalidations
- transparent caching of compiled binaries
- robust tools to help convert Julia 1.0 packages
Julia 2.0 can make the ecosystem much more robust.
I would like to offer a few general comments. Julia solved the two-language problem of Python, but Python is becoming even more entrenched. It’s the glue for software that large companies have written in C/C++, allowing diverse developers and users to interoperate. Julia by being efficient in itself discourages this usage scenario. Julia 2.0 by becoming more robust and more general purpose, can become “casual C++” and gain mindshare over developers who don’t need the system language features of C/C++/Rust.
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [October 3, 2024, 7:51am UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/2 "2024-10-03T07:51:16Z")
The answer to that has been and will remain [“no”](https://towardsdatascience.com/why-julia-2-0-isnt-coming-anytime-soon-and-why-that-is-a-good-thing-641ae3d2a177) for the foreseeable future. As for Python, the creator had a [less positive take](https://www.techrepublic.com/article/programming-languages-why-python-4-0-will-probably-never-arrive-according-to-its-creator/) on the transition from v2 to v3 and ruled out v4, unless something extreme develops in C compatibility or the GIL. Let a language be what it is, there’s more than enough work on new features to do without breaking everything.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [October 3, 2024, 1:39pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/3 "2024-10-03T13:39:03Z")
> [@Kirby\_Zhang](#):
>
> I haven’t seen much talk about Julia 2.0
Probably because it is not on the table in the foreseeable future.
> [@Kirby\_Zhang](#):
>
> - permanently fixing type piracy and invalidations
> - transparent caching of compiled binaries
It is unclear why these would require 2.0.
> [@Kirby\_Zhang](#):
>
> class inheritance and interface inheritance
Since Julia _as is_ does not have classes and the language has no interface specs, again it is unclear why these would require a breaking change in the language.
That said, the day the language gets “classic OOP” will be the one I join a doomsday cult and/or start learning Rust. Fortunately, I think that many core devs feel similarly, so I am safe (and so are Rust and/or doomsday cults 😉).
---
### Author:  [@Kirby\_Zhang](https://discourse.julialang.org/u/Kirby_Zhang)
#### Post date: [October 3, 2024, 1:49pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/4 "2024-10-03T13:49:06Z")
Taking away type piracy and requiring interfaces will introduce many breaking changes including the standard library.
---
### Author:  [@Kirby\_Zhang](https://discourse.julialang.org/u/Kirby_Zhang)
#### Post date: [October 3, 2024, 1:53pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/5 "2024-10-03T13:53:42Z")
He’s probably talking about giving institution clients more support during the transition. Python3 has even more deployed codebase they just don’t want to tackle that, unless it comes with major performance upgrade.
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [October 3, 2024, 2:30pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/6 "2024-10-03T14:30:08Z")
There’s not a huge reason to go to 2.0, e.g. not OOP, since it can be added, is already available:
> **[GitHub - Suzhou-Tongyuan/ObjectOriented.jl: Conventional object-oriented programming in Julia...](https://github.com/Suzhou-Tongyuan/ObjectOriented.jl)**
>
> Conventional object-oriented programming in Julia without breaking Julia's core design ideas
> [@Why there is no OOP (object oriented programming) in Julia?](https://discourse.julialang.org/t/why-there-is-no-oop-object-oriented-programming-in-julia/86723):
>
> I am coming from Matlab and Python background and I have recently started considering Julia seriously for software development. My main question is why Julia is not designed as OOP like python? As far as I can see OOP is not against speed and multiple-dispatch but in contrast it allows a very clean division of code into classes, etc. This may not be a big deal in mathematics and computation but it is quite necessary in software development because it encapsulates functions and data in the same…
With new `juliac` (its PR was recently merged, it’s in 1.12) you have compiled binaries, and avoid these issues, I believe:
- permanently fixing type piracy and invalidations
- transparent caching of compiled binaries
You can add a lot of things without any breaking changes, though I still think we want 2.0, with some _technically_ breaking changes, and it wouldn’t be difficult to migrate to, or support older 1.x Julia with same code, but it’s not a huge need, and I realize I’m in minority pushing for it. With 1.10 soon LTS, it might become a good time to think of such more.
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [October 3, 2024, 3:06pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/7 "2024-10-03T15:06:13Z")
> [@Kirby\_Zhang](#):
>
> If 2.0 ever comes, I would like Julia to have several features:
>
> - class inheritance and interface inheritance
> - permanently fixing type piracy and invalidations
> - transparent caching of compiled binaries
> - robust tools to help convert Julia 1.0 packages
>
> Julia 2.0 can make the ecosystem much more robust.
Just to be clear: Julia 2.0 doesn’t come about on its own. And its existence wouldn’t magically change the ecosystem. Both Julia and the ecosystem are developed by _people_. People who are doing _work_.
The path to improvements is not typically through big breaking changes, but rather iterative and incremental steps that everyone can take together. Join in!
---
### Author:  [@Kirby\_Zhang](https://discourse.julialang.org/u/Kirby_Zhang)
#### Post date: [October 3, 2024, 3:14pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/8 "2024-10-03T15:14:12Z")
OOP is more involved than this. It’s not enough to inherit fields, but you need to verify contracts so types can be fully implemented and documented, and type piracy isn’t even possible. This is why Java is heavily used in enterprise, even though it’s an old language with few modern features.
I’ve published the following package [Inherit.jl - Package Announcements - Julia Programming Language (julialang.org)](https://discourse.julialang.org/t/inherit-jl/99102/17) which verifies type implementations, handles parametric types, while dealing with cross-module inheritance issues. But even there it’s far from complete.
It’s been a long way to speed up time-to-first-plot. I’m skeptical 1.12 can really make binary caching transparent. One purpose of breaking changes in 2.0 would be to prohibit invalidations. To keep up with other languages, Julia needs to gain general purpose developers who are good at building scaffolding around the language. Most Julia users who feel very satisfied currently probably haven’t seen it in an enterprise situation.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [October 3, 2024, 3:22pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/9 "2024-10-03T15:22:28Z")
> [@Kirby\_Zhang](#):
>
> To keep up with other languages, Julia needs to gain general purpose developers who are good at building scaffolding around the language. Most Julia users who feel very satisfied currently probably haven’t seen it in an enterprise situation.
There are tradeoffs in language design, and I think it’s a mistake to try to target all possible situations with a single language. Enterprise audiences are very different from scientists and engineers and technical computing. There’s a reason why the two groups don’t typically use the same languages.
---
### Author:  [@Kirby\_Zhang](https://discourse.julialang.org/u/Kirby_Zhang)
#### Post date: [October 3, 2024, 3:25pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/10 "2024-10-03T15:25:54Z")
What you said is quite true. What motivates Julia 2.0 for me is how much Julia has dropped from the radar as a talked about language, and the mind share it has been losing. Plotly/Dash --probably the best interactive charting library-- already dropped Julia support. Julia has unique advantages, and nudging it in a different direction may open some potential vs the current trends.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [October 3, 2024, 3:30pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/11 "2024-10-03T15:30:32Z")
> [@Kirby\_Zhang](#):
>
> Julia has dropped from the radar as a talked about language, and the mind share it has been losing
Citation needed 😉
---
### Author:  [@Kirby\_Zhang](https://discourse.julialang.org/u/Kirby_Zhang)
#### Post date: [October 3, 2024, 3:35pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/12 "2024-10-03T15:35:38Z")
You can look up which languages the AI assistants have learned. Julia comes up as barely a blip.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [October 3, 2024, 3:55pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/13 "2024-10-03T15:55:09Z")
> [@Kirby\_Zhang](#):
>
> You can look up which languages the AI assistants have learned. Julia comes up as barely a blip.
Sure, but that’s not the same as a downward trend. Julia has _always_ been a niche language in comparison to the dominant ones (JavaScript, Python, Java, C#, C++, …).
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [October 3, 2024, 3:58pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/14 "2024-10-03T15:58:34Z")
I’d also challenge the assumption that a breaking release — even if it contained the answer to life the universe and everything — would increase Julia’s “mind share”. In fact, it’d certainly have an immediate _dip_ in mindshare due to the ecosystem bifurcation. There’s lots of folks using Julia _right now_, and there’d need to be something _really compelling_ that has _no nonbreaking alternative_ to throw that away.
---
### Author:  [@tecosaur](https://discourse.julialang.org/u/tecosaur)
#### Post date: [October 3, 2024, 4:01pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/15 "2024-10-03T16:01:05Z")
A potential Julia 2.0, if it ever happens, will only because a sufficient number of major features are impossible to implement in a non-breaking way, and the core team judges it worth all of the inevitable hassle and turnover.
This is an extremely high bar.
By contrast, most of the items mentioned so far can entirely or at least in part be implemented in a backward-compatible way, more effort would just make them happen sooner 😉
---
### Author:  [@Taaitaaiger](https://discourse.julialang.org/u/Taaitaaiger)
#### Post date: [October 3, 2024, 4:07pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/16 "2024-10-03T16:07:40Z")
As others have said Julia 2.0 would break compatibility will all existing packages, it’s essentially a new language. The only reason for a programming language to go that route is when issues that severely prevent the adoption and use of the language can’t be solved in a way that maintains backwards-compatibility.
---
### Author:  [@Kirby\_Zhang](https://discourse.julialang.org/u/Kirby_Zhang)
#### Post date: [October 3, 2024, 4:07pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/17 "2024-10-03T16:07:51Z")
Julia seems to have been optimized for “time to first code”. It wanted to follow Python’s path as a teaching language. Otherwise, it’s inexplicable why time-to-first-plot has been so difficult to improve after many years. There’s also the even less tractable problem of type piracy and buggy libraries due to lack of interfaces.
To maintain some backward compatibility, I’d look into inferring interfaces.
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [October 3, 2024, 4:13pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/18 "2024-10-03T16:13:12Z")
Note there’s talk of:
> [@This month in Julia world - 2024-06](https://discourse.julialang.org/t/this-month-in-julia-world-2024-06/116704/1):
>
> There are considerations of how to remove some of Julia’s warts without a breaking Julia 2.0 release: a “[strict mode](https://github.com/JuliaLang/julia/issues/54903)” and [versioning of export statements](https://github.com/JuliaLang/julia/issues/54905) seem like a pretty big step in that direction.
The “strict mode” would disallow some Julia syntax, and if it were not done with a strict mode it would require 2.0, but with actually can be done in 1.x. So what exactly do you want _deleted_/disallowed from Julia’s syntax or semantics? Or changed (is same as deleted and addition). Anything to be _added_ can be done already in packages and/or in Julia (and a lot has already be done like two OOP systems and pattern matching systems), more or less; even syntax is handled in a (stdlib) package, and it CAN be added to at runtime… At least the new parser was changed at runtime, when it was in development, it’s now the default (the point was always compatibility, not adding syntax, but could have done it). I can only see changes to the default GC a bit difficult, and there are already alternatives.
I’m not sure what you mean with “permanently fixing type piracy”, I think like accessing/calling non-public, type piracy can be powerful, but if either disallowed, then a lot would break(?). We might need some gradual migration, allow-by-default, then later change the default or the user could until then?
Invalidations and recompilations are certainly annoying, but only a runtime/startup-speed issue, not a show stopper? And packages can be improved to avoid it(?).
Do you want to change Julia to a fundamentally different (static) language? I believe static analysis tools go a long way to fix your problems.
FYI: Julia _has_ actually already been forked, into a static language variant (with one new keyword if I recall):
[ ](https://www.youtube.com/watch?v=IPE2aur0RWo)
It might be mostly (or only?) for robotics. And _I think_, it’s proprietary, at least its runtime Romeo, but I might be wrong on both counts, where do I find it?
The other OPP system I had in mind: ObjectSystem.jl (the developer didn’t know of the former one…). Only/one reason I could see for such capabilities would be more visibility, but I think they should just be documented to exists (in Julia’s official docs…), to avoid reimplementing, not that I want OOP in Juli itself, I dislike OOP for performance reasons, and maintainability reasons, as much as the next guy. But I like that the options are there. For some strange reason the GitHub repo is gone, and I’m not sure where it is, how Julia installed it, so I can’t find the docs (was it deleted abandoned since redundant, not good enough yet?), [EDIT: ObjectOriented.jl works too, and starts very quickly.]
```julia
julia> @time using ObjectSystem
..
[Info: Skipping precompilation since __precompile__ (false). Importing ObjectSystem [beb21ac1-5488-4e8e-a65a-eed5c6ff7e13].
13.983373 seconds (6.72 M allocations: 496.686 MiB, 3.70% gc time, 52.19% compilation time)
```
There are some other related packages e.g. OOPMacro.jl and false alarms (I was looking up the name and docs): ObjectPools.jl and some possibly helpful to you: Interfaces.jl
> [@Kirby\_Zhang](#):
>
> - transparent caching of compiled binaries
What do you mean? Binary code for dependencies is already precompiled and cached, it’s just not for scripts, and juliac is solving that?
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [October 3, 2024, 4:29pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/19 "2024-10-03T16:29:13Z")
> [@Kirby\_Zhang](#):
>
> Otherwise, it’s inexplicable why time-to-first-plot has been so difficult to improve after many years.
This is not a blocking issue for most science/computing tasks where people are interested mainly in long-running computations.
---
### Author:  [@DNF](https://discourse.julialang.org/u/DNF)
#### Post date: [October 3, 2024, 4:43pm UTC](https://discourse.julialang.org/t/is-julia-2-0-needed/120842/20 "2024-10-03T16:43:51Z")
> [@Kirby\_Zhang](#):
>
> it’s inexplicable why time-to-first-plot has been so difficult to improve after many years.
But this _has already_ happened. Or, what are you referring to?
[Next page](https://discourse.julialang.org/t/is-julia-2-0-needed/120842.md?page=2)