<p>There seems to be <a href="https://groups.google.com/forum/#!topic/golang-dev/hOxZCX7navI">an upcoming AMA</a> for the 1.6 release, soon™. Just wanted to post this so people can prepare their questions beforehand, if they want to.</p>
<hr/>**评论：**<br/><br/>stupidworkalt: <pre><p>I wonder what percentage of the posted questions will be related to generics...</p></pre>abcded1234234: <pre><p>Everything you want to know about generics in Go: <a href="https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit">https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit</a></p></pre>iends: <pre><p>Generics will continually be a topic of discussion until the core team completely shuts the door on them and/or shuts the door on Go 2. Right now the message is 1) no language changes in 1.x 2) generics seem nice, but they complicate the language/compiler/etc and might not really be that useful. </p>
<p>This give a lot of hope that a Go 2 will happen that has generics and fixes some of the warts. Since the Go release numbers are getting larger, people pretend that Go 2 could happen in the next two years.</p></pre>enneff: <pre><blockquote>
<p>Go 2 could happen in the next two years.</p>
</blockquote>
<p>Definitely not.</p></pre>thomasfr: <pre><p>Isnt the message that there will be no backwards incompatible language changes in 1.x and more generally that language changes usually shouldn't happen because it's a core design principle to have a simple language?</p></pre>iends: <pre><p>In more words, sure.</p></pre>YEPHENAS: <pre><blockquote>
<p>Since the Go release numbers are getting larger, people pretend that Go 2 could happen in the next two years.</p>
</blockquote>
<p>There's no correlation between the magnitude of minor version numbers and the likelihood of a version 2.</p></pre>iends: <pre><p>Surely there is at least a weak correlation.</p></pre>rsc: <pre><p>It's certainly true that if the minor version numbers were getting smaller, Go 2 would be less likely. :-)</p></pre>g0ldfi5h: <pre><blockquote>
<p>This give a lot of hope that a Go 2</p>
</blockquote>
<p>There will be no Go 2 from the Google team. </p></pre>stupidworkalt: <pre><p>Was there a statement made of this? Or is this speculation>?</p></pre>dlsniper: <pre><p>Yeah, just because there's no such label in the Go repository yet... Oh wait! There is! <a href="https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+label%3AGo2">https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+label%3AGo2</a> Now please stop trolling and Go :)</p></pre>saturn_vk: <pre><p>If I can remember, I'll try to honestly ask about the possibility of supporting sum types. The way I see it (I'm not in any way familiar with the internals of the language), sum types act very similarly to interfaces, but for types. You define the type as a collection of other types beforehand, and the compiler will know whether what you passed to a function matches said type or not. </p>
<p>That would just improve things like this:</p>
<p><a href="https://github.com/guregu/kami/blob/master/handler.go#L33" rel="nofollow">https://github.com/guregu/kami/blob/master/handler.go#L33</a></p></pre>rainworm: <pre><p>Go has this at compile time unless you mean something else. </p>
<p><a href="http://play.golang.org/p/UZU8PB2fQY" rel="nofollow">http://play.golang.org/p/UZU8PB2fQY</a> </p>
<p>Option 1. interface of interfaces. For instance, a ReadWriter is comprised of embedding Reader and Writer interfaces. Anything that fulfills all of the Reader and Writer's requirements is inherently a ReadWriter.</p>
<pre><code>type ReadWriter interface {
Reader
Writer
}
func GiveMeReadWriters (i ReadWriter) {
//...fails to compile if given a non-ReadWriter
}
</code></pre>
<p>Option 2. Define a struct and interface for the purpose of treating it like a group. Embed the struct into others structs to automatically satisfy the interface.</p></pre>saturn_vk: <pre><p>No, while it might seem similar its not quite. Interfaces "generify" actions, in your example, anything that can read, or write. Sum types "generify" data. Consider for instance the http.Handler type. It has worked great, but once the net/context package was released, it suddenly looks very limiting. And you can't do anything about it, or you will break backwards compatibility. However, if you introduce a sum type into the mix, you can rewrite all the std functions that accept an http.Handler to accept a sum type that can be either an http.Handler, or a fictional http.ContextHandler, preserving backwards compatibility. And the handlers are completely different actions, since one deals with basic handling, and the other passes along a context as well. It could look something like this:</p>
<pre><code>type handler sum {
Handler,
ContextHandler,
}
func Handle(pattern string, h handler) {
switch hs := h.(type) {
case Handler:
handleHandler(hs)
case ContextHandler:
handleContextHandler(hs)
}
}
// Or even, similar to anon structs
func Handle(pattern string, h sum { Handler, ContextHandler }) {
....
}
</code></pre>
<p>Much like interfaces, the compiler can check whether what you passed to http.Handle is one of the accepted types, and either fail during compilation, or dispatch it dynamically. It's just for data, not actions. And it looks like it would fit go quite nicely.</p></pre>rainworm: <pre><p>I'm not seeing how what you want would be prevented albeit in a messier way with interfaces. Is there a clear pseudo example of what can't be accomplished in existing Go? My mind isn't turned on yet so please forgive me. </p>
<pre><code>type Sum interface {
Handler
ContextHandler
}
func Handle(h Sum){
//use h
}
</code></pre>
<p>Do you want actions beyond this example: </p>
<p><a href="http://play.golang.org/p/SfRk-ghv9U" rel="nofollow">http://play.golang.org/p/SfRk-ghv9U</a></p></pre>saturn_vk: <pre><p>The interface mandates that all embedded interfaces and methods must be present in each implementation. A sum type can basically be only one:
<a href="https://en.wikipedia.org/wiki/Tagged_union" rel="nofollow">https://en.wikipedia.org/wiki/Tagged_union</a></p>
<p>Your very example is rather unusable, because any type you create would have to implement both interfaces (in your case), and each one would be virtually identical, save for the type signature of its one method.</p></pre>g0ldfi5h: <pre><p>Don't bother. really. The will never change the type system. I can show you 1k lines of discussion on the issue on go-nuts mailing list.</p>
<p>While they used to pretend that "they didn't know how to implement this or that", now at least they are a bit more honest and they'll answer "Go type system is simple, we want to keep it that way".</p></pre>rsc: <pre><p>Actually, I encourage you to ask. There's a much more interesting answer than "Go type system is simple, we want to keep it that way."</p></pre>treehau5_: <pre><p>Good.</p></pre>HectorJ: <pre><p>I'd like to ask about compilation times.</p>
<p>I read on multiple places that the C compiler was partially transposed to Go by an automatic translator and that, though it works, it is not really efficient.</p>
<p>Where does fixing this stands on the roadmap?</p>
<p>I'd like to see if I can help. What are the parts which needs to be rewritten manually?</p></pre>kaeshiwaza: <pre><p>Are package management in the competence of the core team or more the community ?</p></pre>enneff: <pre><p>Both. It's definitely a topic we can talk about.</p></pre>ristof: <pre><p>Where is Go heading with the future releases 1.7... 3.X? With previous versions, the GC has approved a lot but is it a priority also in next versions?</p></pre>nosmileface: <pre><p>I do have a question and it's not about generics. :)</p></pre>literallyelvis: <pre><p>Any idea on when this will occur?</p></pre>Sk1LLb0X: <pre><p>soon</p></pre>rv77ax: <pre><blockquote>
<p>soon™</p>
</blockquote></pre>ericzhill: <pre><p>When will then be now?</p></pre>rsc: <pre><p>Any day now.</p></pre>Tacticus: <pre><p>I really hope the go devs are not adherents to <a href="https://developer.valvesoftware.com/wiki/Valve_Time" rel="nofollow">valve time</a></p></pre>postman_: <pre><p>Gotta ask about pushing code of conduct on the community, since it's Gerrand who created the thread.</p></pre>
