Beyond the state of the Julia Language (which I am excited to try out since 1.0), the core community comes off really badly in this post, and the previous follow-up discussion on HN [1], and julia-users group [2].
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.
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.
I didn’t make as much as effort as the writer of the post, but I had several negative interactions when trying pre v1 releases. This was far more discouraging than questionable code quality.
IMHO, one of the worst things Julia had done was to unnecessarily break so many backward compatibilities (e.g. renaming shift!() to popfirst!() – who cares? and how many user code this will break!). As a result, a great portion, if not the majority, of Julia tutorials online are not applicable to the latest version any more. This leads to a lot of headaches when you learn Julia. I know v1.0 is supposed to be stable, but their track of record makes me doubt. I will see what they do to v1.1 and then decide if it is worth learning.
Older languages like C/C++, Java, Javascript and Perl5, regardless of their versioning schemes, have been mostly stable for decades. There were minor breaking changes from time to time but the language cores are largely compatible backwardly. Newer languages like Go is on a similar path. This is what we need for a programming language.
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.
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.
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].
For Perl you are forgetting the HUGE amount of code that just works 10-15 years later. I love Perl for many reasons but here is where most other languages gets killed.
Older languages also had to exist in a much less networked world. The more 2.0 changes can be done by a robot making a PR, the less concerning they will be.
This is clear FUD. The developers directly stated with previous releases that backwards compatibility wasn't a top priority, and things weren't backwards compatible. Now with v1.0 the statement is that the language is far enough that it is a priority. Why would past telegraphed instability be indicative of future untelegraphed instability? There have already been multiple proposals shut down due to backwards incompatibility since the v1.0 release, so developers are clearly taking it seriously given the comments in the PRs.
Hopefully people go to GitHub or discourse.julialang.org or julialang slack and try out for themselves.