releasing without generics is a huge mistake
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) 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), and the SQL database driver package (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.
http://research.swtch.com/generic
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.
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.
For basic type coercion, yes, it is a pita to write boxing code, and clearly a maintenance issue as well.
But it does buy us a lot from a code complexity standpoint. C++ templates and Java's generics have a horrific effect on readability and comprehensibility, two of Go's primary goals. Generics are hard. If/when we do them, we'll get them right.
While forgetting Go has blessed in-runtime generic types because it turns out you really need generics.
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.
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 ...
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?
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.
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.
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.
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.
Plus, the creators of Go have stated that Generics are indeed considered strongly as an addition to the language post 1.0.