[OvermindDL1]

Though, to be honest, most Erlang/Elixir devs would never think of using something like ZeroMQ as Erlang has more powerful and built in alternatives, or something like the Elixir Phoenix web framework that has built in much more powerful functionality. That seems to be an aspect of knowing the tools, easy to miss if you are new to the Erlang ecosystem. :-)

[SomeCallMeTim]

I beg to differ. ZeroMQ is fast and has bindings for most major languages [0]. So if you want to make native apps that speak over a very reliable channel, ZeroMQ is a great tool for interop. And its elliptic curve auth/encryption are super trivial to set up as well as being very fast, as opposed to getting https certificates pinned correctly on both the server and client.

Only if you only plan to ever speak to other Erlang/Elixir hosts would it make sense to use an Erlang/Elixir-only solution. And I will not even consider the option that writing a game (which is what I'm doing) in Erlang or Elixir is reasonable. Yes, it's possible, in a "Turing Machine" kind of way. But no, it's a terrible idea. Complex games don't break down into isolated functional chunks without actually making them much harder to design, maintain, and extend. I use plenty of functional concepts when I write games, where appropriate, but using a functional language would be a nightmare.

Phoenix is a web framework. "More powerful" functionality that I can't use for a particular project is a pretty profound waste.

Since I did actually abandon ZeroMQ for my game (when I decided that I needed to do most of the game as a web client anyway, and so I should just make the host app be built on TypeScript as well), I'm now using Socket.io, which surprise has an outdated port to Erlang [3] that doesn't support 1.0, and there's no native Elixir port. See a pattern emerging?

And since I mentioned speed was important: Kami, a Go-based web framework, benchmarks up to 4x faster than Phoenix. [1] Raw Go speed for the kind of thing I'd actually be doing is closer to 5x-10x that of Phoenix. [2]

By the way, it turns out there's an actively maintained Socket.io port on Go. And being able to spin up 1/8 the number of servers could realistically take my project from break-even to profitable.

[0] http://zeromq.org/bindings:_start

[1] https://www.techempower.com/benchmarks/#section=data-r13&hw=...

[2] Look at the fasthttp Go results on https://www.techempower.com/benchmarks/#section=data-r13&hw=... and https://www.techempower.com/benchmarks/#section=data-r13&hw=... -- my usage pattern would be somewhere between raw text and "single db" access, since my DB is Redis on localhost, so it's more like a cache than a Postgres/MYSQL lookup.

[3] https://github.com/yrashk/socket.io-erlang

[innocentoldguy]

ZeroMQ is needed by "most major languages," because most major languages suck at concurrency and interprocess communications. Node.js is crippled by its single-threaded nature, as are Python and Ruby; all of which are considered "major languages." Even languages that support concurrency, like Java and C#, are notoriously difficult to get right, due to issue with OOP and state.

Elixir and Erlang make writing concurrent applications easy, and they already have built-in mechanisms, which are better than ZeroMQ, for handling the type of communications that Node folks MUST turn to ZeroMQ to get. Using ZeroMQ in an Elixir application is like installing a gas tank into an electric car, just because they work so well in cars with combustion engines. Completely unnecessary.