Go gives you nothing near to the stability guarantees that a properly built elixir application gives you. Supervision trees are totally rocking.

I can’t say anything about response time comparison in both, since those really depends on how well the application is crafted, not that much the language.

I can tell though that the go runtime stops the world for garbage collection, while the BEAM does garbage collection on a per process base.

Indeed, Elixir supervisors are awesome, but Go is getting much better, i think that in 1.11 it gonna be fully preemptive. In theory, Elixir should have a much better latency because the GC don’t stop the world, but, in pratice, Go has way better latency.

Take a look here.

An Elixir application will probably respond a lot better than a Go application when put under increased load.

Of course, what exactly happens in real life is something you can only find out by extensive benchmarking. I find the claim ‘in practice, Go has better latency’ very sketchy. It’s a nice benchmark that you linked to, but in real life, an application also performs some work besides immediately returning a response to a request. _{(Which this benchmark does not do)}

That said, Elixir is definitely better than Go when talking about:

• Stability. Even if Go becomes pre-emptive, it can by no means claim the same fault-tolerancy as Elixir does unless it will also start to work with the Actor Model. Also, Distributed Erlang (and the newer Swarm and Partisan) are absolutely amazing tools to manage multi-server scalability and fault tolerancy.
• Hot-code reloading. AFAIK, Go is compiled and does not allow you to do this. Especially when you might want to include streaming features in your API, this is the difference between all in-progress API requests being broken or being able to continue along.
• Stateful APIs. The ability to spin up GenServers that manage every need fo your user(s) in a specific context are conceptually really easy to understand, and are a lot faster than writing everything to a database in-between requests. This makes Elixir really well-suited for e.g. multiplayer games, communication platforms, etc.

I would add Inspectability to that list. The amount of tooling you have out of the box to inspect a single process is far beyond what Go can give you. For any one of those multiplayer game rooms, chat rooms, what have you, you can open up observer and see exactly what the internal state is, in order to debug it (or just for shits and giggles).

Go doesn’t have a way to refer to single threads via a general identifier, much less a non-intrusive (or any) way to see what the internal state of a thread is. To inspect the state of something, you’ll have to actually make that whole business yourself, which will just be another point of failure for you. observer will tell you exactly what’s there and how it relates to the other processes in the process tree.

There are already api gateways built in elixir. See GitHub - Accenture/reactive-interaction-gateway: Create low-latency, interactive user experiences for stateless microservices. · GitHub Introducing RIG – the Reactive Interaction Gateway https://www.youtube.com/watch?v=wNF51mmnsMo
I’m reading a bit about api gateways because my new customer works wit microservices and uses a gateway.