Hacker News Reader

Comment by rightbyte | Hacker News Reader

But there is pointer arithmetic in Go, in the "unsafe" package. Like with generics the Go authors want to decide where and when these are used, but they actually made it possible for mere users of Go to use pointers freely, since it's badly needed from time to time, unlike generics which they hide fully.

View on HN

>Like with generics the Go authors want to decide where and when these are used,

I wish this meme about Go and generics would die already. C allows you to define an array of int and and an array of char and have those be two different types. Go allows you to do this with slices and maps as well, because slices and maps are also built in types in Go. This is not "generics".

Yes, C has (very restricted) generics too. No, Go does not need to repeat all of C's mistakes.

I think it's more useful to think of "generics" as applying to type systems that allow abstraction over types. C and Go crucially don't allow you to define a function that, say, appends an element of type T to an array of T. That's where things start to get complicated. C and Go don't have a restricted version of that [1] - they just don't have it at all.

[1] With the largely irrelevant exception of the C11 _Generic stuff.

Surely it's better to confine it to a package labeled unsafe that one must import to use (and which by Go's rules one can't import and then not use) and to make a point of only using it where necessary and paying particular attention to it in testing and code reviews.

Reply on news.ycombinator.com