What do you want Go to focus it's efforts on and gain traction at?

<p>It can be the immediate or long term future. I&#39;ll start: I would love to someday see Go replace Java for android development. With the Oracle lawsuit there may be some incentive for Google to move away from Java and support Go 100% natively. It&#39;s not that crazy considering that&#39;s what Apple did with Swift. </p> <hr/>**评论：**<br/><br/>ericanderton: <pre><p>Short Term:</p> <ul> <li><p>&#34;Garbage Collection&#34; on goroutines. Specifically, goroutines that are blocked on the only remaining reference to a given channel should be quietly destroyed since they can&#39;t possibly do anything but soak up memory. It&#39;s kind of a corner-case, but it&#39;s also a pattern that isn&#39;t guarded against in the language design. It&#39;s also insanely easy to do without realizing it. (Edit: I&#39;m more than happy to be wrong here, but I&#39;m pretty sure this is an issue today)</p></li> <li><p>Semantic Version aware &#39;go get&#39;, with all that implies (pinning, locking, vendoring, combing git tags for versions, etc). I myself have a Package Manager implementation for Go that does this. Everyone does. I think we&#39;re up to at least a half-dozen different takes on the problem at this point. The community has functioned well as a laboratory on this one, and it&#39;s well past time to move the best features into the mothership.</p></li> </ul> <p>Long Term:</p> <ul> <li>A better story for re-tooling. A place where Go faces substantial friction for adoption is how to convince people that it&#39;s the right tool for jobs that are presently satisfied by other technologies. Also: many shops are just plain terrified of managing a polyglot. In any case, the current rhetoric doesn&#39;t always cut it. We&#39;re moving into an era where shops have <em>deep</em> investment into Python, Java, .NET, Ruby, etc... Unless you&#39;re at a startup, or your CTO is willing to take risks, it&#39;s tough to get Go on board. Being able to talk to long-term gains and benefits with solid examples will help tremendously here. Outrunning Go&#39;s identity as something &#34;new&#34; will be another.</li> </ul></pre>peterbourgon: <pre><p>I like your first short-term idea. Your second idea is being addressed in Go 1.5 by first-order support for vendoring, and I guess will continue to evolve from there.</p> <p>re: your last point, I&#39;m hoping to push on this with <a href="http://gokit.io">http://gokit.io</a>. If you have any thoughts to contribute there, I&#39;d love to hear them.</p></pre>ericanderton: <pre><p>As for vendoring, it&#39;s a solid first step, but it&#39;s not complete enough for my taste. That said, the proposed recursive <code>vendor/</code> directories come with some insidious corner-cases. Consider that NPM turned away from this approach for the most part in the recent V3 release. Everyone else avoids it, and not for any lack of technical prowess either. So, I&#39;m not at all satisfied with the status quo, or the charted direction.</p> <p>I like the idea behind gokit.io. I&#39;ll give it a look. :)</p></pre>TheMerovius: <pre><p>+1 for your Garbage collection on goroutines. I don&#39;t think it really can be added to the language as a guarantee, but it would be super-usefull. e.g. concurrent iterators are much harder to write than need be: With garbage collected goroutines you can just return a channel and spawn a goroutine to write to it. Today you need to add a bunch of boilerplate to support cancellation and get a less &#34;neat&#34; API.</p> <p>-1 on the semantic versioning thing, unless you can do it lightweight (e.g. using git-tags) and have tooling to check, that you don&#39;t break anything (which is insanely hard to impossible for the general case).</p></pre>ericanderton: <pre><blockquote> <p>unless you can do it lightweight </p> </blockquote> <p>I can forsee a future where the lightweight <code>go get</code> we enjoy today will continue support the majority of cases. For people like myself that want the heavyweight dependency wrangling stuff, I think <code>go vendor</code> or somesuch could be used to handle the rest if a distinct looking workflow is desired.</p> <p>Edit: a lot of tools today use tags/branch names to handle version name/number metadata. Seems like a good approach to me.</p></pre>SupersonicSpitfire: <pre><p>Making it easy to write mobile applications that use the native widgets, that work well on both Android and iOS. Use an interface designer that has a design per platform, if need be.</p></pre>