- They did not say why they did not choose one of the other alternatives.
- They did not say how they used the concurrent features of Go, only mentioned that they were there.
- They did not say how long it took to rewrite.
- They did not say what they changed in the API.
I'm not saying the story isn't true, but for a true story it lacks a lot. You could summarize the article with the title and you won't be missing much.
They didn't say why Ruby was using a lot of CPU either. Some basic investigation into the root cause might've revealed some intractable problems that are tied to Ruby (or at least the MRI interpreter) like long GC pauses (something which can be mitigated by going to a different interpreter like JRuby versus a complete rewrite in a different language)
Instead, it's "OMG we're maxing out CPU, time to completely rewrite our app in a different language"
And how big is this app that it needs 30 servers? We probably serve an order of magnitude of traffic where I work than these guys do (just guessing) and don't need that many.
Could you elaborate on this please? Are you referring to the OP's motives of publishing the article? Or of switching to Go?
> Go and Rails are so different that there is almost no point in comparing them.
Except when one solves the same problem better than the other.