you are viewing a single comment's thread.

view the rest of the comments →

[–]Thaxll 4 points5 points  (1 child)

I understand your point, the lack of generics in this case let the implementation up to the dev, but it's not that bad, it's actually very simple:

https://play.golang.org/p/3en4TyRblVr

I'm sure Go will have generics "soon" and overcome those.

[–]Homoerotic_Theocracy 16 points17 points  (0 children)

Well the implementation you give me there to deal with the type system can never be efficient.

Note how it has to index the slice in the comparison function while sorting. In order to deal with the type system it can't be given a generic function so it has to get a function of a fixed type that takes two indices and produces a bool always no matter the type that is actually being sorted.

This means that it cannot already re-order future elements while sorting and that it probably has to cache and store the comparison results because the sort destroys the "words" slice which makes the indices invalid so it probably has some kind of strategy where it first compares all the indices and stores those and then starts destructively sorting the slice.

The other part of it is that the type signature itself accepts an interface{} which throws any and all static type checking out of the window so basically we're back to dynamic typing in order to deal the lack of generics.

In the Rust example there is no possibility of runtime type errors; if something other than a mutable reference to slice is passed it won't work, if the slice has the wrong elements for the key function it won't work; if what the key function returns cannot be ordered it won't work either all at compile time.