(Note, the following is in jest but I still mean it )

You shouldn’t need to. That is why you are on the beam. It is meant to crash on patterns you don’t care about. It makes the code cleaner to only handle happy path and not litter the code with code that should not happen.

What do you do when you don’t handle one of 132 error codes from the socket module? Probably a catch all which swallows and logs the error or returns it to someone who has even less knowledge how to handle it. Instead the right thing to do is to let it crash and let the expert supervisors handle it. After all. It is their only job.

If it turns out that clause is part of your domain, then you add it and handle it accordingly.

(Obviously, this is something I would only recommend in beam languages and not to be tried elsewhere (until they have an equally good story on failure handling))

There are few things, which need dynamic typing: modules defined at runtime, hot code updates, ducktyping (if if quacks it’s a duck), …

But the most important one is (distributed) message passing.

You could also look at gleam and what it can’t statically type.

Comparing the TS+JS with Elixir can be a bit misleading. The main reason TS provides such a benefit in the JS world is two things: the poor tools for on offer structuring code (in Elixir we have modules, processes, apps-as-deps, etc.) and the fact that it is weakly typed. Static typing helps with the weak typing as it helps provides static analysis to do what the runtime really ought to be doing. It’s a (very) imperfect solution, but TS goes a long ways to addressing the weak-typing issues of JS.

Elixir (or, rather, the BEAM) is strongly typed. This is what enables guards such as is_integer and why we get runtime errors when using the wrong sort of data (e.g. passing an integer rather than a string to Integer.parse/2). Static typing allows one to write code that is far more predictable and can defend where needed against odd / bad input.

On the other side, static typing typically means more boilerplate / verbosity and less generic code. But it can also allow for more performant code generation by giving further hints to the compiler, catch bugs that would otherwise slip through … the exhaustive pattern matching of Rust has already been mentioned, and that can be quite useful in some cases.

I think it is instructive, however, that many statically+strongly typed languages are moving more and more to allowing for type inference and generic programming that makes the language look and feel a lot more like a dynamically typed language (C++ an Java both being examples there).

We do have dialyzer and it is pretty decent, particularly for a (mostly) functional language. The function is a good unit of typing for Elixir … buuuut .. it is slow (I suspect this is more an issue of implementation rather than due to any inherent weakness in function annotation), its error reporting can be pretty obtuse at times (though that’s an attribute of many static type systems, particularly older ones), and it doesn’t actually enforce any contracts in code (it is documentary-only .. change the function? you need to also update the @spec, not that the code will care and often enough dialyzer won’t tell you about it either ..). So it’s an imperfect system.

I don’t think a whole new language on the BEAM to introduce static typing makes any sense whatsoever, though. Static typing is not nearly a good enough reason to pick a language. It is at best a tie-breaker between ‘equally useful’ options. The amount of highly reliable code being written using Elixir demonstrates that the margins for improvement are not huge.

Personally, I’d love to see a more integrated version of @spec that has better performance characteristics. The type inference dialyzer has is already pretty decent, it’s more about QoL and integration.

Just my 0.02 …