Elixir (and Erlang for that matter) handles concurrency in a really neat way - with single responsibility processes, aka the Actor model. Spawning multiple processes certainly isn’t exclusive to Elixir / Erlang, and neither is the Actor model, but the fact that it’s so easy (in my opinion) to communicate between these processes is unique.
However, the other language where it’s relatively easy (although not as easy as in Elixir) to communicate with processes that I’ve played around with is Go. Their concurrency primative is the goroutine, and you communicate between goroutines - or even back to your main process - via channels. The much ballyhoo’d idea behind it is the following:
“Don’t communicate by sharing state; share state by communicating”
I had never really put it together before, but this is basically the same pattern as Elixir! And from what I hear, Scala and Clojure have basically the same pattern for handling concurrency decently well. Is it possible that the programming world has actually come to a consensus on a good model for handling concurrency?
This is all kind of on the top of my mind after reading a great article this weekend in the journal Nature. The gist of the article can pretty much be summed up in the following chart:
Basically, we’ve stopped making processers actually faster because we can’t handle the heat that would be generated by so much electricity in such a small space (if you’ve ever burned the hell out of yourself changing a lightbulb, you’ll know this problem intimately), but we’ve skirted that issue by adding more cores to the processor.
But even this hack is about to hit its limit, which means that if we’re thinking of building software that stands the test of time, we can’t just throw more processing power at problems. We REALLY need to implement efficient algorithms and manage our resources carefully to get the performance that users expect out of modern day applications.
So, where does this leave my beloved Ruby? Well, unfortunately I’m not sure there’s going to be a real production use for Ruby in the future. The first strike against it is the fact that it’s an interpreted language, so it’s going to be an order of magnitude slower than compiled languages from the get go. But I think the real killer is going to be the lack of true concurrency support.
Or maybe MRI will go the way of the dinosaur and JRuby will be the future, since it at least gives us true threading. But threaded programs are host to a myriad of really gnarly bugs, and switching to a compiled language is most likely FAR more efficient in the long run than sticking with something like JRuby as it stands now. Unless Ruby adopts some really powerful concurrency primatives I’m not holding out hope for a bright, Ruby-tinged future.