This may be a dumb question, but what is the purpose of Dialyzer? WHY should someone use it? I’m looking over its official docs and I’m not seeing anything that answers these fundamental questions (!). Dialyxir doesn’t answer any of these raison d’être questions either, it just punts and says “I’m with Dialyzer”. Ok, it does a static code analysis, ok, it helps identify “software discrepancies” which may include dead code, but it doesn’t seem to even attempt any elevator pitch as to why someone should go through the trouble of using it. Its documentation seems to fall into the trap of focusing almost entirely on HOW… how to run it, how it does its analysis, etc. etc. etc. our eyes glaze over and we start thinking about being a teenager and listening to father rant about growing up and being responsible.
I can infer that having unreachable code is bad and that I may want to remove it, but what do you really get out of combing through your code with Dialyzer? Do you get performance benefits? A cool membership card? My code coverage is 100%, all tests pass – isn’t that enough?
(Yes, I know I’m being deliberately snarky here, but I honestly do want some more insight on this because I think a well-crafted sentence or two that addresses this absolutely belongs in the documentation).
This writeup from “Learn You Some Erlang” is older (refers to Erlang R15 as “the latest”) but still really useful as an introduction to success typing:
Short short version: Dialyzer attempts to prove that code has bugs by deducing types, where “types” can also include things like "a tuple matching {:ok, _}". It doesn’t always work - for instance, it can’t see through runtime-dispatched code like deps.foo_adapter.bar(x,y,z) - but when it tells you there’s a bug there is one.
I’m a big Dialyzer fan. I enjoy having specified types. It helps with documentation and when using functions you may or may not have written — it’s nice to know what the contract is without having to read through the source code.
I’ll also say that every time Dialyzer has said I have a bug, I did. Sometimes what it catches are things that would be tough to debug without typing.
It’s a pretty easy set up and integration with your editor really unlocks the power.
Because the beam puts the restriction that you can’t spec functions that don’t exist, but nothing but name and arity and existence of mentioned types is checked.
It is not checked if the spec makes any sense in context of the speced code or vice versa
Dialyzer will uncover some obvious errors within bounds.
The difference between dialyzer and “conventional” typecheckers is, that dialyzer assumes that you are right, unless it can prove you wrong, in contrast to “conventional” which assume you are wrong, unless they can prove you are right.
This major difference is what often confuses people new to the dialyzer.
To be honest, I don’t even understand your question.
The answer is simple, one runs dialyzer when one wants to typecheck their code. Not more, not less.
Currently there are no alternatives, as gradualizer is still not a thing.