The Selection of Go at Apcera(slideshare.net)
slideshare.net
The Selection of Go at Apcera
http://www.slideshare.net/derekcollison/go-conference-japan
51 comments
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?
Will Go survive (and thrive) if Google pulled its support?
Go is not some side-project started by a mid-level engineer. This is Rob Pike and Ken Thompson we're talking about. They're demi-gods, even at Google.
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.
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.
Agreed. If Google stopped working on Go, it would live on.
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...
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.
Also, I don't know if Erlang would have met their performance needs? http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
Also, I don't know if Erlang would have met their performance needs? http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
Erlang is faster than most people give it credit for. I imagine performance might also have made their bullet points, coming from Ruby: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
One thing that worried me was the slide with just this text on it:
Team selected Go in 15 minutes
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.
(I work at Apcera)
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.
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.
Any chance you'll release the ORM?
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.
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 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.
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.
I found closed issues that might be the ones you mentioned. If you are aware of issues, you should file them: http://code.google.com/p/go/issues/list?can=2&q=crypto&#...
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.
I found closed issues that might be the ones you mentioned. If you are aware of issues, you should file them: http://code.google.com/p/go/issues/list?can=2&q=crypto&#...
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."
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."
(I work at Apcera)
The "15 minutes" part was hyperbole.
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.
The "15 minutes" part was hyperbole.
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.
Probably just to hilight it's an easy decision, or one that is unanimously agreed by the team members.
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?
Am I missing some compelling advantage of block level scopes, or is it just a matter of taste/familiarity?
It's deeply aesthetically offensive, for one. It's error-prone, for two:
if False:
p = 1
print p
That's not how function-level scoping works in Javascript.
function p() {
if(false) var p = 10;
return p;
}
p(); // evaluates to undefined
function p() {
var p;
if(false) p = 10;
return p;
}
p();
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).
Many people, right or wrong, do not feel comfortable running the JVM for patent, ideological and/or security reasons.
Security reasons? What?
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...
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..
But I hope you are not saying the server side JVM has never has security bugs..
I see. I was not aware that this was the case. Thank you.
Looking at Choice Criteria slide one might ask: why not Erlang?
Enterprise ODM + logging etc. Any of that being open-sourceD?
(I work at Apcera)
Soon™
Soon™
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.
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.
|it's you that should manage this situation.
With Go, you don't need to worry about this.
The prediction that go will become the predominant language in IaaS and PaaS seems to be a stretch... python has a HUGE lead and is well entrenched.
On slide 15, he says of Stacks : "I spent 3+ months designing this in C in the 90s".
Anyone know what that means? Is he talking about segmented stacks?
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.
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 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 think they a lot of developers that didn't start with front-end work find Javascript disgusting, maybe this team is in that group.
I am not a Javascript fanboy, but the syntax of GoLang is not better either.
I am not a Javascript fanboy, but the syntax of GoLang is not better either.
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.
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.
Reading this at the top of the comments made me really sad.
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.