Thanks for the feedback! We’re trying to make Gradient as user-friendly as possible - there is significant effort put into making sure it integrates nicely with Elixir, but indeed, the software is still experimental.

Could you create a ticket with an error that you consider hard to read? Or given an example here? I’ll be happy to take it forward.

That’s the never ending story of type checkers / static analysis - how to make the checker detect real problems in code on one hand, yet still be flexible enough to allow for all quirks of the language and full expressiveness on the other. However, even more so in this case, we would be extremely happy if you could report false positives on the project’s GitHub page.

Any feedback is good feedback, so keep it coming I strongly believe it might only lead to making the tool better!

Getting back to main differences.

Gradualizer has a different approach than Dialyzer in reporting errors. Dialyzer advertises that “it’s never wrong”, which is true, but sometimes its feedback is a bit hard to use (the lovely “function … has no local return” and no direct hint on what to do with it). It’s also quite slow, though it’s not as much of a problem as it used to be a few years ago.

Gradualizer reports more kinds of errors and allows for some tricks known from other statically typed functional programming languages like exhaustiveness checking - see example screenshots of Gradualizer being used with the Erlang Language Server in this post. It’s also significantly faster, as it doesn’t require generating PLTs. Actually, thanks to its speed it’s very convenient as a background tool in the editor. However, in this experimental phase, it means some false positives might get reported.

To get a better feel of what’s possible with Gradualizer, that’s not possible with Dialyzer, you might want to watch my lightning talk about typechecking Elixir from ElixirConf EU 2021 or read about the typestate pattern in Erlang.

In the long run Gradient should offer everything Gradualizer does and maybe even a bit more thanks to some macro magic

Dialyzer was build on the idea of success typing. This makes so that dialyzer can work even without user input, just based on code itself. It also tries to not report false positives quite heavily. But it comes with the downside of not detecting many of the error cases other static typing systems can detect. (The link below even argues that dialyzer is not a type system)

Gradualizer is a completely different approach. Afaik it doesn’t do type inference, so unless you manually provide typespecs it does nothing. But for the places you do provide them, it’ll statically check for errors even beyond what dialyzer would be able to detect or would acknowledge. The other big part between the lines is that you can gradually add type safety to your systems. It’ll work with as much typespecs as the code does provide.

For more details see this one:

Essentially both tools try to detect errors, but do that in quite different ways with therefore quite different tradeoffs.

The most recent commit to Gradualixir was almost two years ago. Can someone give me an idea of its current status and prospects? Is anyone using it as a production tool?

-r

I don’t disagree but I think people fear this more than they should. I’ve worked for financiers a few times and yeah, there you should be afraid of lag spikes going to 10 milliseconds; something most apps wouldn’t even notice.

Everywhere else I ever worked though? Meh. Nobody bats an eye if 1 out of 20 requests takes 3 seconds even. Nobody cares. And to this day Rails developers insist that ActiveRecord (the ORM of Rails) being responsible for 100-150ms delay per web request (admittedly only if it has 3-10 DB queries, of course) is small and is not important. In the meantime a similar Phoenix endpoint in its entirety returns in 7ms at the most.

When it comes to such an impressively fast dynamic language environment like the BEAM VM I don’t view some minuscule delay like 2-10 more ms as consequential. Anything that helps avoid bugs, not leak people’s private data, and not lose money should be counted as a win, even if it comes at the expense of performance.

Another example: Rust’s compiler is slow but it does eliminate several entire classes of bugs by the mere virtue of your program compiling.

IMO we need more such tech in our line of work, including in the Elixir ecosystem. It’s amazing how much traffic can a mere modern i3 mini-computer with 32GB RAM and a SATA III SSD can serve; we should focus on correctness because buying 20% more hardware capacity is a rounding error in most companies.

I was waiting on a few things to finish but never got around back to it, work got crazy in a few different ways than it was before. I specifically never published it because I didn’t consider it to be done enough for that and I didn’t want to potentially steal a good name for such a tool, so please, anyone fork it or remake it.

This might indeed be the remake!