Someone here more familiar with the process could maybe summarize the next several steps and the timeline within which we might expect to get a "go" binary that can compile generics.
I don't follow go language design very closely, but I'm curious about how this is going to be implemented, if it actually becomes accepted. What comes immediately to mind is boxing in Java (i.e. you can't have a generic of a primitive).
If go implements generics on top of boxing like Java did, isn't that basically just syntax sugar on top of `type T interface {}`?
For example, today I can write "generic" go code like so:
type T interface {}
func main() {
ints := []T {1,2,3,4}
intsum := Sum(ints, func(a T, b T) T {
return a.(int) + b.(int)
})
fmt.Println(intsum.(int))
}
func Sum(s []T, add func(T, T) T) T {
var sum = s[0]
for i := 1; i < len(s); i++ {
sum = add(sum, s[i])
}
return sum
}
At this point, I fear that, with time, languages will end up adopting each and every paradigm, all of the syntactic sugars, and so on. I escaped perl for a reason.
It's interesting how "angle brackets vs. square brackets" is such an issue for many Go programmers commenting on the generics proposals (including earlier ones).
Maybe it is just revealing where those programmers are coming from. Java and C++? Angle brackets! Eiffel, Scala? Square brackets!
Are there any parser considerations (like <Foo <Bar>> being an issue in C++, afair), or is it just taste (or Scala vs. C++ background)?
For those who are against generics (in general, or with Go specifically), what's your particular rationale? I find myself unable to create an effective anti-generics argument in the same way I can make a pro-generics argument.
So far what I've seen here seem to be:
- You can already use interface{} for something similar to generics
- I don't want the language to become more complex
- I can't conceive of how it'll be done efficiently/effectively
- I don't, personally, see the value of generics (i.e., it wouldn't change any code I've ever written)
I've been writing Go for years and never came across a problem that made me want to have generics.
Anyone able to give me a simple example demonstrating why Go needs this?
Meanwhile Crystal lang has had generics for years and years. Just saying :D
That said, super excited to see Go maturing to the point where they address the #1 complaint about the language. Maybe I'll actually pick it up once this goes through!
Woot. looks like Go might jump decades from the 70s all the way up to mid 2000s language design.
Has Go's interface{} single-handedly confused a generation of software developers, to the extent that they just couldn't understand the language? Is this what happens when languages reach an escape velocity of userbase?
I still remember when lack of generics and other common stuff was one of their main selling points in the beginning.