What we are discovering is that actually it doesn't sacrifice as much as you'd think - and I think that's the point we are trying to make with our article.
You get both the performance, and you get a very lightweight language - I'd say almost as easy to write as Ruby or Python - with great open source support and growing and with a great community around it.
Many modern languages in any field are almost as easy to write as Ruby or Python, have great open source support and a great community.
If you use Ruby or Python, you get extreme dynamism that makes things like ActiveRecord or dealing with external semi-structured data very easy (though you pay a performance cost).
If you use OCaml or Scala you get a lot of control over effects, making the code very safe and easy to reason about. And the type systems let you pull out high-level patterns in your code without going crazy, even when those patterns are very abstract, resulting in more concise and maintainable code.
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.
>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.
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.
We are building something awesome around mobile commerce, trying to connect the people who make products directly with the consumers who love them.
Our current stack is Go (all our backends are in Go), PostgreSQL, AngularJS and ObjectiveC and we picked them thoughtfully because they are the right tools that will help us move fast and build high quality products.
I was at Google for 5 years building the google finance charts, gmail's multiple inboxes, some maps infrastructure, and the like. My co-founder was at Fab for a little under a year.
We're looking for an iOS developer with a great sense of UX, that can both build the best iOS app out there and also help give valuable feedback on building some industry-leading world class UX.
I couldn't agree more. What I feel a lot of people are missing here is that Marissa's making Yahoo a place where good engineers want to work: where empowered smart people can make a difference in a scrappy way.
We are building something awesome around mobile commerce, trying to connect the people who make products directly with the consumers who love them.
Our current stack is Go (all our backends are in Go), PostgreSQL, AngularJS and ObjectiveC and we picked them thoughtfully because they are the right tools that will help us move fast and build high quality products.
I was at Google for 5 years building the google finance charts, gmail's multiple inboxes, some maps infrastructure, and the like. My co-founder was at Fab for a little under a year. We have a fantastic team - http://jellolabs.com/team - are seed funded, and growing quickly.
We're looking for an iOS developer with a great sense of UX, that can both build the best iOS app out there and also help give valuable feedback on building some industry-leading world class UX.
I also disagree with the "wear a suit" idea. After about a hundred interviews at Google, I've seen a pretty good inverse correlation between how dressed-to-impress a candidate is and their real performance in the interview.
The best engineers rarely give a shit about how they show up at an interview, and I don't really care if they wear a tie or a tshirt, as long as they are comfortable.
Maybe a good rule for presenters would be to imagine what happens if they replace the photo of girls in bikinis with a photo of guys in bikinis. If that makes the presentation awkward, then bikinis are not the answer.
Make it equal opportunity - scantily clad girls on left half of the slide and scantily clad guys on the right half. Then everyone's happy - straight girls, straight guys, gay girls, gay guys. Win-Win.
I think a lot of people think like you do, but wasn't that true when Facebook did this too? Weren't people upset for the exact very same reason?
And yet Facebook went ahead and did it, it pissed off a lot of people, and everybody got over it. Most users don't even realize that FB is not showing them everything anymore.
I really hope Twitter will do this, I think it would make their product so much more accessible and user friendly, if they manage to communicate it the right way and switch new users into it.
Nobody's stopping them from offering it as an option, like FB did.
FB doesn't really offer it as an option unless you go through and set everything to full feed for each person.
This sounds completely horrible, and I don't mean it as a nasty, but the active user base of Facebook seems to be distinctly less technical than the active user base of Twitter. I think that could lead to upsetting the active core at a gamble of attracting a couple of hundred thousand new users, who they won't really be making money off.
You get both the performance, and you get a very lightweight language - I'd say almost as easy to write as Ruby or Python - with great open source support and growing and with a great community around it.