This is similar to node.js, btw -- it is also not threaded.

This is why I roll my eyes when people in the wider tech industry get so excited about Node.js. They don't realise this is an ancient idea (in tech terms) and that they're just making the best of a bad situation rather than having invented something amazing. And they don't even have proper coroutines to work with, just callback soup.


maunovaha - Python is a great language, you just have to be aware of the pros and cons. There are applications and situations I would always choose it for, and some where it would be lower down the list. :)

Yea, and I can only say my own view regarding Node.js, and it is basically "ease of use". I come with a web development background, and I know js very well. Hence, single-threading as a concept (for me) is much easier to understand, than multi-threaded game server. I would love to take time to learn something like erlang (or elixir) later on and write game server using that, but at the same time I would like to find out what I can do with single-thread and non-blocking i/o as a game server. So, even if I am experimenting with Node.js for now, it won't stop me from experimenting with different tech in the future. I just need more time to study those things, as they are much harder to comprehend. For the same reason, I am not going to use UDP anytime soon. :)

Single-threading is always easier than multi-threading, because a whole class of design bugs (synchronization and race conditions) just doesn't exist.
The only draw-back of single-threading is that it doesn't make good use of existing hardware resources -- but if you're already using a dynamically tag-checked language, rather than a statically compiled language, that's probably not your main priority!

Regarding Elixir: I'm happy that it draws some attention to the Erlang ecosystem, but in my opinion, it's a solution to a problem that doesn't exist.
"Hey, let's take a functional language and pretend it looks like Ruby" is just not a good idea, except for a few initial days if you happen to already know Ruby.
Shortly thereafter, you will find that the syntax they provide (like re-assigning variable names) actually gets in the way, and causes potentially significant performance problems.
I would recommend just learning the Erlang syntax, if you want to live in that ecosystem.

Btw: If you want to build threaded, distributed, servers, the Erlang ecosystem helps a lot. It has tools for many of the harder things, like "leader election" or "distributed workers" or whatnot.
Also, the cost of learning a new language/syntax (with Erlang) is much smaller, long term, than the cost of learning to live in a distributed world. That's the real challenge!

Anyway: If max scalability and efficient hardware use isn't your top priority, and your project is small so dynamic type checking is okay, then Node.js is fine.

Good points hplus0603.

And now that we are talking about Erlang ecosystem (this discussion could be a subject of own topic really) but because I see Node.js disliked a lot in these forums ( :wink:), what potential alternatives - other than Erlang - there are for any serious network programmer? That said, I mean when scalability is truly needed as in MMORPGs? Hence, I know that many games never reach that point, but I just look for "best practises" and I am always interested to hear about those.

what potential alternatives - other than Erlang - there are for any serious network programmer?

You can write a scalable system in Node.js. Just look at eBay -- they rewrote their web page front-ends on Node.js.
It just takes more work. And, because it's not a statically checked language, you need more unit tests.

For distributed server projects for games with real-time components (simulation servers or similar,) I would personally look at the following:

- C++ -- you will never, ever, be blocked by some bug in some infrastructure, because you can always re-implement it yourself. Also, if you need to go "to the metal," there's no change in tools or build systems -- you're already there! Also, easily links whatever third party libraries you want.
- Java (ecosystem) -- whether you use Clojure, Java proper, or Scala, this is a suite of tools that a lot of people know how to run, and it's easy to find help here. It's a little more ghetto than C++, and a little less real-time (lots of Hadoop / Kafka / Spark type systems) but not to be ignored.
- C# (ecosystem) -- this wasn't on my list before, because mono is hilariously non-good for servers, but with the release of .NET Core open source, I'd love to take a look at that and see what it can do. C# is a more efficient language than Java by design, and Visual Studio is the world's best development environment.
- Erlang, as I said. It has some limitations and bugs, and you need to really learn and internalize the tools that come with it (OTP and the various distribution support libraries.) But excellent systems can be built.

I could conceivably talk about others. I love the Haskell web service infrastructure we have at work, but getting to that point was a lot of work -- there are less batteries included in that part of the world.
Python, Node, and Go are all possible, if the project is smaller. Neither is particularly good at threading, though, and neither is particularly fast; probably Node is fastest because it benefits from the massive optimizations in V8.
Perl, PHP, Ruby -- not really suitable for scalable, multiplayer, real-time game servers. I mean, you could, if you REALLY wanted to. But why would you?

Wow. Seeing it all in a single place makes it seem like ... there are a lot of languages and environments out there!

Well, that was an awesome overview :). And multiple options to choose from.. choices, choices! Hence, I have a strong background in Java, (minor in C#/C++ and many others) so I guess I am more close to writing distributed servers than I initially thought. Hence, somehow I just forgot Java along the way when I got interested in browser-based games (and went to work in a different company), and I read articles saying that it would be preferred if client/server shares the same codes regarding the game loop etc. And then I assumed that writing client/server using different language would be double the work and source for errors. But I guess you have done it before, because I bet you didn't write game client in Erlang either. :)

it would be preferred if client/server shares the same codes regarding the game loop

That's ... an oversimplification.

Is it twice the work if your web browser is written in a different language than your web server?
Well, no. Because there is a protocol in between, and the browser is written to the protocol, and the server is written to the protocol, and they match up (after sufficient amounts of debugging!)

Now, for certain things, it absolutely makes sense to try to re-use code. If you have a FPS, or some other game with heavy physics, using the same physics library makes life less unbearable.
If you have an RTS, or some other game with lockstep deterministic simulation based networking, you want not only the same code on both sides, but the same versions of the same compiler!
This all goes to "sharing the same gameplay code where it matters," which is a great goal. Where it matters!

If the rules of your game are simple (Poker, Chess, whatever,) and the main challenges are different in client versus server (client: presentation and UI; server: scalability) then re-coding the game rules in two languages isn't a big deal.
To make sure that your client and server can talk to each other, use some form of interface description language. This may be as simple as JSON schemas, or something like Protobuf or Thrift, or even heavy-as-lead stuff like SOAP.
Often, a simple script that can generate code to serialize to/from native structs/dicts/objects based on a well-define definition of a "packet" will be all you need. It keeps things in sync; when you change a
packet" (or PDU -- "protocol data unit") you re-run the script, and get the updated code to read/write that packet spit out for all important languages.
(For the Erlang/Python/PHP/JavaScript/C++ project, we used Google protobuf and I wrote a plug-in for protoc to generate Erlang.)

I bet you didn't write game client in Erlang either

Quite :-)

Ahh, I see. This stuff starts to make more sense now. Hence, only problem now is to find the time to experiment these in practise - and learn more in the process. Thank you! :cool: