5 ms·

releasing without generics is a huge mistake

cageface 15y ago
Maybe. Certainly if releasing without them means they're going to be stuck with a half-assed Javaesque implementation later. On the other hand, generics can complicate a language implementation considerably.
- ootachi 15y ago
  From an implementation perspective, generics aren't that bad. For an ahead-of-time-compiled language, you either need a uniform value representation (like ML/Java) or a monomorphization pass (like C++). The former corresponds to what Go has today if you simulate generics with interfaces. The latter corresponds to what Go has today if you simulate generics by duplicating your code (for example, if you wrote an IntTree to operate on ints, a StringTree to operate on strings, and so on). They do complicate the typechecker a little bit, largely due to the interaction with subtyping (which Go has via interfaces, I believe). You probably want definition-site variance, not use-site variance like Java, to keep things simple. Also remember that parameterized types must be invariant, not covariant, in the presence of mutability. (Additionally, if you have subtyping for function types, remember that the arguments are contravariant -- Go probably doesn't care about this, though.) None of this stuff is that complicated, though -- it's all pretty straightforward at this point. There's no reason to fear generics. Moreover, as noted above, all of the workarounds end up duplicating effort that the compiler could have done for you. If you use interfaces, you pay the tax of boxing. If you use code duplication, you pay the cost of increased compile times and increased binary size. Nothing is gained from not having generics, except maybe a simpler type system.
- densh 15y ago
  Java's top priority is to never, ever break anything. It has to be both binary and source compatible. That's a major reason why generics in Java are so broken. They couldn't change syntax to make it nicer and they couldn't substantially change jvm to make it generic-friendly. Which leads us to type erasure and weak integration of generics into the language. Go has quite a different opinion on this question -- we'd rather break things but make a tool (gofix) to automatically fix all your source code. Also Go doesn't aim at binary compatibility at the moment as compilation time is _extremely_ fast and there are no shared library support yet. Most likely they'll be more conservative with Go becoming stable and getting 1.0 release but that doesn't prevent them to break things for 2.0 if that's needed.
  - kristianp 15y ago
    Note that, at the moment it looks like Go will never have shared library support. It seems to not be required and I think there's a conflict of interest with the complexity of (or lack of developer resources for) the fast linker Go uses.
p9idf 15y ago
Your argument is not clear to me. However allow me to share some of the Go authors' thoughts about generics: http://research.swtch.com/generic http://research.swtch.com/generic http://commandcenter.blogspot.com/2011/12/esmereldas-imagination.html http://commandcenter.blogspot.com/2011/12/esmereldas-imagina... I am inclined to agree with them. I like writing Go programs quickly, but not at the expense of compilation speed† or execution speed. The point of Go is to be fast. If I valued programming speed for a particular program, then I would use the right tool for the job and choose a language other than Go. † Though considering the speed of Plan 9-style compilers, I can't imagine at what scale this would begin to be a problem.
- ootachi 15y ago
  As I stated below, Go's lack of generics isn't buying the language anything from an implementation standpoint. What Russ Cox is missing is that, absent some way to write generic code, programmers will end up paying the exact same taxes via their handwritten non-generic code. Consider, for example, a binary search tree that can be instantiated with keys of int type or keys of string type. There are two ways to implement this in Go: (a) use an interface and dispatch calls through a vtable; or (b) implement the tree twice, once for ints and once for strings. But note: these two implementation strategies carry the exact same costs as the corresponding implementation strategies for generics! In the case of (a), the programmer is performing boxing via interface types, while in the case of (b), the programmer is performing code duplication. So not having generics doesn't relieve Go programs of compile-time or runtime overhead in any way; it simply increases the burden on the programmer.
  - eternalban 15y ago
    Let's take case (a) -- that's the approach I adopted when implementing a Splay tree, introducing a Comparator interface. Granted it is a bit of a pain to write IntComparator, LongComparator, etc., but given that Go is not an object oriented language e.g. all types do not support a (hypothetical) CompareTo(other T), it is not clear to me how would the availability of generics would help in this case. For basic type coercion, yes, it is a pita to write boxing code, and clearly a maintenance issue as well.
