<p>I kind of hope it does just because you can find almost any documentation or package for almost anything you want to do. </p>
<hr/>**评论：**<br/><br/>G0T0: <pre><p>For go to "explode" I think it needs to supplant Java on Android.</p></pre>FIuffyRabbit: <pre><p>No because go isn't a language used by the web browsers. </p></pre>MrNaviPacho: <pre><p>There is anyways GopherJS.</p></pre>dlsniper: <pre><p>The fact that Javascript exploded as it did has no meaningful relation with it being used in browsers. In fact it wouldn't be hard to imagine that Go could replace Javascript if someone would willingly put in the time to create a proper Go runtime for browser side. The problem would be the adoption rate among developers and browsers (Firefox and Edge would need to ship with the same runtime)</p></pre>leimy: <pre><p>no</p></pre>BrianWilliamDouglas: <pre><p>Web assembly has basically hailed Javascript as the king. </p>
<p>For Go to get anywhere near that status it would need to dethrone Java on Android. Which is something that could well happen.</p></pre>nanodano: <pre><p>Over time, I think Go will take the place of C++.</p></pre>Gacnt: <pre><p>If say this was to happen, would games become natively cross platform or would there still be a bunch of stuff to stop that</p></pre>FIuffyRabbit: <pre><p>Games are already pretty much natively cross-platform (assuming DirectX isn't used). It is just the designer's choice to not do it. </p></pre>nanodano: <pre><p>Well, as of right now there are no pure Go implementations for graphics that I know of. There are bindings to SDL though. Since SDL is cross platform theoretically you could use SDL + Go on all platforms. It would require setting up and compiling the SDL dependency but maybe one day we will see something like SDL completely written in Go.</p></pre>anacrolix: <pre><p>No, C++ still has a lot to offer. It's well established that Go is supplanting Python, and Ruby, but it won't replace either.</p></pre>MrSaints: <pre><p>I'm assuming that you aren't referring to JS broadly, but rather NodeJS. Regardless, I don't think that a <em>fair</em> comparison can be made.</p>
<p>You seem to be making one on the grounds of its community (i.e. plenty of well-documented packages for any needs). If that's the case, I think you just validated your own question.</p></pre>google_you: <pre><p>Will Go enable incompetent monkeys survive in the industry like Javascript did?
Hope not.</p></pre>grued: <pre><p>In essence, JS was the only language for a platform that exploded. I don't see that opportunity for go. </p>
<p>It could become a dominant domain language, but still has an uphill battle considering some well discussed weaknesses, like lack of adequate generic support.</p></pre>caseynashvegas: <pre><p>Firstly, Go will never be ubiquitous in the way that JavaScript is because JavaScript will remain the king of the browser. </p>
<p>Will it explode like Node.js did? I hope so, but we are missing one key thing that I believe was the single greatest reason for Node.js's rise, NPM. Beyond all the other reasons, having a decent, working package and dependency management program makes Node.js development productive and helps drive the community. It is hard to find packages, it isn't hard to install them and get going. This is where Go fails in comparison. </p>
<p>tl;dr; We need a package manager!</p></pre>caseynashvegas: <pre><p>Wow -2? Why the down votes? </p></pre>kjk: <pre><p>Maybe because there are plenty of npm equivalents in Go, <a href="https://github.com/tools/godep" rel="nofollow">https://github.com/tools/godep</a> being the most popular.</p>
<p>Go has the best package management out there (go get, unlike all other package managements, doesn't require central repository and additional complexity of packaging your code and publishing it to such repository).</p>
<p>There are plenty of solutions for dependency management that are just as easy to use as npm (including godep) and go 1.5 introduced experimental support for vendoring directly go tools (<a href="https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJwkfpx90cqG9AFL0JAYo/edit" rel="nofollow">https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJwkfpx90cqG9AFL0JAYo/edit</a>), so this will become better in the future.</p></pre>caseynashvegas: <pre><p>I don't think we can compare npm and godep. When I search for a package in Node.js the first thing I'm told to do is "run npm install [package]". It's not that way for Go.<br/>
Godep might be nearly functional the same or maybe better but it isn't even mentioned in the official golang site. And your lack of a need for a central repository could be viewed as a negative.</p></pre>Gacnt: <pre><p>Don't feel bad, I don't think I've ever had a successful post on this subreddit, I think everybody's just upset at the lack of a package manager </p></pre>calebdoxsey: <pre><p>Installing packages in go is trivial. <code>go get whatever</code>.</p>
<p>Finding them is also not hard. Use godoc.org, go-search.org or just google it.</p>
<p>NPM is no better at answering the question "which package should I use?" or "can I trust this package?".</p>
<p>The lack of versioning is an issue for large-scale projects, but it doesn't really impact new developers. (pulling the latest version usually works)</p>
<p>Pegging versions doesn't make dependency management issues go away either. It's all to easy to introduce mutually incompatible versions of code from separate libraries, end up with orphaned libraries, or stale libraries with security vulnerabilities, or be forced into a corner when upgrading to a new version for some feature you absolutely have to have.</p>
<p>NPM is as good as any tool, but it to has its own set of problems. For one building platform agnostic C++ bindings is a real chore (and many of the things people use Go for would require such bindings) and for another everything in the Node community seems to have a 6 month shelf life before it's replaced with something else. </p>
<p>I mean how many Javascript build systems are we up to by now?</p>
<p>If that's what "driving the community" leads too, maybe we're better off for it.</p></pre>caseynashvegas: <pre><p>You make some good points, I appreciate the discussion.</p></pre>mnjagadeesh: <pre><p>I wish Go to explode like that</p></pre>pkieltyka: <pre><p>yes.</p></pre>jmking: <pre><p>Nah. One of the main reasons JS continues to permeate the server is the ability to share code between the client and server. Especially as frameworks that leverage that fact, like React or Meteor, continue to grow in popularity, this trend is going to continue.</p>
<p>The ability to deliver a pre-rendered version of a certain "screen" of your single-page JS client application on the server in response to a specific URL and then have client-side JS pick up the ball from there without redundant code is a capability exclusive to JS. In addition, if your application has any real time component, JS becomes even more attractive. In light of that, JS is primarily a threat to Ruby/Python/PHP if the application in question is a SPA.</p>
<p>That said, there's more to the web than serving http requests. There's lots of room for Go in most non-trivial application stacks (even alongside JS). Go also has a bunch of overlap with JS on the server (especially in being great for real time applications). Applications that start in JS may eventually break out certain components and off-load them to Go equivalents.</p>
<p>TL;DR - No because only JS runs in a browser.</p>
<p>Edit: I know you guys don't like JS on the server, but nothing I've said is untrue.</p></pre>ecmdome: <pre><p>I really dislike going back to sharing serverside and clientside code like PHP did at one point.</p>
<p>Its one of the reasons React wasn't attractive to me. It feels like snippets within html.</p>
<p>I really love the complete separation of powers.... frontend library, backend service.</p></pre>jmking: <pre><p>I don't mean mixing HTML and JS together.</p>
<p>I mean, for example, having a validation class written in JS that can validate user input on both the client and the server. You only have to write that logic once.</p>
<p>Whereas in any other traditional pairing (Go/Ruby/Python/etc) you have to re-write that validation logic in the server-side language. Your validation logic may then vary between what the JS code does and what your server-side code does. This makes maintenance a pain as you end up having to implement business logic twice in two different languages.</p>
<p>Modern front-end application development is heavily done in JS - where the HTML output is generated out of JS code. Since the JS code can generate the complete HTML output on the client, the same could be done on the server as well - this makes it easier for, say, search engines to get pre-rendered HTML from the server when it spiders a site or application while also giving users a faster/more responsive interface by only loading in the content that changes per click.</p>
<p>This sort of thing is technically still possible with a backend not written in JS, but it's also a lot more complicated, and there's a lot of redundant code.</p></pre>
