[loeg]

The linked article doesn't attempt to refute the significant claims from Dan's article (which has an update from a year later, so 2015, at the bottom):

1. That the language is (was) undertested, and as a result, full of easy to run into bugs

2. The language makes it easy to ignore errors

3. APIs are inconsistent

4. The head branch isn't kept build-clean (i.e., often it fails to build)

5. Code is often undocumented, with non-descriptive naming. The combination makes it difficult to understand what code is doing.

Dan also writes that he expects the performance issues would be fixed and those aren't what concerns him:

> The purely technical problems, like slow load times or the package manager, are being fixed or will be fixed, so there’s not much to say there.

And bonus community problem:

> Update: this post was edited a bit to remove a sentence about how friendly the Julia community is since that no longer seemed appropriate in light of recent private and semi-private communications from one of the co-creators of Julia. They were, by far, the nastiest and most dishonest responses I’ve ever gotten to any blog post. Some of those responses were on a private discussion channel; multiple people later talked to me about how shocked they were at the sheer meanness and dishonesty of the responses. Oh, and there’s also the public mailing list. The responses there weren’t in the same league, but even so, I didn’t stick around long since I unsubscribed when one the Julia co-creators responded with something bad enough that it prompted someone else to to suggest sticking to the facts and avoiding attacks.

Now, I don't know if any or how many of those issues have been fixed since 2014-2015. But the 2018 blog post about microbenchmark improvements doesn't really address these concerns.

[kristofferc]

There have been over 25 000 commits since that post was written, clearly, any comments about the specifics of the language are terribly out of date.

For example, the base language now has 92% test coverage. CI is being run on Windows 32/64 bit, Linux 32/64bit, macOS, FreeBSD with ARM CI coming up. Every day a large number of benchmarks are run on dedicated hardware and the results are tracked. Benchmarks are also run on most PRs that has potential performance implications bhefore merging. Before new point releases, the tests for all registered packages are run and compared to the old version. Every new failure in a package test is tracked down to make sure there is nothing breaking in the point release.

While package load time is still an issue, the introduced precompilation feature has significantly helped with this. Also, new methods of working with the language, like Revise.jl (https://github.com/timholy/Revise.jl) which updates the code that is being executed in real time when you save your file, makes load time much less of an issue.

No matter who the author is of a blogpost, if it is made about something that has been in rapid development for years after the post was written, the information will have little relevance to the current situation.

[ihnorton]

(1) Test coverage has dramatically improved. (2) Improved, and to some degree a matter of taste (Julia is not statically checked, so some errors can only be discovered at runtime) (3) There has been significant refactoring since 2014 to improve consistency, especially in the recent push toward 1.0. (4) Developers are much more disciplined now, and just about everything goes through CI. (5) Docs are much, much better for both users and developers. For the latter, see https://docs.julialang.org/en/latest/devdocs/ast/ and others in that section (none of which existed in 2014, IIRC).

> And bonus community problem:

I can't comment on private discussions to which I was not a party, but people can search the archived google groups discussions (julia-users) for the blog author's name to read the public threads.

That said, the core of the concern, as I understand it, was that these perceived issues would put a damper on growth. Young languages, especially, need growth to outpace attrition to maintain viability (ecosystem, broad testing and platform support, etc.). Three years on, with sustained user-base growth, increased funding, and Julia having been used for a number of articles in high-impact journals (e.g. Nature) -- I think this concern is somewhat less pressing. See https://pkg.julialang.org/pulse.html for a snapshot of the sustained ecosystem growth, and https://discourse.julialang.org to get a sense of the breadth, depth, and responsiveness of the community (in my obviously-biased view, of course!).

A related concern, was (quoting the blog post):

> A small team of highly talented developers who can basically hold all of the code in their collective heads can make great progress while eschewing anything that isn’t just straight coding at the cost of making it more difficult for other people to contribute. Is that worth it? It’s hard to say. If you have to slow down Jeff, Keno, and the other super productive core contributors and all you get out of it is a couple of bums like me, that’s probably not worth it.

Julia as a whole has had 697 contributors right now. At the very core of the language, the parser and lowering code have well over 40 contributors, and code-generation (LLVM lowering) has over 60.

[urschrei]

It's really shocking to me that years later, nobody has addressed the most serious issue (community interaction) Dan brought up. Just reading the archived mailing list thread I could not believe the suspicion, and later outright hostility towards Dan's comments. It obviously dawned on a couple of core contributors, as can be seen by the sheepish attempts to walk things back, but this sort of interaction _with the project leadership_ is a giant red flag about how they view their community and users. If someone like Dan can be treated in that way publicly (and far worse privately, according to his own account), things are going to be so much worse for other people.