First, I apologize for bringing up something that has been brought up since the birth of Go...<p>I'm surprised at the lack of progress in generics for Go. But more than <i>progress</i>, I'm surprised at the lack of a <i>story</i> about generics in Go. Yes, the FAQ waves its hands at complexity, but the lack of discussion and/or proposals puzzle me. The wiki page about it (<a href="https://code.google.com/p/go-wiki/wiki/GoVsGenerics" rel="nofollow">https://code.google.com/p/go-wiki/wiki/GoVsGenerics</a>) is tiny and feeds from this discussion (<a href="http://groups.google.com/group/golang-nuts/browse_thread/thread/3d825ac84e742598" rel="nofollow">http://groups.google.com/group/golang-nuts/browse_thread/thr...</a>). I would be much more interested in Go were there some evidence for the intent to implement generics. A related concern is that adding generics will have a significant affect on libraries and existing code, so adding generics will become harder the longer Go waits.<p>I would be very happy to have the Go team say: we're going to focus on adding generics to Go in 2.0 and will be considering how to get there sooner than later; that said, we don't know when 2.0 will be released, but building in generics will drive 2.0.<p>Note: I understand the workarounds, but they're either hacky or have terrible performance. And I also understand that users of Go say that they don't miss generics, but I'm just not comfortable believing that.
Using sync.Pool for my personal projects has made them so much faster (/ use less heap) and let me retire my custom pools. So much awesome there.<p>This presentation also doesn't mention the concurrent GC sweep work: <a href="https://codereview.appspot.com/46430043/" rel="nofollow">https://codereview.appspot.com/46430043/</a>
The combination of NaCl support and Objective C linking support make me wonder whether we will see Go creep towards being an officially "blessed" and privileged language (like Java and C+NDK) for Android development in the future.<p>I would assume that the NaCl support means that we'll be able to write things for Chromebooks relatively easily?
The lack of generics in Go is hugely over-hyped as a problem.<p>There are generic lists (slices & arrays), there are generic maps (dictionaries). You can build a hell of a lot on top of that.<p>To generalize logic, Go's interfaces are amazing.<p>There are some huge projects out there using Go, and not hurt by the lack of generics. Perhaps you've heard of Docker?<p>I work on Juju[1], a Go project that is over 200,000 lines of code. There's only a handful of places where generics would have made things a little easier, and it's never been "OMG this is so awful because we don't have generics".<p>And this is coming from a guy who spent his first 14 years programming in C++ and C#, so it's not like I'm not used to generics. You just write code in a different way. Sometimes you can't get around it when you need a containery class, so you use interface{} and cast the result, but that's the exception rather than the rule.<p>[1] <a href="http://juju.ubuntu.com" rel="nofollow">http://juju.ubuntu.com</a>
"Go 1.3 targets that command-line tool for 32-bit and 64-bit x86 architectures.<p>(NaCl supports 32-bit ARM, but we have no plans to support it.)"<p><i>epic facepalm</i>
Noting that I'm successfully running Go 1.2 binaries with CGO on android/arm, cross-compiled from darwin/amd64 (my macbook).<p>You can check out the Makefiles in libtorrent-go[1] and torrent2http[2]<p>[1] <a href="https://github.com/steeve/libtorrent-go" rel="nofollow">https://github.com/steeve/libtorrent-go</a><p>[2] <a href="https://github.com/steeve/torrent2http" rel="nofollow">https://github.com/steeve/torrent2http</a>
> <i>Compiler overhaul: the plan. Not a rewrite. Translate the C compilers to Go. Write and use an automatic translator to do this. Start the process with Go 1.3 and continue in future releases.</i><p>Aww. Transliterated C code does not sound like it will take full advantage of Go idioms. Plus, an automatic translator? Unless it is extremely disciplined C code, that sounds harder than just translating it by hand.
> <i>Support for linking against Objective C code</i><p>This is the most exciting part for me! Although I wish they didn't skim so much on the technical detail here.
I had to use the Page Up and Page Down keys to navigate this; apparently either the mouse is not supported, or I couldn't figure out how to navigate this site with the mouse.
One of the bullet points:<p>- "Clean up and document the code, add unit tests. (Target Go 1.4)"<p>Oh sure, add features now and add the unit tests later. :-D
#joking
Either these slides mischaracterize what liblink does or it has the wrong name. The fact that it does things that the linker used to do doesn't mean it is doing linking.
So "liblink" means that the compilers now generate native instructions, rather than pseudo-instructions. Seems like that would make it much tougher to implement generic methods. Anyone know if that's true?