
Toward Go 1.3 - babawere
http://talks.golang.org/2014/go1.3.slide#1
======
CoffeeDregs
First, I apologize for bringing up something that has been brought up since
the birth of Go...

I'm surprised at the lack of progress in generics for Go. But more than
_progress_ , I'm surprised at the lack of a _story_ 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 ([https://code.google.com/p/go-
wiki/wiki/GoVsGenerics](https://code.google.com/p/go-wiki/wiki/GoVsGenerics))
is tiny and feeds from this discussion
([http://groups.google.com/group/golang-
nuts/browse_thread/thr...](http://groups.google.com/group/golang-
nuts/browse_thread/thread/3d825ac84e742598)). 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.

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.

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.

~~~
tptacek
There is a story about generics in Go. The story is, a variety of complex
programs are being built and deployed in Golang without generics, which makes
it an open question as to whether they're required at all.

Golang doesn't have to be all things to all people, nor does it have to
fulfill every programming task any one developer has.

I would be just as happy at this point to see the Golang team put generics to
rest. And I like generics, and have been annoyed by their absence in Golang
before!

~~~
voidlogic
>The story is, a variety of complex programs are being built and deployed in
Golang without generics, which makes it an open question as to whether they're
required at all.

This. The same can be said for C as well, but C is not memory safe and Go is-
so it wasn't immediately obvious the same would hold for Go.

I used to use generics/templates in Java/C#/C++ a lot, and at first I missed
them in Go, but now, after writing Go full time for 2+ years- I no longer miss
them more than once or twice every few months... I think generics are great,
but also greatly overused.

~~~
AlisdairO
I work with some old Java code that's a mix of generic-ised and not. Every
time I see a method that returns a Collection I want to shout "COLLECTION OF
WHAT?!?!".

Comprehending other people's non-generic code is a giant pain in the ass
compared to reading code with generics.

~~~
wreegab
> Every time I see a method that returns a Collection I want to shout
> "COLLECTION OF WHAT?!?!"

The method was named something like "getCollectionOfSomething()"? If so, you
might want to put some of the blame on the method naming choices.

~~~
AlisdairO
A method might return, say, some URIs. These might be represented as URI
objects or strings, depending on your preference (in some tighter areas of the
code we might use String objects, because URIs can be expensive-ish to create,
and we might know for sure that the strings in question are valid). If I have
a method called getURIs, does it return URIs or Strings? Should the method be
called getURIsAsStrings? Perhaps, but it makes for some pretty awkward (and
long) method names.

Even if you do have a sensible naming scheme that makes the return type clear,
it's rather beside the point. If I have a choice between relying on coding
convention or generics, I know what option I'm going to pick.

~~~
jbert
I'm not arguing the point that generics are unuseful.

But imho the method should _not_ be named for the compiler-type of it's return
value (unless it's a type converter like int2string or similar).

It should be named for the bizlogic/semantic type:

So..not "getURIs()", but better "getBackendPoolMembers()" or
"getBackendPoolMemberURIs()" if you have more than one way of representing
them.

Long method names are fine. Everyone uses autocomplete. Choose good names and
rename them often as the meaning of the code changes over time.

~~~
AlisdairO
That's fair enough - I'm always happy to have descriptive methods names. I
still want to know the compiler type of what I'm getting back though.

------
voidlogic
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.

This presentation also doesn't mention the concurrent GC sweep work:
[https://codereview.appspot.com/46430043/](https://codereview.appspot.com/46430043/)

~~~
0xdeadbeefbabe
[http://talks.golang.org/2014/go1.3.slide#9](http://talks.golang.org/2014/go1.3.slide#9)
Ok I see how it's go-routine (or thread) safe, but what is meant by "free
list"? It's a pool of objects that you can access and put back, and putting
back doesn't block? Free as in freeing memory maybe?

~~~
ominous_prime
A "free list" is a fairly standard programming pattern, though it's not as
common to see now with memory management and GC in most languages. At the base
level, all it is is a list of currently "free" (i.e. available) resources that
have been pre-allocated.

~~~
voidlogic
Sometimes also referred to as an object pool.

What makes this implementation special is that its pooling is both thread-
local and global, and is plugged into the runtime/garbage collector. The
former makes it much much faster than any pool the user could implement, and
the later means is plays nice as resources become more scarce.

------
gtaylor
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.

I would assume that the NaCl support means that we'll be able to write things
for Chromebooks relatively easily?

~~~
enneff
No. The NaCl stuff is not about Chrome. It's about sandboxed execution in
other contexts. For instance, it powers the Go Playground:
[http://blog.golang.org/playground](http://blog.golang.org/playground)

~~~
gtaylor
Sure it's about Chrome. "Native Client is a sandbox for running compiled C and
C++ code in the browser efficiently and securely, independent of the user's
operating system."

[https://developers.google.com/native-
client/dev/](https://developers.google.com/native-client/dev/)

~~~
enneff
The Go NaCl stuff is not about Chrome.

------
NateDad
The lack of generics in Go is hugely over-hyped as a problem.

There are generic lists (slices & arrays), there are generic maps
(dictionaries). You can build a hell of a lot on top of that.

To generalize logic, Go's interfaces are amazing.

There are some huge projects out there using Go, and not hurt by the lack of
generics. Perhaps you've heard of Docker?

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".

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.

[1] [http://juju.ubuntu.com](http://juju.ubuntu.com)

------
leoc
"Go 1.3 targets that command-line tool for 32-bit and 64-bit x86
architectures.

(NaCl supports 32-bit ARM, but we have no plans to support it.)"

 _epic facepalm_

~~~
coldtea
Why, is anyone using Go on 32-bit ARM and will miss this?

~~~
georgemcbay
I use Go on 32-bit ARM (Beaglebone Black, Raspberry Pi, Samsung ARM
Chromebook, and a few old chumby imx233 devices), and having this would
actually be useful to me.

In any case, I'm sure ARM support will be added in time (just not for 1.3
release) if not from the core team than by outside contributors. There are
quite a lot of people using Go on ARM devices.

~~~
enneff
Can you explain how the NaCl port would be useful to you on ARM platforms?

~~~
georgemcbay
One long-term project I've been working on (very off and on) is something like
the chumby dashboard app system but for apps written in Go that can run on
actual old chumby devices (or really any similar ARM device such as RaspPi,
etc). Basically you'd end up with a bunch of mini apps that you rotate through
with each app doing random things, like providing a clock display, or a short
photo slideshow, or whatever.

Ideally the running apps would be sandboxed so they could be served from
potentially untrusted sources and not do damage to the underlying OS or cause
problems or privacy issues with other little apps that would rotate through
running, so a framework like the one used as the basis for the Go playground
would be ideal.

This is admittedly a very niche need and can be tackled by other OS-level
sandboxing techniques (though at that level the support offered by different
combinations of embedded Linux ARM ports and/or ARM CPUs makes things more
complicated), but NaCL support in Go/ARM would be very convenient here.

This project aside, though, there were lots of listed plans for Go 1.3 in the
presentation that I would prioritize way over ARM/NaCl.

~~~
enneff
That does sound really cool!

Sorry that we don't support NaCl/ARM code gen. Our use case (the Go
Playground) only required amd64 support, which is just 386 code gen plus more
hard bits. I'm sure if it were straightforward Russ would have just done the
ARM port too, but as you probably know ARM is very different to x86 so it
would have been another project entirely.

------
steeve
Noting that I'm successfully running Go 1.2 binaries with CGO on android/arm,
cross-compiled from darwin/amd64 (my macbook).

You can check out the Makefiles in libtorrent-go[1] and torrent2http[2]

[1] [https://github.com/steeve/libtorrent-
go](https://github.com/steeve/libtorrent-go)

[2]
[https://github.com/steeve/torrent2http](https://github.com/steeve/torrent2http)

------
sdegutis
> _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._

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.

~~~
stcredzero
_Plus, an automatic translator? Unless it is extremely disciplined C code,
that sounds harder than just translating it by hand._

It's the only way you can port without halting ongoing development. Done it.
Been paid for it. It works.

EDIT: Also, if your original is highly idiomatic, and you exploit this, you
can produce idiomatic code in the target language.

~~~
cpeterso
> Done it. Been paid for it.

Did you work on Go's translator or a different translation project?

~~~
stcredzero
Different one. Call center software.

~~~
babawere
Form what language to what language ?

------
sdegutis
> _Support for linking against Objective C code_

This is the most exciting part for me! Although I wish they didn't skim so
much on the technical detail here.

~~~
melling
Yes, but it's x86 code so it won't work on iOS. It would be cool if Go could
become an option for Android and iOS development.

~~~
enneff
Go does compile to ARM and does run on phones. It works on Android phones
(linux/arm) out of the box, and it has been made to work on iOS (darwin/arm)
but it hasn't been merged with the core:
[https://bitbucket.org/minux/goios/wiki/Home](https://bitbucket.org/minux/goios/wiki/Home)

------
kenshiro_o
Forgive my ignorance but what does 100% Precise GC means?

~~~
tomp
Languages that support pointer arithmetic have to support "raw" pointers, i.e.
pointers that point to any location in memory. This creates some problems for
the GC, as it can't be sure what objects are live and which aren't. For
example, a pointer might point to unallocated memory (in which case the GC
must not even dereference it), to a `malloc`-allocated memory, to a GC-
allocated memory, or even in the middle of a (GC-allocated or
`malloc`-allocated) heap object! In addition, some pointers look like integers
and some integers look like pointers, and the GC has no idea how to
distinguish them at runtime. In order to still support some kind of GC in such
languages, you can write your GC to be _imprecise_ or _conservative_ , which
means that it treats every integer that _could potentially_ be a pointer as a
pointer and assumes it is pointing to a live object. Potentially, this means
that the GC thinks objects are live which are actually not, just because the
programmer is using an integer which, if interpreted as a pointer, points to
said object.

I'm not intimately familiar with Go implementation, but I assume that they
haven't bothered implementing precise stack- and register-scanning, which
means that the runtime cannot distinguish pointers from integers on the
stack/in the registers. That's a really hard problem in general and solving it
requires quite some compiler support and runtime overhead. It looks like that
is finally planned for Go 1.3, though.

~~~
kenshiro_o
I see. This indeed adds a lot more complexity to the GC as it will have to
check every integer or type that "looks" like a reference.

Does this also mean that GC times will likely be longer in Go 1.3? There is
not much detailed info about the Go runtime (like we do have for Java for
instance) so it would great for the Go maintainers to publish a more in-depth
reference of the internals of the language in version 1.3 /

~~~
cpeterso
Precise (or "exactly rooted") GC should have shorter GC pause times because
the runtime knows where to look for references to GC objects, rather than
scanning stacks and the heap for bytes that might look like a pointer. The
problem is that writing code to use precise GC is more cumbersome because you
have to worry about extra bookkeeping code for every pointer reference to a
GC'd object.

------
pjmlp
Instead of doing my usual comments about Go's design, I would rather
congratulate the team in what they have achieved so far.

------
japaget
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.

~~~
darkgray
The far left and right sides are clickable to "turn the page", so to speak.
It's an invisible area, though, so it's not very easy to deduce from just
looking at the webpage.

------
Zenst
From way in the slides I saw this and got excited:

"darwin/arm, android/arm: a contributor is working on these, some way to go."

------
leothekim
One of the bullet points:

\- "Clean up and document the code, add unit tests. (Target Go 1.4)"

Oh sure, add features now and add the unit tests later. :-D #joking

------
namelezz
Wow March 1, 2014. What an exciting month with Go 1.3 and Java 8.

~~~
Jayschwa
1.3 feature freeze is in March, but there will still be a couple months of
bug-fixing and fine-tuning after that.

------
clhodapp
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.

~~~
enneff
It has a weird name, but it also won't be around for long.

------
justinsb
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?

~~~
pcwalton
Yes, in general you will need to have some other mechanism other than emitting
raw machine code to handle generics (unless you have a uniform value
representation like MLs or Java do, but Go doesn't).

------
syaramak
Slightly off topic, but is there a mobile friendly version of this site?

~~~
nfoz
Remember when Microsoft's websites only worked in IE?

~~~
cmelbye
That has very little to do with someone not putting the work in to make their
CSS responsive.

~~~
rsc
Bug reports and suggested fixes welcome. golang.org/issue

