I don't know if I'd call it duck-typing when methods are not grouped into interfaces. I think you could say that in Julia, each method is an interface. I find it much cleaner than actual "duck-typing" (the way it's done in , say, Scala with structural types) because then you have both an interface, which specifies a contract, as well as the method name, which also specifies a contract when duck-typing is used, even when it's found in different interfaces.
Must compound types in Julia be concrete? I don't think I saw it in the documentation.
It's been discussed, and would be satisfying to have an `Iterable` abstract type and ensure that every object implements `Iterable` satisfies contract of having appropriate `start`, `done` and `next` methods, but that requires two features we don't have yet: multiple inheritance of abstract types, and some way of specifying an interface. There's been some discussion of this, and I believe we have the way multiple inheritance could work mostly worked out; enforcement of interface implementation, not so much. However, it's a pretty massive undertaking to add it to the language. Quick teaser: generic functions and final concrete types actually make multiple dispatch work a lot better than it does with single dispatch and the "bag of named methods inside an object" model of traditional OO.
So far we haven't actually felt a "pressing need" for multiple inheritance or interfaces, and we tend to take a pressing-need approach to language features. If you can live without a feature for a while, then maybe you really didn't need it in the first place. But we'll have to see what happens when other people are starting to try to use if for things.
Aren't compound types inherently concrete? The compoundness describes the implementation of the type, implying that it must have an implementation, hence must be concrete.
Must compound types in Julia be concrete? I don't think I saw it in the documentation.