Elixir VS C#

I know this is a couple months old, but I’m surprised no one mentioned “async” in this. This, for me, is the shining attribute of Elixir/Erlang. I’ve been mostly in the C# world for the past decade or so, and I’ve been writing multi-threaded code using BackgroundWorker, callbacks, and more recently async/await for a long time (in Delphi before that as well!). But in my eyes, those kinds of constructs and others, e.g. mutexes, semaphores, critical sections etc., are basically afterthoughts from the transition from single-threaded procedural paradigm to more and more multi-threaded one.

I am loving Elixir/Erlang because it doesn’t add asynchrony on top of something else…it IS asynchronous! And I am a hard-core OO dude that doesn’t hate FP stuff…I just didn’t grow up that route. But the most common issue that I’ve run into with FP is handling state. In even simple examples in most FP languages, state on a project-wide basis seems at best to be tricky to handle properly. Elixir has addressed this with Behaviors, and specifically the GenServer and Agent (which I believe is built on GenServer anyway). It’s like the best of both worlds…FP with superb, and natural state-handling capabilities. And asynchronous coding has become much more straight-forward, because it does these things (mostly) transparently - though you still need to be aware of race conditions and where the asynchrony is happening.

I’m not an Erlang expert, but I think the Beam+Actor Model architecture is the best for its asynchronous design. And Elixir (and its community) is adding to that awesomeness some really excellent options making it much more accessible to those of us from the OOP world.

2 Likes