* 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.
