I read through the rest of this properly, it’s a nice piece.
A further comment on data hiding. You write
Julia does not enforce data hiding, so anyone can access your fields directly. The convention is like Python: If a field’s name starts with an underscore, you should consider it an implementation detail, and it is subject to change and produce strange effects if you mess with it.
On average I’ve observed that the julia community doesn’t actually follow this convention, though some packages do. Base takes the lead here; consider fieldnames(Dict) for example. I think it’s perfectly fine to recommend underscores but it would be clearer if you mention that the ecosystem is inconsistent.
I did find the intro paragraphs of “Polymorphism and Code Reuse” a bit confusing. I wasn’t quite clear on the points you were trying to convey there.
Some more piecemeal comments:
const Opt = Union{T,Nothing} where T
can be written
Opt{T} = Union{T,Nothing}
You write:
So why are types used to implement traits rather than other kinds of values? That’s an easy one: Types are known at compile-time. Values are only known at runtime. This means that traits are computed only when the dispatch compiles and have no cost thereafter.
It’s a bit more subtle than that. Both types and values may or may not be known at compile time, and both can be used during type inference as of ~julia 0.7. However, the ability to use values for further type inference depends on constant propagation and inlining heuristics (I think. I’m a bit hazy on the details). On the other hand, types have been practically usable as traits for much longer. More importantly, the heuristics about how types propagate during type inference are quite different and make it possible to pass trait types between functions without depending on inlining decisions. At least, I think it’s something like this; again I’m not expert on this part of the code.