[dkarapetyan]

So many wrongs and confounding variables that I don't even know where to begin but I'll try anyway.

1) Ruby is a complex language: Ruby is quite simple. Everything is an object, every method call is a message send that follows the exact same protocol of dispatch. Also, completely irrelevant to the main thrust of the article.

2) Memory consumption and speed: Can't really refute anything since by their own admission they were running a monolithic system.

3) Concurrency: Plenty of options. I like celluloid personally and if you switch to JRuby then you can do all sorts of other stuff as well with automatically managed thread pools.

4) Backcompat: Ruby is not an enterprise ecosystem. Some people call that speed and agility. In their case they really should have gone with Java since they are basically serving an enterprise customer. This is not a knock on Java. I think the language and its ecosystem is by design made for stuff like this.

5) PDF generation: I'm guessing the Ruby code was calling some C library to do the rendering and they swapped out all of it for Go. I don't know what library Go is using to render PDFs if it is the same library then there is something interesting happening here. If it is a different library then they are comparing apples and oranges and there's nothing to see here.

6) Alert service: Completely bound by I/O so doesn't matter what language you use. Bad design for keeping many processes around because you only need to spin them up during spikey times which can be easily handled with better engineering. Also eventmachine and celluloid for the worker internals would have been another option so again they didn't do their research.

7) Gradebook service: No idea again. Thin on details so nothing to refute really.

8) Deployment: Sure. Why not. Single binary is easier or JRuby and a single jar which is just as easy.

In conclusion, they re-wrote everything and I'm sure removed a lot of cruft in the process and called it a victory for Go. In a year or so they're going to run into similar issues and Go is not going to save them because from what I read all I saw was bad engineers blaming their tools.

[patio11]

This comment is more aggressive than comments should be on HN.

I would exercise a bit of humility when commenting about other people's architectural decisions: they have bled all over that codebase and infrastructure, but I have not. They see it in their dreams, and I do not. They may from time to time decide to tell the community about their adventures. That is an excellent opportunity for me to learn from another engineering team's perspective and experiences, rather than an opportunity for me to demonstrate my intellectual superiority over them. They do not, as a function of having written about their experiences, owe me responses to my off-the-cuff analysis of their engineering tradeoffs.

[dkarapetyan]

In that case it's excellent story telling and nothing more. We're an engineering discipline and use case studies in engineering disciplines are measured by different standards, humility and hubris aside. You can bleed and dream about your architecture all you want but as a community we should be more analytical than that and not fall into the all the usual mental traps just because we bled for some engineering decisions. Teasing apart confounding variables and showing pros and cons of the various approaches and adding a bit more detail about the actual libraries would have made this a much better post. If he had provided all those details then some of us could have double checked the numbers with some benchmarks and learned from it but that opportunity was squandered.

Once again, I'm not aggressive but I am critical. nexneo has since addressed all the issues people have brought up and if he'd done that initially then I would have been much less critical.