
Go 1.2 - jgrahamc
https://code.google.com/p/go/source/detail?r=87dea3f5ebe7
======
friendly_chap
I am a heavy user of Go, I use it in my job and for side projects as well, for
years now.

The lack of generics in Go takes away most of the fun from coding after a
couple of month. Despite what is being said, interfaces do not lessen the
pain.

With a better type system, taking ides from Haskell (ADT, generics done well,
ability to implement interfaces for a type outside of its package etc) Go
could be the perfect "dirty Haskell" for me, but now it is just a meh language
with a half assed implementation.

That being said, it is still a much better choice then a lot of
overcomplicated languages out there.

EDIT:

The biggest practical problem with not having generics is the fact you do not
have access to list (slice in Go) manipulation functions. This means you have
to implement them yourself, on the fly, for the given type when you need it.
This does increase the time it takes to implement something, but also can
introduce a lot of bugs as well - you can't rely on (almost guaranteedly) bug
free implementations of existing functions.

Of course this runs much deeper than just the list type, but on day-to-day
basis I feel this to be the biggest pain. But the rabbit hole is deep: we
could get into how the multiple returns values are just a really inconvenient
(not composable) workaround of not having a generic tuple type...

~~~
druska
Generics have their own problems:
[http://research.swtch.com/generic](http://research.swtch.com/generic)

~~~
kvb
As many comments point out, he neglects the .NET approach to generics, which
avoids most of the drawbacks of C++'s approach and Java's.

~~~
eeperson
Do you know it does this ? I've heard this before and I'm not sure how C# can
do this.

~~~
kmontrose
In C#...

At compile, there's one version of a generic method (say List<T>.Add).
Compilation isn't slowed down like in C++.

At runtime, a generic method is compiled (on demand) into unique versions for
each T encountered if T is a ValueType (int, double, etc. including user
defined ValueTypes). This avoids boxing, like in Java.

Also at runtime, for all T's that are reference types a single common version
is used with implicit casting as in Java.

C#'s draw back is that there is a small cost incurred on the first use of a
generic method, and then an additional cost for each new ValueType used (if
any). In practice this doesn't ever seem to be an issue, but it's there.

See
[http://stackoverflow.com/q/5342345/80572](http://stackoverflow.com/q/5342345/80572)
and
[http://www.artima.com/intv/generics.html](http://www.artima.com/intv/generics.html)
(which is linked from the former).

~~~
dsymonds
That sounds like a variation on rsc's 3rd approach (but with runtime code
generation instead of boxing) with the same drawback: slower execution. It
also makes certain kinds of debugging harder (how do you map a PC that's
pointing to generated code? what if the code generation is the thing going
wrong?).

C# on CLR is a VM approach, whereas Go compiles to native code. Concepts that
are easy in the first (e.g. runtime code generation) often don't map
particularly nicely to the second.

~~~
kmontrose
Why would you expect execution to be slower? If you invoke List<T>.Add(T)
where T = int you end up running the same machine code that would have been
generated if instead you had a method List.Add(int). There is a cost paid to
generated that specific method, but it's on the first invocation. I'd expect
it to be much faster than boxing, because you can elide a bunch of a
allocations and generate tighter code since you have additional typing
information at code gen time.

I suppose debugging could go sideways in theory, but it doesn't happen in
practice on .NET and I doubt the go team couldn't figure out how to make it
work.

It's worth noting that .NET never interprets bytecode, it always converts a
method into machine code before execution. Go has already had dynamic code
generation as part of it's implementation (I don't know if it's still around
in 1.2), so it's hardly like it can't do the same thing .NET is.

~~~
malkia
Okay, then how does AOT works with C# templates? Really how? Do you have to
pre-declare some known types ahead? (Or could it be that the AOT compiler
scans all possible variants (doable since it's static language))?

~~~
kmontrose
AOT is a Mono extension to .NET, there are some cases it doesn't work and
generics can cause some of them. See: [http://www.mono-
project.com/AOT](http://www.mono-project.com/AOT) for more details

For .NET proper, new machine code is generated at runtime. I believe (but do
not know for sure, offhand) that it basically takes the IL definition of the
generic method, slots the now known type into it, and JITs it to get the
machine code it needs. I do know that there are couple bits of IL that are
meant to make it possible to write the same code to deal with both reference
and value types, which is probably related.

Ngen ([http://msdn.microsoft.com/en-
us/library/6t9t5wcf(v=vs.110).a...](http://msdn.microsoft.com/en-
us/library/6t9t5wcf\(v=vs.110\).aspx)) let's you transforms assemblies into
machine code up front, while still being .NET proper. However, if it _can 't_
find a use of generics with concrete types found at runtime (ie. you generate
a List<int> via reflection) you'll still load up and use the JIT (see some
discussion here:
[http://stackoverflow.com/q/16647568/80572](http://stackoverflow.com/q/16647568/80572)).

I don't use AOT or Ngen regularly, so the particulars may be a little off in
my explanations. But that's the gist of it.

------
justinhj
Here's a long quote by Rob Pike, which whether you agree with the points he
makes or not, explains why Go does not have generics.

"Early in the rollout of Go I was told by someone that he could not imagine
working in a language without generic types. As I have reported elsewhere, I
found that an odd remark. To be fair he was probably saying in his own way
that he really liked what the STL does for him in C++. For the purpose of
argument, though, let's take his claim at face value. What it says is that he
finds writing containers like lists of ints and maps of strings an unbearable
burden. I find that an odd claim. I spend very little of my programming time
struggling with those issues, even in languages without generic types. But
more important, what it says is that types are the way to lift that burden.
Types. Not polymorphic functions or language primitives or helpers of other
kinds, but types. That's the detail that sticks with me. Programmers who come
to Go from C++ and Java miss the idea of programming with types, particularly
inheritance and subclassing and all that. Perhaps I'm a philistine about types
but I've never found that model particularly expressive. My late friend Alain
Fournier once told me that he considered the lowest form of academic work to
be taxonomy. And you know what? Type hierarchies are just taxonomy. You need
to decide what piece goes in what box, every type's parent, whether A inherits
from B or B from A. Is a sortable array an array that sorts or a sorter
represented by an array? If you believe that types address all design issues
you must make that decision. I believe that's a preposterous way to think
about programming. What matters isn't the ancestor relations between things
but what they can do for you."

~~~
kung-fu-master
From this message I understood that the Go is a language only for him and not
for others developers.

~~~
axaxs
You're right, kinda. It's been obvious from the start that this is a bell labs
venture so to speak. I love the language, and assume the likes of Pike,
Thompson, and Cox to know enough to know better. Community driven languages
suck, so I leave it to those much more experienced than me to make these
decisions, and I'm ok with that.

------
buro9
If you're used to running from source using this:

    
    
         hg pull
         hg update release
    

It does not yet return 1.2.

You'll need to use:

    
    
         hg pull
         hg update release-branch.go1.2
    

And then build.

The OP link goes to the commit showing this branch being finalised.

~~~
rsc
Yes, the release has not happened yet. That commit is just the penultimate
step.

~~~
jawr
This release is out on 1/12/13 it's still meant to have a major bug. This
isn't actually a release...

~~~
rsc
What bug is that?

~~~
jawr
Beg your pardon, jumped the gun myself there. Misread a comment on the IRC
channel: "unless there's some massive bug, I doubt we'll see the tip of the
tree change"

------
Nican
Changes can be found here:
[http://tip.golang.org/doc/go1.2](http://tip.golang.org/doc/go1.2)

~~~
humanfromearth
I was wondering when we'll get three-index slices

~~~
wreegab
From the text: "It is impossible to use this new slice value to access the
_last three elements_ of the original array"

Shouldn't this rather be: "It is impossible to use this new slice value to
access the _last element_ of the original array"

~~~
Jayschwa
It looks like the third number specifies an _index_ , not a _length_.

    
    
      var array [10]int
      slice = array[2:4:7]
    

> its capacity is now only 5 elements (7-2)

------
riobard
People using lots of goroutines should note the change of minimal stack from
4KB to 8KB.

“Updating: The increased minimum stack size may cause programs with many
goroutines to use more memory. There is no workaround, but plans for future
releases include new stack management technology that should address the
problem better.”

This is a runtime/debug call to restrict the max size of stack. Somehow I feel
like there should be one to set the min size too…

------
jawr
Not an actual release, the VERSION file changed on a non-main branch.. Stop
jumping the gun.

------
kitsune_
Nice, congratulations on the release.

I'd really like to see some progress on generics / parametric types. I'm
starting to get the impression that it will never happen.

~~~
praptak
It looks like 1) generics are not very well aligned with the main design goals
of Go and 2) it would take a very well thought out design to align them so, if
that's possible at all.

From the FAQ: _" Generics are convenient but they come at a cost in complexity
in the type system and run-time. We haven't yet found a design that gives
value proportionate to the complexity, although we continue to think about it.
Meanwhile, Go's built-in maps and slices, plus the ability to use the empty
interface to construct containers (with explicit unboxing) mean in many cases
it is possible to write code that does what generics would enable, if less
smoothly.

This remains an open issue."_

~~~
lloeki
> the ability to use the empty interface to construct containers (with
> explicit unboxing)

I'm not versed in Go, but does that mean something similar to (Java-style)
Object[] and explicit casting of each value you get out of the list?

~~~
kitsune_
Go has so called _type assertions_ , an example:

[http://play.golang.org/p/L5hprjhqN_](http://play.golang.org/p/L5hprjhqN_)

In this example, one function probes the underlying type by using _t.(type)_ ,
and the other one uses a _type assertion_ by doing a _val, ok := t.(int)_ \-
The _type assertion_ will return the value of the integer and true if _t_
happens to be an integer (a Go function can return multiple values)

If you pass an object as an "empty interface{}" you can test the underlying
type.

edit: Note that you can only use a type assertion with an interface! So, this
fails:
[http://play.golang.org/p/0BtSWfE3f2](http://play.golang.org/p/0BtSWfE3f2) but
this doesn't:
[http://play.golang.org/p/tZB4Jivp3z](http://play.golang.org/p/tZB4Jivp3z)

~~~
lloeki
Is this purely evaluated at runtime or does Go annotates types with its static
analysis and restricts the interface in some ways? IOW are _default_ and
_else_ cases made optional by Go's static analysis, which would help Go throw
its arms up at compile time if an unexpected type is passed?

~~~
kitsune_
I think it's purely evaluated at run-time because you can do this:

[http://play.golang.org/p/Mtg8A5SzdS](http://play.golang.org/p/Mtg8A5SzdS)

------
cpeterso
Are there any plans to self-host the Go compiler in Go itself? Rust is self-
hosted in Rust (originally bootstrapped by a Rust compiler written in OCaml).
I've found a couple Go compilers written in Go that bind to LLVM backends, but
they are just prototypes.

The Go developers make a big deal about compilation speed. Wouldn't Go's
goroutines have some interesting possibilities for parallelizing compilation?

~~~
BarkMore
Self hosting is mentioned in the FAQ:
[http://golang.org/doc/faq#What_compiler_technology_is_used_t...](http://golang.org/doc/faq#What_compiler_technology_is_used_to_build_the_compilers)

------
dbaupp
_> The scheduler is invoked occasionally upon entry to a function_ [from
[http://tip.golang.org/doc/go1.2](http://tip.golang.org/doc/go1.2)]

Does this mean that every function call has to do a check and possibly an
(atomic?) increment of some variable?

~~~
rsc
No. It reuses the check that was already being done for stack growth.

~~~
dbaupp
So the answer is "yes but nothing more than what happens in 1.1" to the check,
but no to the increment?

------
AYBABTME
Go 1.2 is not yet released.

------
matiasb
Any Go jobs over there?

~~~
jbk
I do offer Go jobs. But in Paris, France :)

~~~
thibaut_barrere
Do you have a contact email? Not for me but maybe some of my twitter followers
could be interested. Thanks!

~~~
jbk
My email should be easy to find :) jb@ videolan.org

------
bct
tomaszkubacki: You have been hellbanned.

------
booop
Has anyone combined Go and angular.js to build something? How were your
results?

~~~
rdtsc
The two are rather separate. The only way I can see combining them is if there
is extensive server side template-ing. But angular.js kind of discourages
that. So you can use go to build a RESTful server and then use angular.js on
the front end. But that sort of de-couples the system to the point where it
doesn't make sense to talk about an advantage of a combination of both.

~~~
mjibson
Having myself written such a site
([http://www.goread.io/](http://www.goread.io/)), I concur. Having go on the
backend didn't provide any benefits with an angular frontend over another
language. I just think they excel at their respective purposes - that's why I
chose them.

