[diath]

The BEAM is made with fault tolerance, scalability, and concurrency in mind at the cost of performance due to immutability and message passing approach among other things, which sounds like a terrible choice for a multiplayer video game that's anything more than a walking simulator. Erlang sounds like a good choice for auxiliary video game services, such as chat/social, guild management, auction house and so on, not so much for the game shard itself.

[DuLR10]

Given the current state of the game (the one we keep passing around between client and server), I don't think Erlang is a bottleneck in performance for us, and it won't be in the near future. Keep in mind this state is not that huge and it is yet not distributed, so it is totally possible that at some point Erlang will slow us down. I will keep your comment in mind, thank you!

Edit: currently with the game running at 60fps, there is no bottleneck from the server side. And we call it every 16ms! I should also mention that Erlang's choice has a learning purpose; we want to try to use the game as a way to learn more about OTP and the BEAM.

[toast0]

If it comes down to immutability and copies being a bottleneck, a solution is probably to move more of the core game state into native code (like with Zig), but fault tolerance, scalability, and concurrency seem like important things for a MMO.

Hot loading is pretty nice too.

[cmdrk]

it really depends on the game. people have been writing large-scale multiplayer games for over 25 years now, with MMOs sporting 2,000 player+ shards on significantly more primitive hardware. There is always this assertion that high-level languages of various flavors are too slow for games, but I suspect that today's hardware more than makes up for it for the right kind of game.