Good pros and cons of Go language. There is some information around why Go and not say C++/Java/Ruby etc. The statement "I see Rails as the emperor with no clothes on" seems to be made in haste, since Rails is awesome for basic forms based apps.
I know a lot of friends of mine who have C/C++/PHP background struggle with rails at the start, primarily because of the magic of convention over configuration that happens (they aren't used to it). It takes a while to understand it. But once you understand it, it's a breeze.
Disclaimer: I am a Rails developer. My views are therefore biased.
In many ways the problems people have with RoR are the same problems people have with ORMs. They abstract away a lot of the clutter, but then, just as you become totally dependent on the abstraction, you find you need something that you can't get in the abstracted layer.
When this thing is a substantial increase in speed, sometimes you are totally f*ed, since to get it you need to toss away a lot of the detritus. For an ORM you can gradually phase away parts of it, but for a web framework generally you can't architect away the box into which your app is placed.
I'm unaware of any RoR that has successfully scaled, except by removing Ruby (Twitter). Github is probably the largest existing Rails app (at least that I use), and there are Unicorns aplenty (the new fail whale), or weird caching issues that seem to arise regularly.
I'm unaware of any RoR that has successfully scaled,
Ruby is slower and more resource intensive than some alternatives, but clearly it's possible to scale to large numbers of users and developers with RoR:
That's not to say that choosing an alternative or rewriting a particular service or website in something simpler/faster/cheaper isn't sometimes a better option, but I don't think you can claim convincingly that Rails is impossible to scale.
Apparently Shopify has quite a bit of Go on the backend. I don't know any specifics about the rationale, so I can't tell if this means anything WRT Rails.
I'm sure they all have multiple services running on different tech. Rails is clearly not the one solution for everything, and any website growing in scale is going to hit hurdles and end up rewriting some of their logic, whatever the language/framework used.
Github is unique in that the core logic is actually inside git itself - the real heavy lifting is handled in the git C code. RoR/github is just a pretty cover on top of that, which RoR does very nicely and why it manages to scale in that case.
I think that, as with any automagic framework that the edge cases become exponentially more difficult to implement. I'm very comfortable with MV* frameworks on client and server, and still not big on rails.
It's also likely that TFA's author was frustrated with performance under load, where Ruby (and Python) generally do not shine.
