Happy Elixir user here. At work we have a use case that isn't covered by José's high-level overview of the domains Elixir's used in: we run a massive multiplayer game server on it.
This is actually a really good fit. (It kind of rhymes with the original use of Erlang, being telecoms infrastructure.) We get outstanding concurrency support, high reliability, and really efficient development times. I can't imagine shipping this feature with a server written in C++ (the language I'm most comfortable in), and I can't imagine scaling it the way we need to if we'd gone for a traditional web language like Node, PHP, etc.
If you're interested, you can see the RakNet (game networking protocol) implementation we use on the server here:
The README gives a good overview of the full MMO server's architecture, too: each client connection is a stateful Elixir process (not to be confused with a heavy-weight OS process!), acting asynchronously on a client state struct; clients then asynchronously schedule themselves to send updates back to the user.
It's not as ambitious as an MMO, but I like to use MUDs to learn new languages. I've been (slowly) working on one to learn Elixir and I'm actually finding the concurrency model somewhat difficult to use for the MUD - especially the single world that every player connects to.
But altogether my design feels fairly un-Elixir-like. It seems like the language would shine more in a problem space with more process isolation. When it comes to the game world, pretty much any process could potentially depend upon any other process. Especially once you get into scripting NPCs.
I took a look at ExVenture when I first started working on this. A lot seems to have changed since then, but from what I could tell at the time there were some potential races. For example, movement processing seemed like it allowed for the possibility of players to seemingly move through doors that were closed (at least, from the players' point of view). I could easily have been wrong though since I'm new to Elixir.
That said, a requirement for scripting I have is the ability to chain together arbitrary actions in an atomic fashion without any races or deadlocks. Content creators can create really complex scripts that involve arbitrary locations and actions. I wasn't sure how I would achieve this goal with ExVenture.
If concurrency doesn't help, you can always just not use it. You don't need to run logically separate modules in different processes.
What if you put the entire state in a single GenServer? You can still delegate modifying different parts of the state to different modules, just call functions in those modules from a single server process.
It does help. Any given action will modify a fairly small part of the overall state (at most around .01% of it). But what part of the state it can modify is fairly arbitrary based upon the action. Your dependency could be dataA, dataB, then dataC. Or dataC, dataV, then dataA. Which, if you isolate into processes could create races and/or deadlocks. They would be very unlikely, but they could still happen.
This is why I went with software transactional memory. In the generally unlikely event that there's some overlap, the changes will just be rolled back and re-done.
Yep! I was actually the sole dev working on it, both server- and client-side. I'm working on a post for our public dev blog talking about why I chose Elixir and what my experience has been. It'll eventually be available here:
This is actually a really good fit. (It kind of rhymes with the original use of Erlang, being telecoms infrastructure.) We get outstanding concurrency support, high reliability, and really efficient development times. I can't imagine shipping this feature with a server written in C++ (the language I'm most comfortable in), and I can't imagine scaling it the way we need to if we'd gone for a traditional web language like Node, PHP, etc.
If you're interested, you can see the RakNet (game networking protocol) implementation we use on the server here:
https://github.com/X-Plane/elixir-raknet
The README gives a good overview of the full MMO server's architecture, too: each client connection is a stateful Elixir process (not to be confused with a heavy-weight OS process!), acting asynchronously on a client state struct; clients then asynchronously schedule themselves to send updates back to the user.