[1] https://news.ycombinator.com/item?id=8809422 [2] https://groups.google.com/forum/#!topic/julia-users/GyH8nhEx...
Hopefully people go to GitHub or discourse.julialang.org or julialang slack and try out for themselves.
Two of the people who look the worst are co-founders of Julia. Are they not involved with Julia anymore?
Dan's representation of things is wildly misleading. We worked with him extensively and even had him over to a 4th of July party the year that he was working on Julia stuff. Dan wrote a fuzzer and found a lot of obscure but not practically important bugs, almost all of which were nevertheless fixed quickly. He also found a few other less obscure bugs which were also fixed, usually within a few hours. He made a number of fixes himself as well, for which we were and still are greatly appreciative.
Dan had complaints about various things about Julia at the time. He was in the habit of emailing me directly about them. This is not great form in open source, but we were personally acquainted so it was fine. However, since I didn't have the knowledge or time to fix most of these issues, I generally encouraged him to post them on julia-dev or GitHub. As I recall, he usually did not.
As this continued, I encouraged him to write a constructive blog post about what he thought could be done better. Instead, he wrote a gotcha piece—the one posted here yet again—that implied that we don't care about bugs or software quality and had ignored or dismissed issues that he'd reported. He had been studying what kind of content does well on HN and how to get on the front page [1], and it's tempting to speculate that he knew that a dramatic criticism would get much better traction than a fairer critique.
[1] https://danluu.com/randomize-hn/
Shortly thereafter, in a semi-private forum which I was also on, he wrote a lot of significantly less kind things about about us. I responded to his semi-private "shit talking" in what I still think is a measured fashion. He did not appreciate the pushback and amended his formerly glowing review of the Julia community to what you now find in his blog post. I am the "core dev" that Dan is obliquely referring to. In retrospect, I guess I shouldn't have pushed back at all and just let it go. But having someone who you have gone out of your way to help and showed every hospitality and kindness to, then turn around and talk smack about you in a place where they know you'll read it, frankly really sucks.
Even now, there are some fanatics.
In terms of names, we do care a fair bit in trying to pick intuitive names that clearly communicate what a function will do.
FemtoCleaner also will auto update your code for these breaking changes, by making a pull request to your repo.
How long will Julia keep its backward compatibility? Based on the history, I suspect that in five years, Julia will release v2.0 and break a lot of user code again. Hope I am wrong here.
TLDR: if there aren’t breaking changes it won’t be called 2.0 it will be called 1.12 or something like that.
Go is currently planning their 2.0 release precisely so that they can make breaking changes. It was a big deal when they reached 1.0 for exactly the reason that they stopped making breaking changes. Ditto with Rust. We are following the exact same course. If it feels different, that’s because you weren’t using either language pre-1.0.
See also the Python 2 vs 3 transition and Ruby 1.x => 2. Comparing with Perl5 is ignoring the huge changes made in Perl2, Perl3, Perl4 and Perl5, not to mention Perl6.
That leaves Java and C++. Yes pre-1.0 Julia was more breaking than those two, ancient, industrial warhorses.
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