THANK YOU. I didn't know about this, myself.
I love the philosophy and robustness of the BEAM VM, but I can't go back to the stone ages of a language with a poor (or non-existent) static type system.
I love the philosophy and robustness of the BEAM VM, but I can't go back to the stone ages of a language with a poor (or non-existent) static type system.
What you probably want is a strong type system. Functional programming languages (I'm thinking Julia as an archetype of strongly typed systems) especially are really good at dispatching over types, and can make robust optimizing inferences using a well-designed type system.
BEAM languages are strongly typed, but there are far fewer types (and no true custom types) like julia. However, gating based on functional guards is simply amazing and more than makes up for a limited type system in terms of code clarity. As for compile-time vs runtime error trapping - part of the point of BEAM languages is "who cares?" An error doesn't bring down your VM. It gets logged, you can see it, and apply a hot patch and fix it if you need to.
It won't bring down your VM, but it will impact any end-users of your service. Not all errors can be solved by restarting a process or retrying a request (but I recognize the argument that you should aim to catch those types of errors in tests because they are part of the core business logic).
Also just wanted to note that hot-patching has serious costs. Code upgrades/downgrades can be difficult to write and the upgrades themselves also need testing (and this often doesn't get the attention it needs).
There are no silver bullets, basically.
Expressive, algebraic types allow me to tell my compiler, IDE, and code heirs what I'm trying to do so they know just by reading my code if I failed. That's indispensible.