jbarham 15y ago
I've written a fair bit of Go code, and rarely miss generics. Two Go features in particular help to mitigate the lack of generics: 1. The built-in array/slice and map containers are effectively generic since they can act as containers for any type. 2. Interfaces (http://weekly.golang.org/ref/spec#Interface_types http://weekly.golang.org/ref/spec#Interface_types) define a set of common methods that can be implemented by multiple concrete types. See e.g. the ubiquitous io.Reader interface (http://weekly.golang.org/pkg/io/#Reader http://weekly.golang.org/pkg/io/#Reader), and the SQL database driver package (http://weekly.golang.org/pkg/database/sql/driver/ http://weekly.golang.org/pkg/database/sql/driver/) that defines a collection of interfaces that define an interface to any SQL database. FWIW I've written a concrete PostgreSQL driver: https://github.com/jbarham/gopgsqldriver https://github.com/jbarham/gopgsqldriver.
enneff 15y ago
On the contrary, it is vitally important. Go 1 was a stabilization of what we already had, not an occasion to introduce new features. If Go gets generics it will have a profound effect on the language and its libraries. better to introduce them in Go 2 once we know what they are and have a wealth of experience with them.
- soc88 15y ago
  Does this make _any_ sense? Normally you introduce stuff having "profund effect"s on the whole ecosystem _before_ you release something as "stable". Maybe the Go devs want to repeat the Java generics story ...
  - enneff 15y ago
    Sure, we could have introduced generics (we have a pretty decent proposal in the works) and then tweaked it for another couple of years, but that wouldn't be fair to the thousands of Go programmers (including those at Google) who need to use Go in their day-to-day lives. As has been mentioned elsewhere, part of the problem with Java's generics story was that they needed to maintain backward compatibility at all costs. The same won't be true for Go 2, which may include support for generics. Go 1 is a solid product - language, standard library, and tools - and one we will support for years to come. There will be a time for experimenting with generics but that time isn't now. Why is everyone in such a rush?
MatthewPhillips 15y ago
We already have Java.
- batista 15y ago
  And that is relevant because? Generics aren't a unique trait of Java --quite the opposite: the language existed for a decade without them, and even now doesn't have a nice implementation of them.
  - MatthewPhillips 15y ago
    > And that is relevant because? The goal of C-like languages isn't to duplicate Java features. Go (and others) have their own set of goals. In this case generics doesn't advance the goals.
    - batista 15y ago
      Actually, the goals doesn't have anything to do with the presence of generic in the language or not. Plus, the creators of Go have stated that Generics are indeed considered strongly as an addition to the language post 1.0.

Maybe. Certainly if releasing without them means they're going to be stuck with a half-assed Javaesque implementation later. On the other hand, generics can complicate a language implementation considerably.

ootachi 15y ago
From an implementation perspective, generics aren't that bad. For an ahead-of-time-compiled language, you either need a uniform value representation (like ML/Java) or a monomorphization pass (like C++). The former corresponds to what Go has today if you simulate generics with interfaces. The latter corresponds to what Go has today if you simulate generics by duplicating your code (for example, if you wrote an IntTree to operate on ints, a StringTree to operate on strings, and so on). They do complicate the typechecker a little bit, largely due to the interaction with subtyping (which Go has via interfaces, I believe). You probably want definition-site variance, not use-site variance like Java, to keep things simple. Also remember that parameterized types must be invariant, not covariant, in the presence of mutability. (Additionally, if you have subtyping for function types, remember that the arguments are contravariant -- Go probably doesn't care about this, though.) None of this stuff is that complicated, though -- it's all pretty straightforward at this point. There's no reason to fear generics. Moreover, as noted above, all of the workarounds end up duplicating effort that the compiler could have done for you. If you use interfaces, you pay the tax of boxing. If you use code duplication, you pay the cost of increased compile times and increased binary size. Nothing is gained from not having generics, except maybe a simpler type system.
densh 15y ago
Java's top priority is to never, ever break anything. It has to be both binary and source compatible. That's a major reason why generics in Java are so broken. They couldn't change syntax to make it nicer and they couldn't substantially change jvm to make it generic-friendly. Which leads us to type erasure and weak integration of generics into the language. Go has quite a different opinion on this question -- we'd rather break things but make a tool (gofix) to automatically fix all your source code. Also Go doesn't aim at binary compatibility at the moment as compilation time is _extremely_ fast and there are no shared library support yet. Most likely they'll be more conservative with Go becoming stable and getting 1.0 release but that doesn't prevent them to break things for 2.0 if that's needed.
- kristianp 15y ago
  Note that, at the moment it looks like Go will never have shared library support. It seems to not be required and I think there's a conflict of interest with the complexity of (or lack of developer resources for) the fast linker Go uses.

