Open-Source Go Libraries
Adam Langley will disagree with me on this point, but if you were a client and put a choice of Golang crypto/tls and OpenSSL in front of me, I'd professionally recommend crypto/tls.
This doesn't come up that much, because most production-scale deployments terminate TLS at a cluster of load balancers, so you don't really get to choose which TLS library you use in prod. But if you have the option, I get warmer fuzzies from crypto/tls than from native bindings to the scariest library in cryptography.
This could change in a year or so when the forks settle out, but I hope not, because crypto/tls is a very nice piece of code.
> While Go has very deliberately not implemented class hierarchies, a quick perusal of Go's net and os packages should indicate that sometimes error hierarchies are useful.
I just want to point out - I would hesitate from drawing too many conclusions from "net" and "os" (the latter in particular). Not only is "os" some of the oldest Go code, but it is also designed to wrap conveniently around external interfaces that follow very different idioms.
Another example would be the constant declarations[0], which use ALL_CAPS - this is actually not idiomatic in Go, but it is used here (a) because it was done very early on, and (b) because it more closely matches the C libraries it interfaces with[1].
I need to take a closer look at this errors package before drawing an opinion about the rest of it, but this sentence caught my attention.
In their errors library - http://godoc.org/github.com/SpaceMonkeyGo/errors - they write:
> It doesn't take long during Go development before you may find yourself wondering where an error came from. In other languages, as soon as an error is raised, a stack trace is captured and is displayed as part of the language's error handling. Go error types are simply basic values, and no such magic happens to tell you what line or what stack an error came from.
I was thinking the other day that Go's "if err != nil { return err }" is just the explicit version of what's done implicitly with exceptions, except the 'err' doesn't remember where it came from. This lack of information seems like a pretty big inconvenience. How do Go developers typically deal with this problem?
> Go TLS does not support hardware accelerated crypto.
Go uses AES-NI instructions on amd64 when available http://tip.golang.org/src/pkg/crypto/aes/asm_amd64.s
> Go TLS does not have wide support for backwards compatibility with less secure and older protocol versions (a good thing, until you have no other option).
LibreSSL people beg to differ about this "feature".
> Go TLS does not give much control over the certificate validation process, which makes it difficult or impossible to add additional checks and validations.
What exactly is this about?
> Oh, and Go TLS is vulnerable to timing attacks.
A mitigation is in WIP https://codereview.appspot.com/94850043
Nice set of libraries. I wonder if they looked at log4go before writing their own logger, and if so what drove them to do so.