On: Why I program in Erlang (2012)

[resonious]

I was thinking the same. At this point it's hard for me to believe that a programming language can provide that much productivity. You always find counter arguments from people who have worked in very large teams that use language-in-question. The counter arguments also tend to over-correct - just because one company has a mess written in <lang> doesn't mean <lang> is bad.

I've been writing a lot of plain JS in my free time lately and it's been awesome. Just like the article, I've written all kinds of things in it and it's been a breeze. I don't think this is because JS is great - it's just because I have a lot of practice and I don't have to worry about real business requirements, deadlines, other people, or other people's code. If these side projects of mine became team projects where each member has varying skills, interests, and experiences, I'm sure it'd become a mess - especially if I quit!

[rkangel → resonious]

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.