I try to explain to my friends why I’m so enchanted by Elixir but it’s difficult to explain because it’s a negative proposition, that is I like the things that are missing from the experience of writing Elixir. I have a lightning fast application with twice as many features as usual written in half the time. But I haven’t thought once about the network (still haven’t written an HTTP request), nor thought about the operating system (still haven’t written any syscalls), nor have I thought about how to coordinate distributed services (clouds are now simply things outside my window).
4 Likes
That’s great! Thanks for sharing, @kokolegorille.
I believe a lot of these were very intentional design decisions back in the Erlang days. And some of these decisions are difficult.
They impose constraints on the developer, have performance implications etc, but they are all cohesive design decisions with the purpose of simplicity. (If you read Joe Armstrong’s papers, you’ll see how thoughtful the decisions are.)
For example think about which is simpler and why:
- Immutability to mutability
- Concurrency using processes (which run sequentially within a process) rather than threads/locks/semaphores
- Referential transparency where nearly everything is just data vs. pass by reference where
usera != userb
even if they have the same exact fields
1 Like
This and sequential mailboxes make reasoning about concurrency logical. It also gets rid of pretty much of 95% cases where you have racing conditions somewhere in your code.
3 Likes