[Okvivi]

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 advantages that come with the fact that it's a language designed today - with a lot of lessons learned from the past.

[cygwin98]

>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 and experiments. Right, those are the beefs I wanted from your article but didn't find.

>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 advantages that come with the fact that it's a language designed today - with a lot of lessons learned from the past.

This is not convincing though. As much as I admire Ken Thompson and Rob Pike, I tend to agree with the perspective that Go to C is like Plan9 to Unix. Of course, I could be wrong and am glad to be corrected by insightful comparisons and opinions.

[Okvivi]

I understand what you are saying, and indeed I am trying to be diplomatic.

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.