<p><pre><code> "Google starting to kill off projects, would Go be on that list?"
</code></pre>
Key difference here, unlike Reader, golang is fully open source. So even if they did (which is unlikely because it is good and used by Google itself), it could survive that and still thrive. I feel it's got enough critical momentum even at this point (and even more so in the future).<p>This is one of the main reasons why I believe in its future and feel passionate about it. They started off right by making it open source. I would have very mixed feelings if it were closed.
Were Node.js and Go the only two choices considered? Erlang, Haskell, etc seem like they would fit the choice criteria, save for dependency management which is generally handled externally via rebar or such. Works pretty well though. Moreover, Erlang has solutions for the listed pain points of Go -- an excellent scheduler, fast GC thanks to per-process stacks, mature libraries including HTTP, crypto, etc.<p>Perhaps if they had spent more than 15 minutes deciding on the language...
One thing that worried me was the slide with just this text on it:<p><pre><code> Team selected Go in 15 minutes
</code></pre>
Is that really long enough to make a decision? I'm not saying it was necessarily the wrong decision. Just that 15 minutes isn't a whole lot of time.
I'm using Go at my new startup. I've only been working with it for a couple of weeks but I'm loving it so far. They just got so many things _right_ with this language.
This is really a minor point, but lots of people seem to hate function level scoping, including these guys. Having started out in languages with function level scoping, and only later used block level scoping, the former strikes me as the most ordinary thing in the world.<p>Am I missing some compelling advantage of block level scopes, or is it just a matter of taste/familiarity?
I'm curious why Java isn't customer neutral. Clojure (and Scala) both seem to be more mature, and concurrency is a core part of clojure (with a rich ecosystem and runtime in the JVM).
In the page 10 of presentation I saw "Callback Spaghetti" for NodeJs. I think he means "Callback Hell".<p>There's several good approaches that helps you to manage and write better JavaScript codes (even NodeJs) to prevent callback hell problem, it's not a problem of NodeJs or JavaScript, it's you that should manage this situation.
On slide 15, he says of Stacks : "I spent 3+ months designing this in C in the 90s".<p>Anyone know what that means? Is he talking about segmented stacks?
As a cloud platform startup, I'm kind of surprised they didn't just go with NodeJS due to it's huge popularity advantage meaning they'd have many more customers. Even investors are asking for it nowadays. If you are writing internal software for your own company, OK, pick what you want. But if you are building a cloud platform that will presumably have customers with their own wants/needs/demands/codebases, I think they would have been better off with a platform written in the same language and engineers steeped in the same language as everyone wants right now.