<hr/>**评论：**<br/><br/>lstokeworth: <pre><p>Go 2 is <a href="http://www.thedynamiccommunicator.com/increase-meeting-productivity-the-idea-parking-lot/">an idea parking lot</a>. There are no plans to start development on Go 2.</p></pre>thockin: <pre><p>It does sort of kill me that basically any language changes are on hold until Go 2. But there are no plans for Go 2.</p></pre>dmikalova: <pre><p>What is missing? I see the developers are still very hard at work improving stability, performance, and tooling. What would Go 2 solve for you?</p></pre>iends: <pre><ul>
<li>Go path is super annoying. I have mix code projects and go path is pretty terrible</li>
<li>Lots of typing improvements. I would elaborate, but people would just downvote. =)</li>
<li>go get is lacking</li>
</ul></pre>dmikalova: <pre><ul>
<li>Go path is part of the compiler tools, not Go itself. For example Gb is another tool to build without Go path.</li>
<li>Go get is just a Go tool, so switching from Go 1 to 2 won't magically make it better. That also means it can be improved in Go 1.</li>
</ul></pre>lucsky75: <pre><blockquote>
<p>Go path is part of the compiler tools, not Go itself. For example Gb is another tool to build without Go path.</p>
</blockquote>
<p>GOPATH may be technically just part of the compiling tools but years of brainwashing from the Go team has made it an integral part of the whole ecosystem. Switching to GB (for example) also means giving up the entire set of additional tools that the ecosystem provides. So no, it's not JUST part of the compiling tools.</p></pre>iends: <pre><p>Technically go get could change, but based on rsc's response to the go dep tool, I doubt the core team is interested in making the user experience better for the public.</p>
<p>I'm pretty sure the core team has said they could not change the way go path worked in Go 1, but I don't have any source handy.</p></pre>dmikalova: <pre><p>Go dep is on the roadmap to being <a href="https://github.com/golang/dep/wiki/Roadmap">merged into the toolchain</a>. What did RSC say? The typical response I've seen is basically "we're not fundamentally opposed to this, but we're not going to add it unless someone shows a good proof of concept", which is also how they've dealt with generics.</p></pre>iends: <pre><p>That's the dep roadmap and not the go roadmap. I guess the summary can be found in this thread <a href="https://groups.google.com/forum/#!searchin/golang-nuts/go$20dep%7Csort:relevance/golang-nuts/PaGu2s9knao/9ZgwktG-BwAJ" rel="nofollow">https://groups.google.com/forum/#!searchin/golang-nuts/go$20dep%7Csort:relevance/golang-nuts/PaGu2s9knao/9ZgwktG-BwAJ</a></p>
<p>But they key quote for me is "You make it sound like dep is just going to become 'go dep' in Go 1.10. That's not the plan I thought we discussed." -- rsc</p></pre>sdboyer: <pre><p>Very, very, VERY important to read rsc's LATER reply in that thread: <a href="https://groups.google.com/d/msg/golang-nuts/PaGu2s9knao/_CWM9N_UBgAJ">https://groups.google.com/d/msg/golang-nuts/PaGu2s9knao/_CWM9N_UBgAJ</a></p>
<p>We're trying to land a 747 on a narrow sidewalk with dep - something of this scale is entirely new to the Go community, and we're necessarily having to figure some things out as we go along.</p>
<p>But there should be no question that things are moving forward, with "absorption" into the go toolchain being the goal. The reasons that's unlikely to be a simple direct merge have more to do with detail - like, the different things that become possible once dep is operating at a toolchain level - than any grand disagreement about direction.</p></pre>iends: <pre><p>Hi Sam, </p>
<p>Thanks for all your work on making the Go ecosystem more sane.</p>
<p>rsc's later response seemed orthogonal to his original response to me. How confident are you that Go 1.10 (Feb 2018) will include some form of dep?</p></pre>sdboyer: <pre><p>I'm enjoying it :D I'm just glad the effort seems to be taking root - I'm hardly the first community member to throw gobs of time at this problem.</p>
<blockquote>
<p>rsc's later response seemed orthogonal to his original response to me. </p>
</blockquote>
<p>I think it was intended to make clear that dep is fundamentally the path to the future, even though we still have substantial issues to figure out.</p>
<blockquote>
<p>How confident are you that Go 1.10 (Feb 2018) will include some form of dep?</p>
</blockquote>
<p>I can't really assert that with a lot of confidence, unfortunately; the best I can say is that we have a roadmap where we're <em>trying</em> for that, based on what we know right now.</p>
<p>I'd say the main unknowns are:</p>
<ol>
<li>Even if it were up to me to decide what "good enough" means for a toolchain release, I don't know the toolchain internals well enough to be able to even ballpark how much work is involved.</li>
<li>Conversely, rsc et. all probably don't yet know the internals of dep/gps well enough to be able to guesstimate the amount of work needed before it'd be toolchain-ready.</li>
<li>Even for the work we do know we'd likely want to do, it's not clear how much would <em>have</em> to ship with the first release of a new toolchain in order to avoid other failures or anticipatable backwards-incompatibility problems later on.</li>
<li>Plus, of course, all the normal, reasonable concerns one would have about any complex software as to whether it is sound, and operates well at scale.</li>
</ol>
<p>The roadmap's outlined goal of inclusion in 1.10 is based on an early-pass guess of how much work needs to be done that seemed...let's say, "not crazy." The best we can do right now is try to actively mitigate these unknowns as we go - build <code>dep</code> with an eye to what we understand to be the eventual toolchain requirements, not just its immediate needs as a standalone tool. But, to err on the side of safety, we are building dep with the idea that it'll need to exist and work well as a standalone tool for the next year or so.</p>
<p>So, the clearest promise I can give you is that, as soon as we think there's good reason to believe we'll miss 1.10, we'll update the roadmap and explain our thinking.</p></pre>dmikalova: <pre><p>Ah interesting, I wonder what the plan was.</p></pre>Manbeardo: <pre><p>IIRC, the vision is for it to integrate with go get. The end result should be nicer, but it puts their first deliverable much further away than the "add go dep" plan.</p></pre>sdboyer: <pre><p>The future relationship between dep and go get is not clear. I discussed the possibilities a bit over here: <a href="https://www.reddit.com/r/golang/comments/653mxc/dep_status_week_of_april_10/dg7dqh3/" rel="nofollow">https://www.reddit.com/r/golang/comments/653mxc/dep_status_week_of_april_10/dg7dqh3/</a></p></pre>slrz: <pre><p>Just merging dep into the go command as-is would yield a horrible result. They have totally different approaches to their user interface. People can experiment with dep but whatever gets into the go tool should follow its user interface conventions.</p></pre>rottenanon: <pre><blockquote>
<p>Lots of typing improvements. I would elaborate, but people would just downvote. =)</p>
</blockquote>
<p>Oh please do elaborate, I'd love to know.</p></pre>iends: <pre><p>Google it. Start with "golang sum types", "golang decimal type", etc.</p></pre>Vlir: <pre><p>Gen...</p></pre>iends: <pre><p>Yeah, <a href="https://hexdocs.pm/elixir/GenServer.html" rel="nofollow">https://hexdocs.pm/elixir/GenServer.html</a> is really cool.</p></pre>rottenanon: <pre><p>I think it's safe to assume you're going to say <em>generics</em>.</p></pre>throwlikepollock: <pre><p>In additon, my desires:</p>
<ul>
<li>Immutable types would be amazing. Ala-Rust.</li>
</ul></pre>andradei: <pre><p>Dude. Yes!</p></pre>tetroxid: <pre><blockquote>
<p>typing improvements</p>
</blockquote>
<p>lol<sup>no<sup>generics</sup></sup></p></pre>PaluMacil: <pre><p>I don't know if he was referring to generics. From another comment, I think he meant sum types and decimal types. I haven't taken the time to understand all the implications of sum types, and I haven't used Go for applications that do enough math for me to miss my decimal types from C#, so I don't pine for those things, but I'm sure I'll look into it eventually.</p>
<p>As for generics, I'm comfortable with Go's lack of them, and I enjoy the simplicity, but we certainly need to keep our mind open for a future where perhaps an elegant approach emerges to provide that feature.</p></pre>zsaleeba: <pre><p>Gawd yes. Go path is just awful for my mixed language projects.</p></pre>slrz: <pre><p>You're holding it wrong. It can work very well in multi-language projects if you try to embrace it.</p>
<p>For example, set GOPATH so that $GOPATH/src is whereever you keep your code. For most people, that's probably GOPATH=$HOME.</p>
<p>Put your project root at ~/src/myproject.example with subdirectories for its components A (written in ALGOL68), B (written in Bash) and G (written in Go). They key is to <em>not</em> recreate a whole new GOPATH within your project directory. That's just going to lead to pain.</p></pre>throwlikepollock: <pre><p>Out of curiosity, how do you import that project from another go project?</p>
<p>I assume in your example then tools like <code>go get</code> and possibly <code>dep</code> are unable to properly checkout/etc those projects?</p></pre>slrz: <pre><p><code>go get myproject.example/G</code> checks out the repo and installs the Go package G.</p>
<p>Leaving off the G also checks out the repo but then results in an error message that myproject.example is not a Go package. As it was cloned into your GOPATH, you can still build other packages importing <code>myproject.example/G</code>.</p></pre>kris-nova: <pre><p>Is there still frustration even after the $GOPATH assumptions made in 1.8?</p></pre>shovelpost: <pre><p>Not really. Just a loud minority. The majority of the gophers are silently and happily being productive.</p></pre>iends: <pre><p>This sounds a lot like Stockholm Syndrome. </p>
<p>But you can be happy and productive with go without liking all the warts. I'm certainly not going to stop using Go because of GOPATH, but that doesn't mean I have to be happy about it.</p></pre>shovelpost: <pre><p>Where you see a wart, the majority see simplicity and pragmatism.</p></pre>iends: <pre><p>Literally nobody, including the Go core team, is happy about GOPATH. They just prioritize maintainability over changing it.</p></pre>shovelpost: <pre><blockquote>
<p>Literally nobody, including the Go core team, is happy about GOPATH.</p>
</blockquote>
<p>Got any proof?</p></pre>lluad: <pre><p>I'm quite happy with it.</p>
<p>(But I understand that it's a path variable containing a prioritized list of directories, not a single filesystem path, though. If I didn't know that I'd probably hate it.)</p></pre>iends: <pre><p>Yes</p></pre>daveddev: <pre><p>Is there something about this that a soft link can't solve? It works for me in mixed projects.</p>
<p>Edit to add: The soft link should be set to target the directory within your GOPATH. The languages I work with have no problem with this, and I also ensure that the project structure is reasonable.</p></pre>thockin: <pre><p>Go explicitly does not support symlinks in GOPATH. Sometimes it works, sometimes it doesn't, depending on the tool.</p></pre>daveddev: <pre><p>Yep. I clarified how it would be setup specifically because of that fact.</p></pre>ryeguy: <pre><p>The answer to this is irrelevant. Soft linking shouldn't be necessary.</p></pre>daveddev: <pre><p>Until "shouldn't" becomes "isn't", wish in one hand. The point was that the issue is easily circumvented and not worthy of lamenting as insurmountable. It's a rather minor annoyance at most.</p></pre>ryeguy: <pre><p>Nobody is lamenting things as insurmountable. Just because there's a workaround doesn't mean that it can't be on a go 2 wishlist.</p>
<p>I also wouldn't consider it a rather minor annoyance. It's something that is in nearly every anti-go blogpost and has many different attempted community solutions to it. It clearly occupies a lot of mindshare.</p></pre>daveddev: <pre><p>Stating that GOPATH is awful is absolutely an overstatement and defeatist. Stating that it's odd to need to soft link a project to accommodate how one would prefer to arrange their file system is more accurate in tone and scale. I have no issue with distaste for GOPATH, but focusing one's attention on this issue so much and with obvious contempt says far more about the developer than the language.</p></pre>dmikalova: <pre><p>Have you tried out <a href="https://getgb.io/" rel="nofollow">Gb</a>?</p></pre>iends: <pre><p>Yes, like all of Dave's stuff, it's good, but there are still fundamental problems with versioning libraries.</p></pre>jnj1: <pre><p>Those things are not related to the language. They have nothing to do with Go 2.</p></pre>iends: <pre><p>Type improvements have nothing to do with the language? lol ok.</p></pre>jnj1: <pre><p>"Typing" sounds like the thing you do on your keyboard.</p></pre>iends: <pre><p>Oh, I guess since you're new to programming I would encourage you to google "static typing", "dynamic typing", and/or "type systems".</p>
<p>You'll learn a lot!</p></pre>thockin: <pre><p>There are a hundred things I'd like to see Go fix, about half of those are realistic and could plausibly be called compatible.</p></pre>gempir: <pre><p>What I want is something closer to node </p>
<p>Dependencies in a vendor folder and the folder itself can be anywhere on the system. Go get in the folder would update the vendor directory.</p>
<p>I dislike gopath a lot. It's awkward to cd, I don't even know how the syntax works if you are like a company with go and not on GitHub where does your code go? </p>
<p>src/git.company/company/myrepo ?</p>
<p>It's unclear, I just prefer the approach where you aren't reliant on the rest of the system in terms of dependencies.</p></pre>dmikalova: <pre><p>It's not unclear at all, Go get specifies the headers needed to make any page into a go gettable resource. It even supports SVN and Hg. And that URL is pretty much what I do with my work repos.</p>
<p>I personally like that I can identify the source of any import just based on the import path. And with tools like GoImports, it gets even better where on save my IDE will automatically add or remove imports.</p></pre>gempir: <pre><p>Ok, so what's the structure for my example? We are using bitbucket at work so the structure would be</p>
<p>(.company is a TLD only available in our network)</p>
<p>src/bitbucket.company/project/repo ?</p></pre>dmikalova: <pre><p>Yeah, mine specifically is:</p>
<p>src/bits.company.com/team/repo</p></pre>shovelpost: <pre><blockquote>
<p>I dislike gopath a lot. It's awkward to cd</p>
</blockquote>
<p><a href="https://www.reddit.com/r/golang/comments/5l282g/gcd_cd_in_gopath/dbsh6vk/" rel="nofollow">https://www.reddit.com/r/golang/comments/5l282g/gcd_cd_in_gopath/dbsh6vk/</a></p></pre>gempir: <pre><p>Yes I have done similar things, but I switch PCs a lot, or create a new testing VPS where I need go etc. It's something I will have to do everytime I setup the system.</p></pre>shovelpost: <pre><p>Then make it part of your configuration. There are countless tools that help applying configurations on new PCs or vms. Use one of those.</p></pre>gempir: <pre><p>Yes I know. Cd'ing into the thing isn't my only issue it's just an example.</p>
<p>Another one would be that my IDE (goglang) display the full path from the ~ home dir to my repo and with go that will always be very long, making it look bad in the IDE.</p>
<p>Another issue is when you want to open it in a GUI like sublime you will go through all the folders...</p>
<p>It's not something that I should need to fix with a symbolic link or environment variable.</p>
<p>It's not something that NEEDS to be fixed, I just feel I would prefer go without GOPATH, but that probably won't happen since it's a big part of Go.</p></pre>YEPHENAS: <pre><p>You're talking about tooling. Any of this can be changed without a Go 2.</p></pre>cdoxsey: <pre><blockquote>
<p>It's awkward to cd</p>
</blockquote>
<p>Have you looked at autojump (<a href="https://github.com/wting/autojump" rel="nofollow">https://github.com/wting/autojump</a>)? </p></pre>exch: <pre><p>Not ideal perhaps, but Go is an open source project. There is nothing stopping anyone from forking Go and adding all the goodies you want it to have.</p></pre>iends: <pre><p>This is counterproductive bullshit that people say when they have nothing good to say in respond to criticisms of open source projects.</p>
<p>There are actually an infinite number of things stopping people from contributing to open source or forking a project.</p></pre>exch: <pre><p>Only if you don't want to put in the effort.</p></pre>AluekomentajaArje: <pre><p>The effort of maintaining such a fork? Sure, but not many <em>organizations</em> on this planet have the resources to do that, much less an individual developer.</p></pre>dilap: <pre><p>Not concretely planned as far as I know.</p>
<p>If/when it does happen, I'll bet ya $20 that they'll also release a Go 1->2 transpiler that'll automatically update 99.9% of the code out there without problems, and everyone will be amazed by the smoothness of the upgrade.</p></pre>: <pre><p>[deleted]</p></pre>dilap: <pre><p>Hmm, maybe knock it down to 98%. (And hard to say without specifics, but it seems even if you added generics or something, some uses of reflect could still pretty easily be translated.)</p></pre>ca5h3vvs: <pre><p>They found that it is better than telling people to fuck off with their stupid ideas - they tried that in the past and it didn't work well.</p></pre>jiimji: <pre><p>lol, word.</p></pre>kris-nova: <pre><p>Despite there being no "official" plans (yet). This does make me raise an eyebrow or two. Call me crazy, but this seems like a good starting point for such a venture, and I am kind of surprised it hasn't seen more of a buzz around it. Especially because I think, the community would be pumped about a 2.0 something with the language. <a href="https://gophercon.com/speakers/11">https://gophercon.com/speakers/11</a></p></pre>ssimunic: <pre><p>Interesting find. On related topic, blog post by him few months ago: <a href="https://research.swtch.com/go2017" rel="nofollow">https://research.swtch.com/go2017</a></p></pre>iends: <pre><p>If that talk is anything but "Google knows best because we webscale and have more Go code than you will ever have so this is why X, Y, & Z won't work", then it'll be a win in my book.</p></pre>SSoreil: <pre><p>It might happen one day has been the message since we have been on Go 1. There is plenty of interesting work left for the Go maintainers as far as I can tell. I haven't seen much push for a Go 2 from people writing a lot of Go.
I wouldn't take a bet on us haviing a Go 2 in the next 5 years.
At this point I would be most interested in the option to have breaking changes in the standard library if there were to be a Go 2. The longer we wait for Go 2 the more stuff crops up which will start to irk people. It would be a shame if a Go 2 was rushed and then we needed a Go 3 and so on. It's great that I have had the chance to write in the same language for a few years without any worry about changes or features.</p></pre>dmikalova: <pre><p>I think the interesting thing with Go 2, like Go pre-1, is that they'll have the Go fix tool. Basically whenever there was a breaking change, which were a lot when it was beta, you could just run a tool that would do all the automatable changes and also tell you what parts it wasn't able to change itself.</p></pre>driusan: <pre><p>I think there have been signs that Go 2 will happen in the next 5 years. rsc's blog about his new years resolutions, various core team members self-filing proposals for Go2, (ie Rob Pike's proposal for variable size ints.)</p>
<p>I don't think they're in any rush, but 5 years? I'd take that bet.</p></pre>iends: <pre><p>The no breaking changes thing is super annoying. It means your handicapped by the teams knowledge when Go 1.0 was released.</p>
<p>If the Go team had a different release process they could let their users opt into changes they want, but they'd have to invest in better package management and versioning story, which Google doesn't' seem interested in.</p></pre>dmikalova: <pre><p>Breaking changes are even more annoying...</p></pre>iends: <pre><p>No, they are not. Languages change and evolve all the time. They do it carefully and in a controlled manner, but they do change. They fix their warts and make their users lives better.</p>
<p>Yes, it's not easy to get right all the time, but the Go solution of just doing nothing is suboptimal too.</p></pre>puffybunion: <pre><p>It might be annoying but it's definitely not without it's reasons.</p></pre>iends: <pre><p>Sure, lots of mistakes have good explanations. </p></pre>puffybunion: <pre><p>You have kind of a shitty attitude.</p></pre>iends: <pre><p>I'm sorry you feel that way.</p></pre>help_computar: <pre><p>A Go 2 announcement would have been an amazingly funny April fool's joke. </p></pre>chmikes: <pre><p>A move to Go 2.x would be costly for companies that accepted code developped in Go now. This could hit language adoption. The coexistance of 1.x and 2.x packages would be a pain to sort out. Go should have a mature package versionning and remote storage system to minimize the friction of the transition. </p>
<p>Even if there are things that could be enhanced in the langage, I would prefer we wait 10 years before this is considered.</p></pre>iends: <pre><p>The longer you wait, the more you increase your change of a python 2 -> 3 fiasco. You need a periodic cadence of breaking changes (once a year or once every two years) and compelling reasons to upgrade (features).</p>
<p>For example, combing the awesome GC improvements of the past few releases with a few small breaking changes would not impact adoption at all.</p></pre>chmikes: <pre><p>That's not wrong. The Go team introduced breaking changes to the language in the past. The evolution was apparently painless due to the tool for automatic conversion. </p></pre>carleeto: <pre><p>Go 2 was released on April 1. It added support for goto. </p></pre>note_bro: <pre><p>I think it's a joke, goto==go2</p></pre>iends: <pre><p>Go has goto statements in 1.x: <a href="https://golang.org/ref/spec#Goto_statements" rel="nofollow">https://golang.org/ref/spec#Goto_statements</a></p></pre>carleeto: <pre><p>note_bro gets it</p></pre>peterbourgon: <pre><p>No. At least, no real plans.</p></pre>des09: <pre><p>Java is 22 years old, and still at 1.x</p></pre>jiimji: <pre><p>and Java got generics in the mean time.</p></pre>Floooof: <pre><p>And backward-compatibility meant that Java generics were implemented with type erasure, restricting the power of the feature.</p></pre>geodel: <pre><p>Cool. So can I have simple thing like List/Vector of primitive types?</p></pre>: <pre><p>[deleted]</p></pre>geodel: <pre><p>It has slice to serve the same purpose. Please check the docs.</p></pre>iends: <pre><p>Versions number comparisons across projects are pointless, but thanks for playing. There have been a handful of breaking changes to the Java language still under the 1.x versioning scheme.</p></pre>des09: <pre><p>I get that the number of features in a release doesn't track between projects, but you missed my point. Java follows semver versioning, which means that you can expect no breaking changes in minor releases, and has held pretty well to that standard. I don't think it's pointless to point out that Java has not had a major breaking syntax change in almost two decades, it is one of the reasons it's the most overused enterprise development languages. </p></pre>iends: <pre><p>Have fun learning! <a href="https://stackoverflow.com/questions/16506411/was-there-ever-a-breaking-change-in-the-java-language-specification" rel="nofollow">https://stackoverflow.com/questions/16506411/was-there-ever-a-breaking-change-in-the-java-language-specification</a></p></pre>des09: <pre><p>What exactly is your point? Mine is that breaking change is expensive, and should be avoided where possible. Its a pretty simple concept. Do you not understand it? Or do you disagree with it?</p></pre>iends: <pre><p>You can claim to know best and never let your users get improvements to the language or you could give your users the power to decide when to opt into breaking language changes (with a better versioning story). </p>
<p>I prefer the latter. </p></pre>des09: <pre><p>Or you can deliver changes and improvements in a responsible way that does not force people to rewrite their code to continue to receive patches and updates. Java did this when adding generics support, and again to greatly improve it's functional programming idioms.</p>
<p>I don't think it's always the right thing to do, but maintaining compatibility should always be preferred over changing the language. Golang has impressed me so far by doing just that. I hope they continue to do so.</p>
<p>Personally, I can't think of a feature that should be added to Golang that would seem worth a breaking change to the spec, today. There might be some in the future, and I might be pretty narrow minded about this, but there you go, it's my opinion.</p></pre>driusan: <pre><p>It's been a long time since I used java (ie before the language even had generics). What do you mean by "greatly improve its functional programming idioms"?</p></pre>des09: <pre><p>Well, greatly may be stretching it a bit, lol, but java 1.7, and 1.8 have added functional interfaces that make the dog-ugly anonymous classes you may have used in the past much simpler to use and write, and a streams API that's quite expressive.</p></pre>iends: <pre><blockquote>
<p>Or you can deliver changes and improvements in a responsible way that does not force people to rewrite their code to continue to receive patches and updates.</p>
</blockquote>
<p>You can provide tooling to help identify problematic areas and still maintain previous versions for a sane period of time. Things like making error() an interface, etc could drastically improve the usability of the language for small changes to compatibility. </p>
<p>Of course Google isn't interested in this because they don't really care about the usability of the language over maintainability of their existing code, but a lot of these warts turn people off and they just end up using Java or C#.</p></pre>fortytw2: <pre><blockquote>
<p>Things like making error() an interface</p>
</blockquote>
<p><code>error</code> already is an interface type <a href="https://golang.org/pkg/builtin/#error" rel="nofollow">https://golang.org/pkg/builtin/#error</a></p>
<p>perhaps you mean something else? (I'm confused, at least)</p></pre>ssimunic: <pre><p>This hasn't been stated yet. However, you can see some of the change proposals for Go 2 <a href="https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue%20label%3AGo2%20" rel="nofollow">here</a>.</p></pre>iends: <pre><p>Things labeled "ponies" are also worth looking at too.</p>
<p>Edit: I guess the downvotes are from people not that familiar with the Go project, but here's a link <a href="https://github.com/golang/go/issues?utf8=%E2%9C%93&q=ponies" rel="nofollow">https://github.com/golang/go/issues?utf8=%E2%9C%93&q=ponies</a></p></pre>f2f: <pre><p>what are the ponies issues? "ponies list", as they are referred to in one of them. from a cursory glance it appears to be a list of not-impossible-to-implement issues...</p></pre>iends: <pre><p>It's a nice to have one day list that predates the Go 2 tag.</p></pre>threading: <pre><p>Well language is already proven to be webscale so I'm not sure what they can improve in that regard but I guess there are still rooms available for improving the GC.</p></pre>unimportant1234567: <pre><p>Three things I'd like to see:</p>
<p>Easier Type Conversions (for example:)
<a href="https://github.com/cstockton/go-conv" rel="nofollow">https://github.com/cstockton/go-conv</a></p>
<p>Multi-dimensional slices
<a href="https://github.com/golang/proposal/blob/master/design/6282-table-data.md" rel="nofollow">https://github.com/golang/proposal/blob/master/design/6282-table-data.md</a></p>
<p>Interfaces with properties (Why do interfaces not define properties / fields?)
<a href="https://groups.google.com/forum/#!searchin/golang-nuts/why$20do$20interfaces$20not$20describe$20properties%7Csort:date/golang-nuts/ZJ5DEv_36S8/ZgADJo061JkJ" rel="nofollow">https://groups.google.com/forum/#!searchin/golang-nuts/why$20do$20interfaces$20not$20describe$20properties%7Csort:date/golang-nuts/ZJ5DEv_36S8/ZgADJo061JkJ</a></p></pre>
