eqwalizer VS FunkyABX

I don't think the implementation itself is at fault, but yes, I do think that the design of dialyzer makes it an (at times) faulty type checker. The unfortunate reality of a type checker that fails sometimes is that it makes it mostly useless because you can never trust that it'll do the job.

To be clear, I've had it fail in a function where I've literally specced that very function to return a `binary` but I'm returning an `integer` in one of the cases. This is a very shallow context but it can still fail. Now add more functions, maybe one more `case`.

I think an entire rethink of type checking on the BEAM had to be done and that's why eqWalizer[0] was created and why Elixir is looking to add an actual sound, well-developed type checker. Gleam[1] I would assume is just a Hindley-Milner system so that's completely solid. `purerl`[2] is just PureScript for the BEAM so that's also Hindley-Milner, meaning it's solid. `purerl` has some performance issues caused by it compiling down to closures everywhere but if you can pay that cost it's actually pretty fantastic. With that said my bet for the best statically typed experience right now on the BEAM would be `gleam`.

0 - https://github.com/WhatsApp/eqwalizer

1 - https://gleam.run

2 - https://github.com/purerl/purerl

While it's not static-typing, compile-time type checking for Erlang have come a long way: Eqwalizer works pretty well - but I may be biased since my employer sponsors the project.

1. https://github.com/WhatsApp/eqwalizer

Note there is also research happening in this area by the Elixir team. The WhatsApp is also working on static types for Erlang, which I am certain will be available for Elixir too at some point.

From the discord blog posts it seems that elixir powers the chat system, with rust and python as the other two main languages in their stack.

As for whatsapp, they are mainly a erlang shop and yesterday they open sourced a type checker for erlang:

https://github.com/WhatsApp/eqwalizer

All web frameworks fail with forms one way or the other :)

I think one point would be the docs, to outline the basic cases, best practices. Maybe something tying the form helpers and changeset.

I have a side project [0] with a form which have inputs dependant of others and a dynamic section (assoc).

I struggled a bit with the data, checking what I would get inside a changeset struct, until I "discovered" get_field and put_change.

For the assoc I was also a bit lost until I read an article using a delete virtual field. In the end I made it work but I still not sure I used all the right changeset functions.

To LiveView credits this app has been used all over the world and got very good feedback, nobody mentioned any lag issue etc (well, someone with a crappy connexion in Istanbul once got an incomplete uploaded file without getting an error).

[0] https://github.com/conradfr/FunkyABX

Hello, this is a LiveView app (although most of the player code is in javascript).

https://github.com/conradfr/FunkyABX