3 ms·

Thanks for the explanation :) Slices are backed by arrays, not actual arrays - copying a 100K slice into another slice isn't as intensive as it sounds. I'm no

Thanks for the explanation :) Slices are backed by arrays, not actual arrays - copying a 100K slice into another slice isn't as intensive as it sounds. I'm not sure I see this as "interfaces are broken in Go", or something that requires generics to solve? (I do realise that the language itself uses generics to implement the copy keyword for this).

jwalton 5y ago
Unfortunately I think copying 100K elements is going to be exactly as painful as it sounds. The `[]Impl` is going to be (more or less) an array of 100K strings. The `[]Abstract` will be an array of interfaces, each of which is internally two pointers, so I'll have to allocate 1.6M of RAM and fill that RAM with pointers in order to convert a `[]Impl` into a `[]Abstract`. Generics fix this handily, because I can write: func ShowAbstracts[T Abstract](arr []T) { for _, a := range arr { fmt.Println(a.value()) } } And now when I try to pass in my `[]Impl`, Go will compile a new `ShowAbstracts(arr []Impl)` transparently behind the scenes.