Purescript also has an Erlang backend !

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 don't find staticness to be the gating criterion for me. Go, for example, has a static type system that's IMHO very poorly designed - for example, if you want to multiply a time interval by some integer, you have to convert the integer to a time type and then multiply, which breaks my poor science brain (violates fundamental concepts of dimensional analysis). You also have to do things like pick between implementing something with slices versus fixed size arrays, and generic functions are not an option. I couldn't write fn dot_product{n}(v [n]int){...} for example.

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.

I like a type system that leans closer to Haskell than not. As someone else mentioned, my users prefer me to catch errors before compile time :)

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.

> 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.

Out of curiosity, what languages do you prefer to work in?

Nothing is a slam dunk. I love and hate even my favorite languages (TypeScript, F#, Elm). Hoping Rust will be the silver bullet once I have time to try it.

Try to give scala a whirl. It's pretty nice.

I'm also making a backend for Idris: https://github.com/jameshaydon/idris-elixir