It’s only worse when comparing to static languages like Go, Rust, Swift, Kotlin… If you don’t have much experience with this type of languages it’s hard to explain the warm feeling you get when the code compiles. The stricter the type system, the warmer the feeling 
But Julia probably has lots of room to improve in this regard. To take an example from my previous post: I could not find which methods I had to implement to satisfy the IO interface. Well, @contradict found it for me. But what if the Julia developers add a new method to this interface, let’s say a method that is only used when you show an Array{T} where T<:IO with MIME type text/html? When and how will you realize you need to adapt your code? Most likely when it crashes in the face of that particular user that hits that corner case.
In Go this list of method would be written explicitely in an interface definition like this. And if they add a method in Go 2.0, my code with type T::IO will refuse to compile until I implement this new method for T.
Such explicit interfaces could be added to Julia. The compiler could then tell me it’s not properly implemented, as soon as I use it with my type T, even if the missing method is not actually used.
Indeed, but my example was from the standard library, not from an obfuscated code contest… And I’m not saying that code is bad, just pointing out a downside of expressiveness.
I think Julia makes it too easy, and therefore too likely, for some types of projects.
A language could offer every tool and leave it to the users to use them wisely. Modern C++ is a bit like that. But is it good design? There’s something true in the quote “Perfection is achieved when there is nothing left to take away”. For example, Go was designed in part by taking things away from C++, see this essay from one of the designers. I don’t think it would be the best approach for Julia, but in my opinion it makes Go a good choice for some types of projects.
And can you really “leave it to the user” to be wise in practice? My personal experience is that it doesn’t work well, especially for large projects with heterogenous teams. It’s nicer and more reliable to have discipline enforced by the compiler. And internal code styles don’t help when you want to use open source projects.
Also, the benefits of a coding style increase with the size of the team, so they’re largest when the constraints are part of the language: the style is automatically enforced for the whole ecosystem.