For some applications it is quite hard to overstate how much easier Erlang (or in my case Elixir) does make things. For a web backend, the concurrency approach

For some applications it is quite hard to overstate how much easier Erlang (or in my case Elixir) does make things. For a web backend, the concurrency approach means that you can handle each request as synchronous, "blocking" code (the easiest to reason about). In practice the GenServer system means that you're probably doing a lot of sending messages to a lot of other processes[1] and waiting for responses, but it all looks and feels like function calls and returns. Similarly I use Nerves for a hardware control application. I have an operation that's doing a multi-step bit of communication where the actual comms is handled via an IC on an SPI bus. You build your layers of driver, abstraction and then eventually application code over the top, and I end up with a really clear top level function that basically looks like: configure_radio() send_request(flags, data) wait_for_done_flag() read_response() All of this works perfectly, doing SPI transactions, waiting for responses and all operates perfectly on the same VM that's also monitoring some registers, as well as running a live web interface for introspection, handling graphql requests etc. And then if there's an error case that I haven't handled the code that communicates with the IC will all restart and reconfigure the IC, so that transaction will fail, but the next one will likely work fine. [1] Processes here using the BEAM terminology - a lightweight userspace scheduled thread of execution. Similar to green-threads, fibres or goroutines.