Almost all of those 'correctness flaws' are bugs in packages that weren't interfacing with each-other correctly. Everything has bugs and correctness problems, but it may be that Julia users run into them more often because they compose packages in novel ways very often.
But we also have very rigorous testing infrastructure and a community that cares deeply about these things and moves very fast to fix them. You'll notice that every legitimate issue in that post is now closed and fixed, and the remaining ones are about the users misusing in place functions in the presence of aliasing.
I think it's fair to point out that Julia makes it really hard to write robust, correct code.
There are a lot of different interacting reasons for this (it deserves a blogpost on its own), but here are a few:
* There are no interfaces
* Existing abstract types are mostly undocumented: It's unknowable and certainly untestable what constitutes an IO or a Number or even an AbstractArray (yes, even AbstractArray leaves important edgecases unspecified).
I've written 100 methods that takes `::IO`, yet I don't actually know what it can take. Much of the issues with unsupported package interactions come down to this: One package doesn't know what it promises, and the other one doesn't know whether the promise is upheld. E.g. it's still unclear to me whether `OffsetArrays` actually fulfill the contract of an AbstractArray. If not, it's a bug that it's an AbstractArray. If so, Base is insufficiently tested, as it ought to test its AbstractArray code with an AbstractArray with offset axes.
* Base Julia have several functions that are simply not tested. CodeCov of Base is far from 100%
* Iterators are assumed by Base and Iterators to be immutable - a buggy assumption in many contexts
* It's not even clear what is public and private in a package. E.g. are fields of exported struct private? Where is that documented? And it's way too easy to rely on unexported symbols.
* Speaking of which, you can export stuff that does not exist.
* Projects does not have compat entries by default
* Generic functions are rarely tested generically - i.e. not with any minimal abstract type.
* Promotion rules of non-numbers are unclear and underspecified, and accidentally changed recently on master because it's not documented nor tested anywhere
* There is a lot of "Yeah, X isn't really semantically correct, but I can exploit its weird behaviour in my own code, so we shouldn't fix it, it's actually a feature" hacker attitude among Julians.
There are like, 100 more small things that make Julia more bug-prone. I think this is a serious issue about the language that we should take note of and try to work on. You'll notice several of these issues can be resolved. But we need to take it seriously.
I'm starting to think that multiple independent implementations of a language are important for catching implementation quirks before they become entrenched.
> Almost all of those 'correctness flaws' are bugs in packages that weren't interfacing with each-other correctly. Everything has bugs and correctness problems, but it may be that Julia users run into them more often because they compose packages in novel ways very often.
I agree with this. Yuri's post requires a bit of Julia experience to understand the context of it, that much of it is about drop-in combinations of packages and types that one wouldn't even attempt in many other languages. Julia allows you to do that and makes it programmatically easy, which has significant benefits. But it also requires work on the implementers' side to get right.
> But we also have very rigorous testing infrastructure and a community that cares deeply about these things and moves very fast to fix them.
Not sure how much I agree with this. If you're talking about the language itself, sure. But a lot of the libraries don't have extensive testing infrastructures, especially not the kind Julia obviously needs based on the above, with beyond-the-expected-usecase tests. Maintanence of packages varies a lot, with the median being on the slower side. There's definitely "a community that cares deeply about these things", we just need more of it.
But we also have very rigorous testing infrastructure and a community that cares deeply about these things and moves very fast to fix them. You'll notice that every legitimate issue in that post is now closed and fixed, and the remaining ones are about the users misusing in place functions in the presence of aliasing.