The future of Julia, 1.6, 1.7-rc1, 1.8, 1.9, 1.10 and 2.0 and LTS

Julia 1.7-rc1 [EDIT: is done, 1.7-rc2 is coming]. Julia 1.6 has been approved as LTS, while not yet announced (I would rather want 1.7 as LTS, but it’s not up to me).

Julia 1.0.x has been the long-term support (LTS) release, officially, for little over 2 years already, and is actually over 3 years old. With the next LTS, it no longer will be.

Given a new LTS out soon I think we’re in a very good position to talk about Julia 2.0, even with it having has “[technically] breaking” changes, if the pre-2.0 LTS is going to be supported for years I’m not worried.

Julia 2.0 has 7 open PRs and 72 open issues, but it’s unclear Julia 2.0 will ever (or soon) happen. Python 4 is a known in-joke, that’s never going to happen, and it’s unclear to me if the 2.0 milestone is such a garbage can, code for “never going to happen”.

Is there a subset of the 2.0 open issue we can all agree on implementing? Julia version 2.0 would break some older (private) code, not a lot (but we can ensure all public packages keep working), still all 2.0 code would work in older Julia versions, e.g. the LTS, with the same semantics, if we want to be conservative (cleaning up the language, no great speed-benefit, e.g. for “stop exporting HTML and Text from Base” and many such issues), or with slightly different semantics if we want to be less conservative, are ok with the approving issues like “Parse 1 + 2 + 3 as +(1, +(2, 3))” (increasing speed, sometimes by much).

Julia 1.8 has 4 open issues. Julia 1.9 and 1.10 milestones were recently added, but so far have no issues linked to them and no milestones have a due date, while my understanding Julia is on a time-based schedule as of 1.7.

https://charlesleifer.com/blog/new-features-planned-for-python-4-0/

All new libraries and standard lib modules must include the phrase “for humans” somewhere in their title.

2 Likes

Julia is a scientific programming language. It can asymptotically approach 2.0

34 Likes

Don’t pay too much attention to GitHub milestones. They’re internal organizational tools, not external promises.

20 Likes

At this point I don’t think there’s any breaking changes that seem worth it, and there’s been so much non-breaking improvements and other work to do that there hasn’t been any bandwidth available to think about 2.0 issues. I suspect at some point 1.x work will slow down a bit and we’ll get some more capacity to stop and think about 2.0 kinds of changes, but that time just hasn’t happened yet.

39 Likes

Is there a world where we run out of release versions and have to go to 2.0? If we are already at 1.7, theres not a lot of room to go (Though I don’t know the criteria for a major release)

You can go as far as you like. Version 1.132.2 is just a few years away.

12 Likes

Just to be explicit for everyone, it’s not that version 2.0 must follow version 1.9. You can have 1.9, 1.10, 1.537,1.538,… and then when you are ready, you can go to 2.0.

7 Likes

Just an observation: this is a powerful testament to how well-designed Julia 1.0 was. We’re more than three years past the release of 1.0 and despite the wide uptake of the language, nobody has discovered any major issue or improvement that would require a 2.0 release to fix.

When you consider how individual Julia packages often require multiple breaking iterations to arrive at a long-term stable API, it’s frankly amazing that the core Julia devs managed to design an entire freaking language in just five years and six 0.x releases that (so far) stands the test of time.

[I’m willing to bet that if we get a 2.0 release in the next 5 years it will be mostly to facilitate static compilation and stand-alone binaries, and even so it will only be “formally breaking” and require minimal changes to existing code.]

18 Likes

To be fair, a lot of it is that breaking changes for Julia is way more work to fix than breaking changes for a package. There are plenty of things we would fix if it were free to do so, but that are hard to justify given how annoying fixing them would be.

1 Like

Once we get to Julia v1.4294967295 we’ll be forced to either change the definition of VersionNumber or release Julia v2.0.

16 Likes

Thanks :hugs:. I do think it might make sense to release Julia 2.0 with some technically breaking changes that aren’t all that breaking.

4 Likes

Linus Torvalds released Linux 5.0 after 4.20 because he ran out of fingers and toes.

Although Julia count the minor version number using a different system.

2 Likes

Ah yes, the clasic int4.321928094887363 datatype

2 Likes

He really should be using his fingers/toes to represent an Int20, not an Int$(log2(20))!

3 Likes

Yes, so do I. I think we can and should make a 2.0 branch/nightly, where all (current) 1.x packages will work in 2.0 plus (new) 1.x code could work in 2.0, and all 2.0 code will work in 1.x.

