"Google starting to kill off projects, would Go be on that list?"
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).
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.
Remember Unladen Swallow? It was open source. It had non-Google contributors. It was going to be the future of Python. Google was a heavy Python user and needed Unladen Swallow to succeed. It had a specific, ambitious goal. And then it just fizzled out because Google reassigned its people.
Will Go survive (and thrive) if Google pulled its support?
This is actually a pretty weak point for the language - that it is tied with personalities (no matter how great they are).
For instance, a contrary example would be - as a C++ engineer, I'm more than happy and think that it is one of the strongest point of C++ that it is not tied with Bjarne nor with any other company/personality.
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.
Perhaps if they had spent more than 15 minutes deciding on the language...
Your analysis omits the fact that Erlang and Haskell are mostly functional languages, which is different enough from what most programmers are comfortable with. This is typically a very large barrier to overcome.
Go 1.1 which will be out soon (maybe this month?) addresses a lot of these pain points to varying extents and is completely backwards compatible with 1.0.X code.
And then they had to write their own interface to OpenSSL, their own logging framework, their own ORM, their own HTTP server, and their own implementation of map. That seems like a lot of "non-value-added" stuff to have to reinvent.
We didn't write our own HTTP server, but rather a framework that sits on top of it and makes it easier to use.
The logging library is quite unlike anything else we're aware of, and the goals of it were language independent. The author of it is giving a talk about the library and our experiences with Go at GlueCon next month.
The ORM is the one which is more a result of what we wanted not being represented by existing libraries, and the community being still smaller compared to Node.
However, with all those still considered, we've gained a lot of velocity with Go, better concurrency without doing full async development, etc. Personally, I've hated testing async code in the past with both Node and EM+Ruby.
Our experience with Go at Braintree was similar. While the language is great, you still have to reinvent the wheel sometimes. For some companies this might make sense if they get a ton of value out of the language. We ultimately decided we could use Ruby for our purposes, so we switched.
I think the OpenSSL binding are really only necessary if you follow the train of though that, "its new so it must be broken". I prefer tests and evidence and I would not hesitate to use the Go cypto in many production scenarios. To distrust something with no evidence of being broken seems like magical thinking to me.
Go 1.1 includes a better map implementation, so if they were starting now that probably would not have been needed.
Most large systems always end up performing some customization to standard logging solutions as well.
The Go developer he's citing is probably Adam Langley, who is responsible for a good chunk of pkg/crypto and is also Chrome's TLS security person.
I started with Go some months back and ran into a compat issue with their SSL library almost immediately (it couldn't handle Firefox's goofy SSL compat dance in proxy mode).
Assuming that any new crypto implementation was safe sounds like magical thinking to me.
I would agree that OpenSSL is safer than using Go crypto. But I haven't seen any compelling evidence that it is any less secure than other non-Open SSL solutions. Like anything else, find a bug, report it/fix it.
That's because you're not looking for evidence. Just look at Langley's Twitter feed: Golang's SSL still has Lucky13 timing channels, and the RSA and elliptic/ECDSA code hasn't been assessed for side channels.
I like Go, a lot, but I think you should hold off on recommending crypto libraries ("I wouldn't hesitate to use this library in production"); that's something you want to be sure about before you develop opinions.
To be clear I said I thought the Go crypo was suitable for some production uses. The text you put it quotes was not anything I ever said. I would rather use OpenSSL for a banking app for example.
Since Go is >= version 1.0 and the crypo libraries in the standard library and not in go/exp, etc Go is implicitly endorsing them for some production use.
The text you put it quotes was not anything I ever said
Pretty close: He said "I wouldn't hesitate to use this library in production". You actually said "I would not hesitate to use the Go cypto in many production scenarios."
The timeframe referenced the length of the discussion of the two, not the knowledge the decision was based on. Several of us had previous experience with Node, and some of the team had prior Go experience.
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.
Am I missing some compelling advantage of block level scopes, or is it just a matter of taste/familiarity?
That's not how function-level scoping works in Javascript.
function p() {
if(false) var p = 10;
return p;
}
p(); // evaluates to undefined
What you'd get in a block-scoped language is some sort of ReferenceError; you still don't get 10 in JS, though. The variable is accessible outside of the block, but the block itself isn't executed. The above is just equivalent to the following transformation:
function p() {
var p;
if(false) p = 10;
return p;
}
p();
Aesthetic offense is a matter of taste. I prefer Scheme over C for aesthetic beauty, but many prefer the opposite.
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).
I have heard some security researchers are not pleased with Oracles security fix response time.
Other people feel the JVM is highly targeted. Or has more security bugs than it should. Or is too bloated for the limited services they use it for and could be smaller and this present a smaller target. etc
I'm not saying these concerns are necessarily valid, but I have had customers who had no JVM rules...
You are confusing the Java applet sandbox with the JVM. Serverside JVM applications don't try to safely execute arbitrary JVM opcodes from random Internet hosts.
"You are confusing the Java applet sandbox with the JVM"
I tried to be clear I was expressing common views customers and people I have interacted with have expressed, not my own. In the context of marketing, perception matters.
But I hope you are not saying the server side JVM has never has security bugs..
In the page 10 of presentation I saw "Callback Spaghetti" for NodeJs. I think he means "Callback Hell".
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.
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.
I'm not familiar with their product, is their back-end choice going to limit their customers?
I think that a lot of developers that didn't start with front-end work find Javascript disgusting, maybe this team is in that group. When I worked at a consulting firm (that used a lot of C#) and we talked about node.js when it came out, everyone agreed they hated the idea of having to write more yucky JS than they had too. I think node.js was high on hype for a while and is less loved (esp outside of CA) than you might expect.
I've ported node.js apps to Go 1.0.1 and even back then the result was better performing, used less memory, about the same LOC and IMHO much cleaner, straight-forward and maintainable code.
I disagree, Go is slightly more verbose, but it leads to very clear code that is easily understood. Go code is beautiful.
Javascript's dynamic typing, extensive use of callbacks, its approach to OO, inconsistent braces and semicolons, etc are all felt by a lot of people to be messy.
For me lack of something like gofmt and a compile time errors also greatly detract.
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.