A review of the Julia language (2014)

Re:A review of the Julia language (2014) by attractivechaos on Sunday September 09, 2018 @12:02PM (#17946476)

Which versioning scheme to use doesn't matter. What matters is how long you promise to keep a language "stable". Java and javascript have gone through many major versions, but the core of the language is largely stable. The same will be true to golang. Read their plan [1], the paragraph starting with "Go 2 must also bring along all the existing Go 1 source code". That is promised backward compatibility. There have been breaking changes in Perl5 (so it is not following semver), but most of the changes were minor and little user code was affected. Python 2=>3 is a disaster. If Julia goes through a dramatic change like that in 5 years, it will be worse.

[1] https://blog.golang.org/toward-go2

[ Parent | on HN ]

Re:A review of the Julia language (2014) by StefanKarpinski on Sunday September 09, 2018 @02:47PM (#17947184)

When they write "bring along" they do not mean "Go 2 will be backwards compatible with Go 1". Pre-1.0, Go extensively used "go fix" to automatically upgrade older Go code to newer versions. (If they had never introduced incompatible changes as you seem to be claiming, this would not have been necessary.) They will most likely do the same thing for upgrading code from Go 1 to 2. Although that alone is likely to be insufficient as the failure of py2to3 demonstrates; they will probably need to also support using Go 2 packages from Go 1 or vice versa.

Julia has taken a similar albeit less automatic approach with deprecation warnings. When a breaking changes have been made, in one major release it continued to work but issued a warning telling you how to change your code. Only in the following major version did the code actually break. This allowed people to upgrade, run their tests (you have tests, right?), fix the warnings and be good to go.

More recently FemtoCleaner [1] has been introduced, which automatically makes PRs to projects and upgrades them just like "go fix" does. When we release Julia 2, we'll use a similar approach, so if your happy with how Go is doing things, you should be happy with how Julia does them.

It's fairly straightforward to avoid the Python 2/3 debacle, they key is to always allow packages to support two "adjacent" major versions at the same time, so as to not cause "upgrade deadlock" [2].

[1] https://github.com/JuliaComputing/FemtoCleaner.jl

[2] https://discourse.julialang.org/t/1-0-adoption-path/7922/39

[ Parent | on HN ]

Re:A review of the Julia language (2014) by attractivechaos on Sunday September 09, 2018 @06:16PM (#17948083)

I will ask this more explicitly: how soon will you deprecate features in 1.0? 2 years? 5 years? 10 years? Go 1 is 6 years old and Go 2 seems at least a few years away, and the paragraph I was referring to says "Mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa, must work effortlessly during a transition period of multiple years.", which suggests they will keep the Go 1 compatibility for "multiple years" after Go 2 kicks in. That adds up to 10 years. If Julia can promise to keep the vast majority of 1.0 features around for 10 years, I will be good with that.

[ Parent | on HN ]