It would be easy, it’s just a matter of choosing what goes in and what gets postponed to Julia 3.0.

I’m the kind of guy that lives on the Julia edge, I use Julia nightly for my development anyway, so I would use this alternative nightly.

I think even I could fork Julia to drop stuff, and add a few bits, but that branch would quickly get stale and not be of much value unless it’s publicly known, and be on the official download page. There would be no commitment to it being stable, like with the current nightly, but also no expectation of 2.0 being released soon. The value to the developer comes with you knowing your code will work also in 1.x, and it will be future-proof for an eventual 2.0.

We should stop exporting a bunch of stuff from Base, e.g. HTML, Text and position. Also The Core exports list is very long · Issue #39114 · JuliaLang/julia · GitHub. Julia 2.0 is about a. removing stuff (to make Julia better for the future), but that may not get anyone excited. And possibly b. adding stuff.

I think with a “technically breaking”* 2.0 people will ask what was the point, I see no change, why upgrade the number with no new important feature. What could they be? I feel we needs at least one carrot, something for performance, e.g. “Parse 1 + 2 + 3 as +(1, +(2, 3)) · Issue #34999 · JuliaLang/julia · GitHub”.

I know some people would like and and or operators. I would want those keywords in, but for now only to prevent those used as variables, giving you a syntax error, to get time to discuss the semantics (I had a proposal that wasn’t just a synonym for && and ||). There’s a precedent for keywords doing nothing in other languages, at least in F# for potential OCaml compatibility, and discussion on dropping them now. We could define their meaning in 2.1, or even change our minds and return to the status quo.

* Some of you may not know what a “technically breaking” change is, that’s a good example. As variable names, and and or are awful, and probably no one is using them, thus nothing breaks in practice. We can only check with PkgEval for known code, i.e. all registered packages. That gives us some confidence adding them will not break old code, but it’s not a guarantee, and new code in Julia 1.x could break 2.0 for some reason, e.g. defining those variables. That’s why I wrote “1.x code could work in 2.0”, i.e. if you’re careful, and you would prevent accidents by using the nightly, or at least test with it (that could be a requirement for registering new packages).

For position Julia 2.0 code would need to use Base.position, an that would also work in 1.x, and it would free up position as a variable in 2.0 only. In 1.x:

julia> position = 1
ERROR: cannot assign a value to variable Base.position from module Main

That’s an example that would work in 2.0 but not in 1.x, and I wrote “all 2.0 code will work in 1.x” (possibly should have written “almost all”). Is there a good way to postpone freeing up position in 2.0 except by adding it as a dummy keyword? If not, we may be ok with “2.0 code could work in 1.x if you’re careful”. For a while we should test all code in old 1.x Julia and new 2.0.

We should “move MersenneTwister out of Random · Issue #41272 · JuliaLang/julia · GitHub” and probably “Deprecate norm(x,0) · Issue #30810 · JuliaLang/julia · GitHub” while I’m not sure about “== for immutables should recursively call == on its fields · Issue #4648 · JuliaLang/julia · GitHub”.

I don’t know about all proposals e.g. postpone this one? 2.0: just one import keyword · Issue #39235 · JuliaLang/julia · GitHub

And 2.0: remove `===` fallback for `==` · Issue #40777 · JuliaLang/julia · GitHub

This would be heavily breaking, so definitely not a 1.x thing

This one seems very important: String constructor truncates data. · Issue #32528 · JuliaLang/julia · GitHub

Telling people that mutating functions are marked by a ! and then not following it in seemingly arbitrary cases is worse than not having the convention at all since it lures one into a false sense of security when they read code.

with this response:

If we’re willing to wait until 2.0 to do this then yes, we can deprecate String for String! and then later reintroduce String to always make a copy. But for 2.0, as I said above, we may well have the ability to freeze and thaw arrays and require passing a frozen byte array to String .

A bit off-topic, but gave me an idea for Julia: The chimera(?) in Iceland, called Helmingur (e. Half), with a black half, and white half, and only one horn, none on the black half, so a bit of a unicorn. See video at 16:00:

Here Google translated (video not working here): Google Translate

Maybe Julia 2.0 branch could include 1.x and 2.0, with some clever conditional compilation. I was thinking how easy or difficult it would be to maintain two nighties. Python has from __future__ import … and potentially we could have one binary with two modes, 1.x and 2.0, and from either side you could opt into the other one.