If it’s in CI it means contributors need to know about it or I have to fix the issues they introduce. I don’t think it’s worth it for myself either since there have, at least traditionally, been many errors that are not fixable in generated code and with protocols. Errors that we cant fix also makes CI practically useless since it will always fail. The effort is usually not worth the value it provides.

Dialyzer does not do what I want a type checker to do. In traditional type systems you write types and then verify the code against the types - the types are the contract. In dialyzer the code is the contract, dialyzer ignores the types and uses the code as single source of truth. After verifying the code without the help of user-given types it then checks the types against the code, but this is limited since it will only show an error if it can guarantee that the type does not match the types inferred from the code.

This is the correct behaviour of dialyzer because it should never reject valid code [1], but for me it makes it a lot less useful.

[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.62.3859&rep=rep1&type=pdf

I can’t say why Phoenix isn’t using Dialyzer, but personally I feel like the value it provides does not outweigh the downsides it brings. Dialyzer makes it harder for contributors because it’s slow, the errors are hard to understand and you need knowledege of Erlang syntax to understand it.

I would rather get more contributors and have Phoenix more approachable to beginners than use Dialyzer.

Interesting, as I was thinking of adding dialyzer to my project, with the hope of onbording contribute with more guide rails.