<p>And by this I mean "is the GO ecosystem" production ready?</p>
<p>The language is clearly there and already used by manny successfully in production. What I'm referring to is the libraries you will end up needing along the way that are not in the core. Are the most commonly used libs (db drivers, caching libs, etc.) mature and battle tested?</p>
<p>How do you know if something is production ready and that you can trust it? Let's say you need a database driver or some kind of library and you just find a random package on GitHub. How do people know/trust that that is safe to bet your project/production on?</p>
<p>What if you have the next great idea, and want to use Go for your startup, how can you know that eventually one of the libs you end up needing/using won't come back and bite you due to some bugs, the guy abandoning the project, etc. You're not a big company that can just pour money and time into fixing things or writing the lib yourself.</p>
<p>I'm just curious from this point of view how others feel, and how did you handled this?</p>
<hr/>**评论：**<br/><br/>dlsniper: <pre><p>Libraries in Go will more often than not be stable. Usually the authors seem to be embracing the stdblib path of not breaking BC unless something major.</p>
<p>There are numerous libraries about everything under the sun, you should have a look here: <a href="https://github.com/avelino/awesome-go" rel="nofollow">https://github.com/avelino/awesome-go</a> . </p>
<p>The main advantage of Go is that you can read the code quickly and have a rough idea of what a library does and if you should use it or not. There are all sorts of best practices developed around this from <a href="https://golang.org/doc/effective_go.html" rel="nofollow">https://golang.org/doc/effective_go.html</a> to <a href="https://github.com/golang/go/wiki/CodeReviewComments" rel="nofollow">https://github.com/golang/go/wiki/CodeReviewComments</a> to tools like <a href="https://github.com/alecthomas/gometalinter" rel="nofollow">https://github.com/alecthomas/gometalinter</a> that are being used in the CI tools to ensure quality. There's also a web project which helps with that: <a href="https://goreportcard.com/" rel="nofollow">https://goreportcard.com/</a> so you can quickly check a library against (but it doesn't support everything under the metalinter one).</p>
<p>I've wrote an entire startup code on Go from day 0 and everything was fine, we never had any problems with it. And by the number of Go users <a href="https://github.com/golang/go/wiki/GoUsers" rel="nofollow">https://github.com/golang/go/wiki/GoUsers</a> I think you should be safe.</p>
<p>Finally, I'd recommend you to join the Slack channel, <a href="https://gophers.slack.com" rel="nofollow">https://gophers.slack.com</a> (invite: <a href="http://invite.slack.golangbridge.org/" rel="nofollow">http://invite.slack.golangbridge.org/</a> ) and ask questions / get help from a bunch of gophers there.</p>
<p>Edit:
Despite having 4-5 years only of stable release, I think you'll find that contrary to many other languages out there articles written even before 1.0 was released still apply (for example: <a href="https://blog.golang.org/profiling-go-programs" rel="nofollow">https://blog.golang.org/profiling-go-programs</a> )</p>
<p>Also, 4-5 years and a stable language means that people can focus on building things that work rather than fight and keep up with language changes, and that's the biggest advantage of Go.</p></pre>CaffeineComa: <pre><p>I tried signing up to the Slack channel and got: "Error inviting you :-(". Maybe I'm a bot and I just don't know it?</p></pre>dlsniper: <pre><p>Nah, it recently got updated to: <a href="http://invite.slack.golangbridge.org" rel="nofollow">http://invite.slack.golangbridge.org</a></p></pre>drvd: <pre><p>How do you know which Java libraries are "production ready", how do you tell for Ruby or JavaScript packages? How do you mitigate the mentioned risks in C/C++, Java, Lua, Node, Ruby, Clojure, Haskell, Cobol or FORTRAN?</p></pre>BoTuLoX: <pre><p>Yes. Of course in some domains other languages can be better while Go will beat those languages in other domains.</p>
<p>It's a tradeoff you make when you pick any language. If you want a jack of all trades, master of absolutely none (except making tech-illiterate bureaucrats happy), pick Java and be done with it.</p>
<p>Go is used for writing bank infrastructure, runs a huge chunk of YouTube, services Uber's most demanding service, hosts dl.google.com and many other things big and small.</p>
<p>Worst case scenario you'll be using a bit of cgo.</p></pre>junajted: <pre><p>you inspect the library, how is written, how active is its development, does it have tests, what version it is (it's unwritten rule that libraries < v1.0 aren't production ready). if library gets abandoned and is widely used, someone else will take over or you can still fork the library and keep fixing bugs yourself.</p></pre>metamatic: <pre><p>Also, check the documentation. I find that documentation quality is a good indicator of code quality.</p></pre>interactiv_: <pre><p>The use cases are simple. If you expect something like JSF, JAX- ... then no, Go isn't mature for these kind of things. What would take a day or 2 to write with these will take you a month in Go, because you'll basically have to write the entire stack yourself.</p>
<p>If you're into discreet server components ( tiny web services ) , then Go will be useful. </p></pre>blueblank: <pre><p>If you need something not in the standard library, your best case is to do it yourself rather than bring in unwanted dependencies.</p></pre>Sythe2o0: <pre><p>In my experience, it's more likely I will find the libraries I want don't exist and I need to write them myself, or use bindings to C. </p></pre>RickAndMorty_forever: <pre><p>Because it's Go and not kids hacking around on npm in their spare time. You can characterize Go code as ruthlessly efficient and explicit. </p>
<p>Read the source code of the libraries you're interested in, there's literally no better way. </p></pre>tgulacsi: <pre><p>Take a look at gopkg.in - if sy took the effort to declare a version, that means stability is a goal.</p></pre>srbufi: <pre><p>It's only 5-6 years old? It's hard to get a mature ecosystem that amount of time from scratch. Safest bet is to use it for the use cases Google does.</p></pre>
