TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Open-Source Go Libraries

81 点作者 jtolds大约 11 年前

5 条评论

tptacek大约 11 年前
Adam Langley will disagree with me on this point, but if you were a client and put a choice of Golang crypto&#x2F;tls and OpenSSL in front of me, I&#x27;d professionally recommend crypto&#x2F;tls.<p>This doesn&#x27;t come up that much, because most production-scale deployments terminate TLS at a cluster of load balancers, so you don&#x27;t really get to choose which TLS library you use in prod. But if you have the option, I get warmer fuzzies from crypto&#x2F;tls than from native bindings to the scariest library in cryptography.<p>This could change in a year or so when the forks settle out, but I hope not, because crypto&#x2F;tls is a very nice piece of code.
评论 #7736737 未加载
评论 #7735428 未加载
chimeracoder大约 11 年前
&gt; While Go has very deliberately not implemented class hierarchies, a quick perusal of Go&#x27;s net and os packages should indicate that sometimes error hierarchies are useful.<p>I just want to point out - I would hesitate from drawing too many conclusions from &quot;net&quot; and &quot;os&quot; (the latter in particular). Not only is &quot;os&quot; some of the oldest Go code, but it is also designed to wrap conveniently around external interfaces that follow very different idioms.<p>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].<p>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.<p>[0] <a href="http://golang.org/pkg/os/#pkg-constants" rel="nofollow">http:&#x2F;&#x2F;golang.org&#x2F;pkg&#x2F;os&#x2F;#pkg-constants</a><p>[1] <a href="https://github.com/golang/lint/issues/32" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;lint&#x2F;issues&#x2F;32</a>
kbd大约 11 年前
In their errors library - <a href="http://godoc.org/github.com/SpaceMonkeyGo/errors" rel="nofollow">http:&#x2F;&#x2F;godoc.org&#x2F;github.com&#x2F;SpaceMonkeyGo&#x2F;errors</a> - they write:<p>&gt; It doesn&#x27;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&#x27;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.<p>I was thinking the other day that Go&#x27;s &quot;if err != nil { return err }&quot; is just the explicit version of what&#x27;s done implicitly with exceptions, except the &#x27;err&#x27; doesn&#x27;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?
评论 #7735973 未加载
评论 #7735938 未加载
评论 #7736567 未加载
评论 #7736073 未加载
tagrun大约 11 年前
&gt; Go TLS does not support hardware accelerated crypto.<p>Go uses AES-NI instructions on amd64 when available <a href="http://tip.golang.org/src/pkg/crypto/aes/asm_amd64.s" rel="nofollow">http:&#x2F;&#x2F;tip.golang.org&#x2F;src&#x2F;pkg&#x2F;crypto&#x2F;aes&#x2F;asm_amd64.s</a><p>&gt; 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).<p>LibreSSL people beg to differ about this &quot;feature&quot;.<p>&gt; Go TLS does not give much control over the certificate validation process, which makes it difficult or impossible to add additional checks and validations.<p>What exactly is this about?<p>&gt; Oh, and Go TLS is vulnerable to timing attacks.<p>A mitigation is in WIP <a href="https://codereview.appspot.com/94850043" rel="nofollow">https:&#x2F;&#x2F;codereview.appspot.com&#x2F;94850043</a>
评论 #7738534 未加载
Xorlev大约 11 年前
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.
评论 #7735381 未加载