We use it at work but I never in my personal projects. I also don’t use specs except on defstructs and behaviours (though do use pretty liberal use of pattern matching and guards where it makes sense). I’m one of those dynamic-loving wienies and probably always will be.
sodapopcan
3
ErikNaslund
As an Elixir beginner I’m using Dialyxir and it gives me some value, so I keep using it. I’ll echo what others have said before me - the error messages are really hard to understand compared to what something like mypy produces for Python. It’s gotten to the point where I usually don’t read the Dialyxir messages, but instead just look at the code/specs myself and try to figure it out.
As always, if I practised reading the error messages more I’d get better at it, but there’s definitely some skill involved in making sense of them right now.
3
eksperimental
I encourage everyone to start using Gradient, GitHub - esl/gradient: Gradient is a static typechecker for Elixir · GitHub, and publishing issues with whatever you think it should be improved/fixed. I will help a lot to Gradient and Gradulizer itself to reach the point of maturity that still needs.
8
mattludwigs
I use it everywhere and all the time. After 6 years of full time Elixir I think it’s one of the most underrated tools available to us. I think dialyzer is only as good as you use it. More (and better) the types, the better it works. I think when it’s sprinkled in a code base and the type definitions aren’t very clear (like using any, term, keyword, and map types) most places the tool doesn’t really help. Being really clear in the typing and use of type docs also provides a benefit to the documentation of the code and even that provides longer lasting benefits to maintenance over time. It’s one of those tools where you get out of it what you put in IMO. It’s not perfect in developer experience but it has provided me massive value over the years. Drop me into a Elixir project with very little to no types I’d probably struggle, I am not smart enough to not use types in my code base.
9
Will-W
I have two decent size work projects. We use dialyzer pretty consistently through that project - specs on the interface to every module and dialyzer run in CI.
I’m not sure we got value out of it - we spent some hours tracking down odd failures that we’re caused by an area completely different to where the error is reported and mostly it was a dialyzer/spec issue rather than a real one.
So when the second one started I didn’t make it part of the process. Dialyzer is not running in CI and there is only the occasional hand written spec (in addition to ones provided by libraries and use of behaviours). We do get some value out of this - I (and most of the team) have error highlighting on VS Code like you normally do and that catches some stupid stuff before running anything. As our target is embedded (Nerves) that can really save some time.
If the errors were better (both in content and pinpointing the location) then I would definitely revisit it, but I remain to be convinced of the value of ‘tacking on’ a type system. I need to experiment with gradualizer too.
2
chrismccord
Creator of Phoenix
Dialyzer as it exists today is a net negative value add for me. I only use it if forced. In principle it checks out, but in practice it always costs more than it saves.
18
erszcz
Dialyzer gets some time to get used to and I understand the pain associated with learning how to use it effectively.
Moreover, I have the impression that in Elixir, due to much higher macro proliferation than that of parse transforms in Erlang, it’s more often “wrong” (not technically wrong, but a nuisance without being helpful) because of warnings about the generated code. E.g. a macro might take params and based on them sometimes generate clauses which are always true or always false etc. This will trigger a Dialyzer warning. It’s not a Dialyzer bug, rather a macro bug or just “coarseness”, but the result is having to add such cases to dialyzer.ignore-warnings 
3
kenny-evitt
I’ve run into a lot of the things others have already mentioned, e.g. cryptic errors, but I think, overall, Dialyzer is great. It does make me wish that typespecs were more ‘algebraic’ – or that I could (sometimes) use ‘regular’ static typing instead.
Most of the errors/warnings reported for the code in the projects for which I’m using Dialyzer have been helpful – it’s definitely spotted real errors/issues.
The biggest annoyance has been warnings about other code tho, i.e. dependencies. That did result in me contributing at least one fix to another project tho, e.g. correcting a typespec. But even reproducing the warning for the dependency itself has been difficult, in particular for at least one Erlang project.
In the biggest project for which I’m using Dialyzer, it takes less than 30 seconds to run, even when several dozen files need to be compiled first. That’s acceptably fast IMO.
4
Qqwy
TypeCheck Core Team
As someone who is working a lot with Typespecs, for instance while working on the library TypeCheck, here’s some of the struggles I have with using Dialyzer:
- Adding it into any project of reasonable size is slow, sometimes unsustainably so.
- When it reports a problem, it is often very unclear why it is caused, and even moreso how it might be fixed. For example, help with this long-standing ‘function call with opaqueness mitchmatch’ problem would be greatly appreciated.
- Elixir’s standard library itself does not follow Dialyzer’s opaqueness rules correctly, and fixing this would be a difficult and backwards-incompatible change. Essentially this means that pattern-matching on “pattern matching on the struct name allowed” structs like
MapSets will make Dialyzer complain about usage which is recommended by Elixir’s official documentation. (Source: elixir/#8463 and elixir/#8480)
However, I still use it regularly, especially on smaller and simpler projects. I like the ‘belt ánd suspenders’ kind of approach w.r.t. detecting potential bugs early.
And as @eksperimental already noted: Gradient/Gradualizer is a wonderful new project, and very much worth keeping check on!
9
evadne
I have Dialyzer integrated into CI as standard. Largest codebase on hand is 33k lines of Elixir (excluding dependencies) which passes such a check. We did run into some issues with dependencies. Our solution was to submit pull requests that fix the issues. We do not hesitate to ignore obviously compliant files, however.
Have tried Gradient against the same codebase. Very interesting!
4