Hacker News new | ask | show | jobs
by weberc2 3143 days ago
If your `Comparer` is an element type (as opposed to Go's `sort.Interface` abstraction over collections), this is going to be horribly unperformant. Suppose your `Foo` type implements `Comparer`, and you have a large `[]Foo`. Then you'll first have to iterate over each element in `[]Foo` and add it to your `[]Comparer`, probably with an allocation per element. Then each invocation of `foo.Compare()` is going to be indirect as well (in other words, an interface lookup and a function call, i.e. no inlining). Mind you, this is still faster than many languages, but it's not the kind of performance people expect from Go.
2 comments
AnIdiotOnTheNet 3143 days ago
From this description, I'm getting the impression that Go's interfaces are not as much like Java interfaces as I had assumed.

Never the less, I find that generics usually are just an over-engineered solution to any given problem.

link
weberc2 3143 days ago
The primary differences (I think) are that everything in Java is already a pointer, so there isn't an extra alloc to make an interface. The same is true in Go if your comparables are all pointers. Probably the more significant difference is that Java has a JIT compiler, which may be able to inline all of those calls to Compare(). This is largely why Go's `sort` package abstracts over the collection, not over the element.
link
foldr 3143 days ago
I don't see any reason why the interface lookup couldn't be done at compile time in this instance.
link
weberc2 3143 days ago
I don't think there is a technical reason. It's probably not something they'll do for a while because it probably requires some significant reorganization of the compiler and making a passably fast implementation is probably quite hard (the Go community places a premium on fast compiler times, rightly or wrongly). Also they seem to value predictable optimizations. Not sure how keen they would be to add an optimization that works until a seemingly inoccuous code change prevents the compiler from guaranteeing that all elements in the slice have the same concrete type, making performance (probably) significantly worse.

Again, I don't necessarily agree with the Go team; I'm just guessing the are some of the concerns they're weighing.

link
foldr 3142 days ago
Ah I misunderstood the previous comment. Sure, if you have a list of pointers to values that satisfy a given interface, dispatching at compile time would not be trivial.
link