Earlier quoted context omitted.
We haven't really ruled out any of the common stack tech choices. They are all good in their own ways, and have their own tradeoffs - and the intention here was not to spark wars about which tool is the best. I think the choice was much more of a proactive choice - we liked Go, we like the way it fitted us - good for fast iterative development upfront, good for the long term, fun to write code in and with a lot of ad…
>We haven't really ruled out any of the common stack tech choices. They are all good in their own ways, and have their own tradeoffs - and the intention here was not to spark wars about which tool is the best. This is way diplomatic. Though for me your article has no beef, the Pros and Cons of Go has been repeated here for so many times. I was expecting to see the v.s. stuffs, why this, why that, your thought process…
Picking on Rails/Node was not my goal and I feared that a stronger comparison between these choices would have been seen as such by the current startup community.
At the end of the day most of these choices are tools and I truly believe that while they have their trade-offs, they are all good from one point or another. The point I was trying to make is that Go is a tool worth looking into as an alternative to Rails/Node for early stage.
Unless you build the exact same product in Rails/Node/Go it's hard to make meaningful broad comparisons - and you end up comparing lab experiments around speed in specific toy examples, or end up comparing only certain isolated parts of the toolset.
We are planning on writing more blog posts about our experience using it, more into performance internals and how it all plays out - but I do feel that we'll stay away from comparisons.