> In case it's not clear from the above: Crystal supports type annotations, they are enforced by the compiler, and it's not uncommon to use them in practice. Y

> In case it's not clear from the above: Crystal supports type annotations, they are enforced by the compiler, and it's not uncommon to use them in practice. Yes, I considered that when I was writing my post. :) > In a more strictly typed language (that doesn't support intersection types), I couldn't do that without first defining some interface that includes `to_json` and `to_yaml` and then maybe convincing the compiler that my objects qualify for the interface (by extending their class definitions or casting at the call site), which is a lot of work to enable a trivial method whose purpose is already clear. In Crystal, the compiler just checks that whatever you're passing into the method has `to_json` and `to_yaml` defined and lets you get on with life. > Another good case is removing redundancy on wrapper methods: I fully agree that there are cases where the relative number of keystrokes saved are considerable; however, these cases are quite rare and keystrokes are much, much cheaper than readability. Also, structural subtyping (aka protocols aka 'static duck typing') allows the compiler to determine whether or not a type implements an interface without an explicit `implements` declaration. In any case, I don't want to put too fine a point on it. In the worst case it's a relatively minor inconvenience and perhaps it adds more ergonomics than I'm giving it credit for.