[peterevans]

Sort of--you get dynamic types, so you can stuff whatever you want into your collections. You can do that in Go, too--just use interface{}. Sadly, that has not quieted the Generics Brigade.

If you used arrays in PHP, or Ruby, or Python, you can get those--with static typing!--in Go, either with slices for sequential arrays, or maps for associative arrays. I think that satisfies the vast majority of collection use-cases that arise in practical applications of those three languages.

(Note: I think generics would be a Good Thing for Go, and I think they'll probably happen at some point. They keep doing user surveys, and the user surveys keep bringing up the lack of generics as one of if not the number-one issue that users would like to see addressed.)

[sanderjd]

> You can do that in Go, too--just use interface{}.

This is what I mean by switching back and forth between type-world and no-type-world. If you implement a data type this way, I need to convert your no-type-world (interface{}) data to type-world data at some point after it pops out of your library.

> If you used arrays in PHP, or Ruby, or Python, you can get those--with static typing!--in Go, either with slices for sequential arrays, or maps for associative arrays. I think that satisfies the vast majority of collection use-cases that arise in practical applications of those three languages.

You do often (though not always) see "primitive obsession" in those languages, and Go encourages it even more so due to its only generic containers being the primitives provided by the language.

I don't mean to come off as a Go hater at all. I think it takes the pragmatic side of a ton of trade offs. But I do think that results in some weaknesses that people should be aware of.

[zbentley]

Can you expand on what you mean by "primitive obsession"?

[candiodari]

> Sort of--you get dynamic types, so you can stuff whatever you want into your collections. You can do that in Go, too--just use interface{}. Sadly, that has not quieted the Generics Brigade.

This argument, made often by the Go team, contradicts other arguments made by the Go team. Generics done like this have no type safety, which is the central reason for Go.

> If you used arrays in PHP, or Ruby, or Python, you can get those--with static typing!--in Go, either with slices for sequential arrays, or maps for associative arrays. I think that satisfies the vast majority of collection use-cases that arise in practical applications of those three languages.

Of course what everybody wants is trees, sorted maps, sets, ... WITH static typing.

> (Note: I think generics would be a Good Thing for Go, and I think they'll probably happen at some point. They keep doing user surveys, and the user surveys keep bringing up the lack of generics as one of if not the number-one issue that users would like to see addressed.)

No they won't. The real issue is that implementing them is pretty difficult in the compiler. Go's compiler is extremely, extremely simplistic, even to the point that it's badly written. It needs a LOT of cleaning up before anyone can reasonably contemplate adding generics.

[mseepgood]

> Generics done like this have no type safety, which is the central reason for Go.

Type safety is not the central reason for Go.

[peterevans]

I suppose time will tell whether generics are added or not. I'm--not exactly buying your argument that Go's compiler is badly written, or itself the reason that generics can't be added. But god bless ya for having an opinion.