Hacker News Reader

Comment by lox | Hacker News Reader

I posted this because I was interested to see if anyone else had experienced gaps in the golang `crypto/tls` library. The original author is pretty scathing about Go's implementation, but my impression thus far has been that it's an amazing quality part of the Go standard lib.

I'd take it any day over openssl, that is for sure. I wish the author had published methodology on the benchmark comparison, would be interesting to dissect that.

View on HN

From what I've seen in everyone's work is that Go's STD libs are amazing... for the the exact use case that Google has needed.

When you have to deviate from doing anything that Google/Pike would consider "acceptable" for what they would see as the "plebeian programmer" the STD libs aren't built for it. I'd not say it's a side effect of the language (not even the fact that it's lacking generics). I'd just say it's age. It's too young to be refined.

I'd say the std library is built exactly for the "plebian programmer" but such that it scales up well to larger use cases, pretty much exactly how the language itself is designed. I think how they've responded to vendoring package management is a great example of how they do take external feedback, but don't make knee jerk changes, and I really appreciate that.

Really not a big fan of some of Go's std libraries that come with heavy use of global states, baked into packages like http and flag.

I know one can use other functions in the same packages to create instances of HTTP servers or flag parsers. But the default approach coming as a part of the std libs will more or less make Go newbies to take it for granted as a programming idiom, which is not the best as the project grows

What tools does go provide to track down memory leaks like he experienced?

Yeah, and it sounds like a lot of his issues ended up being with cgo and openssl. If he'd used the standard lib, he might not have run into many of those issues.

Reply on news.ycombinator.com