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.
