<p>Which external packages you believe are so well-written, clean, battle-tested or otherwise awesome enough that you would like them to become part of the standard library in the future?</p>
<hr/>**评论：**<br/><br/>dchapes: <pre><p>The Go authors are doing the reverse, keeping new stuff out of the standard library unless there is a <em>very</em> good reason for it to be there. They put most new stuff in the <a href="https://golang.org/pkg/#subrepo">sub-repositories</a> (i.e. under <code>golang.org/x/...</code>).</p></pre>neoasterisk: <pre><p>I am very well aware of that but hey... what if? :)</p></pre>hybsuns: <pre><p>I won't suggest any of them. One of my favorite parts of Go is that it only provides essential tools that enable developers to build more customized and useful tools on top of them. Adding more packages to standard Go will only bloat it up and produces monstrosities. </p>
<p>Let me elaborate it a bit more here. I believe there are three kinds of packages in software framework: essentials, utilities, and preferences. Packages like fmt and os are essentials and is required by almost all development. Utilities like clients of paypal, Apple pay, twillio are useful only when you develop applications that need them. Preferences such as Gorilla, Gin, beego serve the same purpose in different ways. In my opinion, only essentials should be in Go's standard packages, while utilities and preferences should be developed and maintained individually.</p></pre>neoasterisk: <pre><p>I understand what you mean. I think there are trade offs. Having a package in the standard library gives it guaranteed stability which is a huge boon. An external package on the other hand has more flexibility and it can grow much easier. </p>
<p>Unfortunately unless there is a common interface in the standard library for people to build on, like you described, the community will keep building and building and keep the ecosystem fragmented (See loggers). </p>
<p>The line about what is essential and what not can be gray sometimes. Why exactly is a production level web server essential and why is it in the standard library? I also remember a thread where Brad was discussing bringing the Let's encrypt package in the standard library. Maybe those things are not essential but especially the web server and the rest of the strong standard library has played a major role into making Go a success. </p>
<p>In my opinion, if a package is so well-designed and mature that is pretty much "done" then it would benefit the community a lot by having it in the standard library. I understand of course that the more we add in the standard library the more burden we put in the shoulders of the Go authors. </p>
<p>But still I was looking for packages that are so tremendously good that they wouldn't add much burden for the Go authors and would enhance the standard library. Or maybe one of those packages get get in the standard library and some packages can get out in Go2. Or if nothing can be done then at least hypothetically speaking!</p></pre>connor4312: <pre><p><a href="https://github.com/pkg/errors">pkg/errors</a> is one package I use on nearly every project I work on--no more mysterious trace-less errors. Getting it into the standard library and wider use would be fantastic.</p>
<p>That said it does come up with a runtime overhead from capturing those stacktraces, but in most applications I work on the ease of debugging far outweighs the extra few CPU cycles.</p></pre>TheMerovius: <pre><p>I really dislike that package. It's born out of an unreasonable rejection of debug logging, it encourages useless error messages (It equates "helps telling the user what went wrong" with "barfing out a stack trace") and with the language as it is, it just fails if not <em>everyone</em> is using it (and thus violates the whole "errors are just values" idea).</p>
<p>I think it's a perfect example of something that seems reasonable and helpful at first glance, but just encourages bad design and bad code when looked at with some distance.</p></pre>DualRearWheels: <pre><p>Been using Go for years in high load production. Never had need for stack traces. Message is enough to pin point where problem originated, and possible causes were never obscure enough to require stack dumps. It was always either nil pointer or function returning error that should be handled correctly.</p>
<p>Maybe stack traces are invaluable when debugging shitty third party libs I always stay far away from.</p>
<p>Only "gremlins" I ever encountered were with CGO and using C libs that are not thread safe so you need to lock goroutine. But in that case stack traces are just random useless garbage as crashes happen randomly.</p></pre>Sythe2o0: <pre><p>This is apparently a pretty divisive topic, because someone (I suppose a java programmer) was telling me just last week that Go was garbage because it didn't bake in stack traces to all its errors but required a separate package to do so</p></pre>neoasterisk: <pre><p>For good or worse, it seems that "<a href="http://godoc.org/github.com/pkg/errors?importers" rel="nofollow">everyone</a>" is using it.</p>
<p>This is the first time I hear anyone say that it is not a good package. I was under the impression that everyone thought it's great and that it might even become part of the standard library.</p>
<p>In fact pkg/errors it is so popular that some other popular 3rd party packages are using it as a dependency despite them being libraries.</p></pre>TheMerovius: <pre><p>I think people should take a note from the standard toolchain and golang/x/tools. The tools produce helpful, direct error messages that do not rely on any wrapping or stack traces. Because the people who wrote them sat down and <em>handled</em> the errors they could handle and explain the ones they couldn't.</p>
<p>pkg/errors is certainly popular (though I haven't yet heard of anyone on the go team who gave any indication that it might end up in the stdlib. So far, I've only heard people express the opinion that it should). But I claim that this is because it makes the job of writing code easier - at the expense of <em>using</em> that code.</p>
<p>As a user, whether I'm using a software or whether I'm depending on a library, I don't ever want to have to read a stack trace to figure out what's wrong. I want an error message that tells me.</p></pre>neoasterisk: <pre><blockquote>
<p>As a user, whether I'm using a software or whether I'm depending on a library, I don't ever want to have to read a stack trace to figure out what's wrong. I want an error message that tells me.</p>
</blockquote>
<p>It seems pkg/errors is so popular and convenient that can be used <a href="https://github.com/gorilla/csrf/issues/69" rel="nofollow">by libraries</a> regardless if they provide help to the end user or not.</p>
<p>I think it is an unfortunate result for having a lack of guidance, opinions and articles about good error handling. Yeah sure we have the classic articles 'Errors are values' and 'error handling in Go' (which is now 6 years old!) and the occasional random error handling article but those can only get you so far. The look-at-the-standard-library argument doesn't help either as it is not helpful at all for beginners.</p>
<p>Right now if I do a Google search on my machine for "golang error" Cheney's package appears on top and surpasses the few good articles that teach proper error handling. Personally I've never used the package and I always try to good error handling myself. But I have to admit even after quite a few Go projects and me actively researching and trying to do proper error handling, I still have no idea what I am doing. I can't imagine how a beginner would feel. Where are the best practices? Where is the guidance? We have none. Just abstract advice hinting to an elegant solution that supposedly exists somewhere if we search hard enough. So no wonder Cheney's package is so popular.</p></pre>TheMerovius: <pre><blockquote>
<p>It seems pkg/errors is so popular and convenient that can be used by libraries regardless if they provide help to the end user or not.</p>
</blockquote>
<p>I don't understand why you are writing this. I already acknowledged that the package is popular. But programming is not a popularity contest.</p>
<blockquote>
<p>The look-at-the-standard-library argument doesn't help either as it is not helpful at all for beginners.</p>
</blockquote>
<p>Why not? The level of expertise doesn't seem to matter to me here. In general, the code of the stdlib and the tools by the go project itself seems, if anything, <em>better</em> suited for beginners, as it's of an above average quality (not saying it's perfect, though).</p>
<blockquote>
<p>Where are the best practices? Where is the guidance? We have none.</p>
</blockquote>
<p>The best practice is, to handle errors and to think about error messages. Don't write <code>return whatevs, err</code>, but think about what it means to have an error at this point and translate that into a meaningful message to the user. <code>fmt.Errorf("read failed: %v", err)</code> is not a meaningful error message, <code>fmt.Errorf("configuration file %v does not exist", cfg)</code> is. Yes, that will require writing some code to handle different error-conditions, which is the essence of the "errors are values" adage - error handling is code and to give useful errors, you are going to have to write some code.</p>
<p>Yes, that requires doing things like</p>
<pre><code>if os.IsNotExist(err) {
return errors.New("config file does not exist")
}
if os.IsPermission(err) {
return errors.New("config file is not readable for current user")
}
</code></pre>
<p>and it requires doing that on several layers of your program (it also requires adding generous amounts of debug logging, so that if there is an actual bug in your program, you can get at the additional context easily).
But that is, what error handling <em>is</em>. Error handling isn't the technical implementation of how to bubble them up the stack, it is looking at what went wrong and reacting to those conditions appropriately.</p>
<blockquote>
<p>Just abstract advice hinting to an elegant solution that supposedly exists somewhere if we search hard enough.</p>
</blockquote>
<p>The solution is not "elegant", but it is simple: Write code. The basic issue here is, that people want a magical system that absolves them of the responsibility to care about error handling, be it exceptions or Dave Chaney's error package. Something that they can just lazily and mechanically call into and have good error messages fall out the other end. But that simply does not exist.</p></pre>neoasterisk: <pre><p>I wonder if the author has made any attempt to bring it in the standard library.</p></pre>Mteigers: <pre><p>I thought Dave Cheney wrote that.</p></pre>neoasterisk: <pre><p>Yeah... so has Dave Cheney made any attempt to bring it in the standard library?</p></pre>pierrrre: <pre><p>+1</p></pre>sh41: <pre><p>Let me rephrase as:</p>
<p>"Which external packages you believe are so well-written, clean, battle-tested or otherwise awesome enough that you would like them to have their APIs irrevocably frozen and constrain their future development?"</p>
<p>None. I want fewer packages in std lib, more should be moved out to golang.org/x repos or so.</p>
<p>Basically, being in std lib benefits the discoverability and ubiquity of a package, at the extremely expensive cost of significantly constraining it. Being in std lib shouldn't be a desirable goal, it's just an unfortunate necessity sometimes.</p>
<p>Std lib is a great place to define base types that external packages can use to have a common interconnect. For example, things like <code>io.Writer</code>, <code>net.Conn</code>, <code>time.Time</code>, etc.</p></pre>neoasterisk: <pre><blockquote>
<p>Let me rephrase as:</p>
<p>"Which external packages you believe are so well-written, clean, battle-tested or otherwise awesome enough that you would like them to have their APIs irrevocably frozen and constrain their future development?"</p>
</blockquote>
<p>I understand what you mean. But I was thinking about packages that are so well-designed or have reached a certain level of maturity that are basically "done".</p></pre>flogic: <pre><p>Even in this light, I would still like to see pkg/errors added to the std lib. Go's Error interface is a bit on the anemic side. Often, there are 3 different things we care about when dealing with an error. There is the actual message itself that could bubble up to the end user "could not find file foo.txt" but that's kinda hard to work with inside the program. So we also want an easy method way to compare/identify errors in the program ie <code>err == FileNotFound</code>. And sometimes, we want to have extra info for the programmer such as stack traces. Go's std lib currently requires you to choose one between the first 2. There are ways of working around that but they're less than idea. <code>pkg/errors</code> seems like a tolerable way to solve that issue without making new code completely incompatible with the way current Go code works.</p></pre>readytoruple: <pre><p>netchan</p>
<p>Plz don't hate me Rob</p></pre>neoasterisk: <pre><p>I hope we get it at least in Go 2! :)</p></pre>TheMerovius: <pre><p>None. Pull stuff out of the stdlib into their own repos with their own release schedule and stability policy. Putting something in the standard library is making any kind of maintenance on it incredibly hard. My favorite example is <a href="http://godoc.org/plugin" rel="nofollow">plugin</a> -- buggy as hell, mostly pointless, only supported on a tiny subset of architectures, but it's in the stdlib now, so we're stuck with it <em>forever</em>.</p></pre>neoasterisk: <pre><p>Again I am not talking about garbage packages. Everyone has been saying that plugin was a big mistake that it ended up in the standard library. </p>
<p>No. I am talking about external 3rd party packages that have reached a certain level of maturity and have considered everything there is about design so now they are pretty much "done".</p></pre>PaluMacil: <pre><p>I don't know that the packages I use are perfectly battle tested, but I can't help but feel like NTLM auth (easier in 1.9 with the custom dialer), LDAP queries, and UUID types are things that should be in the standard library due to how common and critical they are to many codebases.</p></pre>neoasterisk: <pre><p>I agree! I was pretty surprised the standard library didn't offer anything about these!</p></pre>chmikes: <pre><p>There is a large number of web routers with many claiming to be fast, etc. I wished this router could get more attention. <a href="https://github.com/gowww/router" rel="nofollow">https://github.com/gowww/router</a>. </p>
<p>It's API is intuitive and straightforward. It is apparently faster than all other equivalent packages. </p></pre>forfunc: <pre><p>I'm sick of all those this is the fastest router claims. Most of the time it doesn't even matter because you are waiting on dB queries or whatever in your handlers. </p></pre>neoasterisk: <pre><p>I kinda wish the standard library router would become more powerful so that all the router fragmentation of the ecosystem would stop.</p></pre>
