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? https://github.com/JuliaLang/julia/issues/39235
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 .
. I do think it might make sense to release Julia 2.0 with some technically breaking changes that aren’t all that breaking.