[pdpi]

> and no worse than pre-generics java

Personally, that was the turning point when Java became palatable. Which is a shame, because Go is all-around a pretty nice language. But writing real, production code, I've felt that I was needlessly repeating myself because of the lack of generics. Specifically, I really wish I could write generics over channels, so I can solve the problems of multiplexing/demultiplexing channels, throttling them, etc exactly once.

[dilap]

(It's worth pointing out that Go does offer lots that pre-generics java doesn't, in particular interfaces w/ structural typing.)

Agreed that not having generics is a real pain-point, though not as bad as I would've assumed before using the language.

For the channel stuff, you could always just make use "chan interface{}", have your generic chan library, and then cast when receiving from the channel.

Or you could use code generation to make specific versions of your library for various types, maybe using the upcoming go generate.

It's kind of interesting, because C++ templates, for example, essentially are code-generation, but just hidden away, and for that reason tend to get overused (IMO), resulting in crazy-long compile times.

If Go's solution to generics ends up being "generate the code explicitly", it would seem uniquely Go-ish -- inelegant, but might work well practice.

(I do sort of dream about some kind of generics in Go -- something like

  where X interface{}
  type LinkedList X struct {
    Obj X
    Next *LinkedList X
  }

and maybe...

  where X Lessable
  type Heap X []X

  func (h *Heap X) Push(x X) {
     ...
  }

or even just

   where X interface{}
   func PushHeap(h []X, x X, less func (a,b X) bool) {
      ...
   }

Ah, to dream :)