Re:From Python to Go: migrating our entire API
by d23 on Thursday September 10, 2015 @07:47PM
(#10201241)
> 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.
Re:From Python to Go: migrating our entire API
by BuckRogers on Wednesday September 16, 2015 @10:25PM
(#10231224)
It is an easy claim to make but just as easy for them to test as well, so it works out.
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.