[dv_says]

Formerly using Python, motivated to migrate to a modern stack, and so recently attempted to write a simple web back-end for my apps in Go and then in Elixir. Same logic, same unit tests, two languages.

Really liked: the simplicity of Go's build, not having to spawn N processes on the server side, the compiler catching so many issues, the very strict formatting rules, all a major win over Python. However, didn't like how verbose the code turned out, especially for parsing or any data manipulation tasks. For server-side debugging/tools, it's also a bit of a build-your-own adventure.

Elixir I found to be much more pleasant to write and subsequently read, more well-suited for back-end tasks, great for generating and parsing data. Also, more things in the toolset for back-end deployment, in large part due to the OTP stack.

Perhaps Go's ideal use case is local system tools, compilers, or anything else that requires concurrency (let's say, creating tools like "ls," or Apache bench, or gcc, or cURL), and something like Elixir is more ideal for building actual servers.

[gtaylor]

It sounded like they were gunning to shave the maximum in response time from their HTTP APIs. From my understanding, Elixir/Erlang probably wouldn't be able to match an optimized Go process in raw efficiency. I get the sense that scaling horizontally is the big draw of the Erlang VM, not so much raw responsiveness.

If simplicity were the primary concern, they could have stuck with Python. You do get a much more distributed element with Elixir/Erlang (which certainly helps with volume), but I'm not sure they'd reach that 10ms response time average with it.

[BuckRogers]

If latency were the primary concern nothing would beat the BEAM platform. It was built for that purpose, low latency is absolutely critical when you make a phone call.

Of course that's a bit like a benchmark (meaning, it means absolutely nothing to you/your code). If there were any more latency in the Erlang solution it would be the same algorithmic issues that could pop up in any software.

Go is more efficient for CPU throughput, but BEAM has been fine tuned for decades to keep latency down and wouldn't be able to top for responsiveness.

My personal opinion is that they made a mistake. Reporting about swapping out a stack like this is weird because it looks like they don't know what they're doing. What's next month's blog? We're Moving to Rust? I'm glad they're satisfied, but you gain improvements anytime you do a rewrite- even in the same language. I wouldn't have migrated my existing stack anywhere. I'd use PyPy which would've done wonders for responsiveness on the existing product and adopt containers for deployment.

[d23]

> I'd use PyPy which would've done wonders for responsiveness on the existing product and adopt containers for deployment.

That's an easy claim to make, but you don't know whether their stack would actually get much improvement out of PyPy. We've had trouble in the past using PyPy with C extensions. Trying to migrate to pure Python equivalents was a headache. Once we managed to get a PoC of a service running under PyPy, we saw very little improvement.

[BuckRogers]

It is an easy claim to make but just as easy for them to test as well, so it works out.

[nailer]

10ms HTTP response times in Phoenix (on elixir) is pretty normal.