No, the authors specifically said that they would like to have generic features but couldn't figure out a way to implement it without unacceptable performance problems.
I'm pretty sure the feature will show up in the next few minor version increments.
> I'm pretty sure the feature will show up in the next few minor version increments.
No it won't. People need to stop expecting generics because it will never happen. Not that agree with this but it was made pretty clear in the go-nuts mailing list that the Go team wants to keep Go type system "simple".
This is one of the things I like about Go: it's "done." In exchange for passing on extensions that might make certain use cases easier, we'll avoid the bloat and have decades of backward compatibility.
We just came out of a decade of nifty language mania. What I learned is that languages are boring but problems are interesting. Algorithms and solutions are interesting. A great solution to a challenging problem is really interesting even if it's in the most boring language ever.
I have code on my machine written in C in the 70s because C is largely "done." People today continue to write interesting stuff in C. Neuromancer was written in the same language as Lord of the Rings and Moby Dick, too.
C is clearly not done, actually. Both C99 and C11 added, deprecated, and even removed many features. You can run C in the 70s not because it didn't change, but because it retained backward compatibility. It will be pretty surprising if Go manages to prohibit even the same level of changes C has taken.
Basically they dismissed every implemented approach, despite generics obviously working in other systems. (And it's hardly a "new" feature unless we're counting in multiples of decades.)
> Basically they dismissed every implemented approach, despite generics obviously working in other systems.
But working at a price. And Go isn't willing to pay the price (especially in terms of compile time). If Go ever adds generics, it will be with a new approach that doesn't blow up compile times.
C# compiles and JITs incredibly fast and has generics. F# has the same generics and compiles far slower. The reason isn't compile times. (Especially since one impl of generics is just generating code, which is cheap.)
IIRC the reasons on the list were the standard tradeoffs of memory space and so on. Do they emit specialized versions for each function, or not, and so on. Again, stuff that's working fine in other platforms.
A few years ago, Andrei Alexandrescu showed that the dmd compiler was actually faster than the gc compiler, and D supports templates. Recently, with 1.5, Go has shown that it is ready to take a hit on compile-time speeds. I don't think the argument of compilation speed holds for generics. To me it sounds much more like a culture thing: generics, for better of for worse, add an extra thing to think about and I think that the Go authors and many Go developers are just not interested.
I find that to be a very odd statement. Usually, the developer waits for the compiler in order to find out if the code compiles and executes properly. That is, every minute of compiler time costs a minute of developer time.
Worse, the developer time you spend due to lack of a feature, you spend while writing some code that would benefit from the feature. The compiler time you pay every time you compile - year after year, for some projects.
> I find that to be a very odd statement. Usually, the developer waits for the compiler in order to find out if the code compiles and executes properly. That is, every minute of compiler time costs a minute of developer time.
If your business starts to hit a wall on compile times you can buy a computer that can compile twice as fast. It's much harder to buy a developer who can think twice as fast. And every year the computers get faster and the developers stay the same.
> Worse, the developer time you spend due to lack of a feature, you spend while writing some code that would benefit from the feature. The compiler time you pay every time you compile - year after year, for some projects.
No, the cost of being unable to abstract increases exponentially as your system grows. If using language X lets you cut 500 lines from a 1000-line Go project, then when you have a 2000-line Go project, in language X you'd be able to cut 500 lines from each half of it considering each half in isolation - and then you'd be able to cut some more because of things that were common between the two halves - so you'd end up with just 750 lines of language X. And you pay the cost of extra lines every time you read or debug, year after year.
> Worse, the developer time you spend due to lack of a feature, you spend while writing some code that would benefit from the feature. The compiler time you pay every time you compile - year after year, for some projects.
Except that this is a false dichotomy: you don't have to have a lack of features to get a fast compile. Incremental compiles have existed for a very long time in various language ecosystems and will achieve very acceptable results.
In addition, SSDs and multicore CPUs can be leveraged to decrease compile times, and these things are only getting better.
I imagine not that much in practice. It is not like someone is going to manually write out identical functions twenty times for each type they want to support. That's precisely what computers are good at doing and there are countless tools to do it painlessly.
The bigger problem is that Go doesn't have type inheritance or similar. Meaning, there's no great way to say that this generic function will only work with number types, for example. You leave the burden on the programmer to ensure their generalized function is applied only to types which it is intended to be used with.
While that is less than ideal, I cannot see that increasing developer time by a significant margin.
A fantastic idea, even slower to compile (since you need to parse extra source files), more complex workflow, and extra files which developers have to remember to ignore.
Incremental compiles have existed for quite some time.
Go is only unique in that it can do a complete recompile in very attractive times. The only hitch, of course, is that you sacrifice features known and loved in other languages for over a decade.
I'm pretty sure the feature will show up in the next few minor version increments.