> Erm, you can setup dialyzer to be as strict as possible.

No. This is just plain false. Having used dialyzer since 2016 I can tell you it's not useful as a substitute for statically checked types via a compiler, with real strictness (which includes "When I don't have enough info, that's a type error").

> This might not catch all the errors because of the nature of messages, but this is a pretty small part of a system usually and can be covered by tests.

Not only will it not catch obvious type errors, it will also report false types when the core team doesn't use dialyzer in their libraries (because it doesn't work). These will bubble up to you instead and while you're mad they're not using dialyzer you'll still have to admit you understand why they don't.

I'm not sure what you mean by give you examples of how Elixir type specs aren't useful for domain modelling. They're ad-hoc, serve as documentation at best and even if they had structural power enough to express basic things they aren't checked at all, so you're getting none of the guarantees you would get in a statically checked language where your model changes and you can safely go forward by seeing what needs changing additionally to adapt.

Elixir doesn't have any concept of real tagged unions or sum types. Modelling is intimately connected to checking because when we change something (as we are wont to do) we want to have that change bubble out into the rest of the system safely. This just isn't reliable at all in Elixir.

The most potent data modelling tool you have in Elixir is a `struct`, which is just a `Map` with `atom`s for keys. You can then associate this map with an ad-hoc `atom` tag in some return value if you want, and that's as far as we can go.

Modelling behavior in Elixir is easier and better, with processes, but having absolutely zero guarantee that what you're doing makes sense when it comes to data hierarchies and composition is just not useful when trying to outline what data represent and how it can be represented.