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.
The answer to that has been and will remain “no” for the foreseeable future. As for Python, the creator had a less positive take 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.
Probably because it is not on the table in the foreseeable future.
It is unclear why these would require 2.0.
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 ).
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.
There’s not a huge reason to go to 2.0, e.g. not OOP, since it can be added, is already available:
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.
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!
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.
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.
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.
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.
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++, …).
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.
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
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.
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.
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):
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> @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
What do you mean? Binary code for dependencies is already precompiled and cached, it’s just not for scripts, and juliac is solving that?
).