p9idf 15y ago

Your argument is not clear to me. However allow me to share some of the Go authors' thoughts about generics: http://research.swtch.com/generic http://research.swtch.com/generic http://commandcenter.blogspot.com/2011/12/esmereldas-imagination.html http://commandcenter.blogspot.com/2011/12/esmereldas-imagina... I am inclined to agree with them. I like writing Go programs quickly, but not at the expense of compilation speed† or execution speed. The point of Go is to be fast. If I valued programming speed for a particular program, then I would use the right tool for the job and choose a language other than Go. † Though considering the speed of Plan 9-style compilers, I can't imagine at what scale this would begin to be a problem.

ootachi 15y ago
As I stated below, Go's lack of generics isn't buying the language anything from an implementation standpoint. What Russ Cox is missing is that, absent some way to write generic code, programmers will end up paying the exact same taxes via their handwritten non-generic code. Consider, for example, a binary search tree that can be instantiated with keys of int type or keys of string type. There are two ways to implement this in Go: (a) use an interface and dispatch calls through a vtable; or (b) implement the tree twice, once for ints and once for strings. But note: these two implementation strategies carry the exact same costs as the corresponding implementation strategies for generics! In the case of (a), the programmer is performing boxing via interface types, while in the case of (b), the programmer is performing code duplication. So not having generics doesn't relieve Go programs of compile-time or runtime overhead in any way; it simply increases the burden on the programmer.
- eternalban 15y ago
  Let's take case (a) -- that's the approach I adopted when implementing a Splay tree, introducing a Comparator interface. Granted it is a bit of a pain to write IntComparator, LongComparator, etc., but given that Go is not an object oriented language e.g. all types do not support a (hypothetical) CompareTo(other T), it is not clear to me how would the availability of generics would help in this case. For basic type coercion, yes, it is a pita to write boxing code, and clearly a maintenance issue as well.

jbarham 15y ago

I've written a fair bit of Go code, and rarely miss generics. Two Go features in particular help to mitigate the lack of generics: 1. The built-in array/slice and map containers are effectively generic since they can act as containers for any type. 2. Interfaces (http://weekly.golang.org/ref/spec#Interface_types http://weekly.golang.org/ref/spec#Interface_types) define a set of common methods that can be implemented by multiple concrete types. See e.g. the ubiquitous io.Reader interface (http://weekly.golang.org/pkg/io/#Reader http://weekly.golang.org/pkg/io/#Reader), and the SQL database driver package (http://weekly.golang.org/pkg/database/sql/driver/ http://weekly.golang.org/pkg/database/sql/driver/) that defines a collection of interfaces that define an interface to any SQL database. FWIW I've written a concrete PostgreSQL driver: https://github.com/jbarham/gopgsqldriver https://github.com/jbarham/gopgsqldriver.

enneff 15y ago

On the contrary, it is vitally important. Go 1 was a stabilization of what we already had, not an occasion to introduce new features. If Go gets generics it will have a profound effect on the language and its libraries. better to introduce them in Go 2 once we know what they are and have a wealth of experience with them.

soc88 15y ago
Does this make _any_ sense? Normally you introduce stuff having "profund effect"s on the whole ecosystem _before_ you release something as "stable". Maybe the Go devs want to repeat the Java generics story ...
- enneff 15y ago
  Sure, we could have introduced generics (we have a pretty decent proposal in the works) and then tweaked it for another couple of years, but that wouldn't be fair to the thousands of Go programmers (including those at Google) who need to use Go in their day-to-day lives. As has been mentioned elsewhere, part of the problem with Java's generics story was that they needed to maintain backward compatibility at all costs. The same won't be true for Go 2, which may include support for generics. Go 1 is a solid product - language, standard library, and tools - and one we will support for years to come. There will be a time for experimenting with generics but that time isn't now. Why is everyone in such a rush?

MatthewPhillips 15y ago

We already have Java.

batista 15y ago
And that is relevant because? Generics aren't a unique trait of Java --quite the opposite: the language existed for a decade without them, and even now doesn't have a nice implementation of them.
- MatthewPhillips 15y ago
  > And that is relevant because? The goal of C-like languages isn't to duplicate Java features. Go (and others) have their own set of goals. In this case generics doesn't advance the goals.
  - batista 15y ago
    Actually, the goals doesn't have anything to do with the presence of generic in the language or not. Plus, the creators of Go have stated that Generics are indeed considered strongly as an addition to the language post 1.0.