Comment by waps

Mind if I ask why these functions are laid out entirely differently from almost every other function in the go standard library ?

Yes, I know the Go authors do it too. And of course we know the answer : they're ashamed of just how bad it is, and mask it by making exceptions in the style guide for this specific case. You also left out the type declaration and the actual sorting call. Here's the full code :

  type myStructSlice []struct

  func (ms myStructSlice) Len() int {
    return len(ms)
  }

  func (sl myStructSlice) Less(i, j int) bool { 
    return sl[i].MyKey < sl[j].MyKey
  }

  func (sl myStructSlice) Swap(i, j int) {
    return sl[i], sl[j] = sl[j], sl[i]
  }

  ...
  sort.Sort(myStructSlice(sl))

And for this trivial example we're at 15 lines of (properly indented) code. You also have polluted the name space with one-use names for types. Is it really so hard to believe that this easily explodes to 30 lines of code for real life examples ? The Less function is not going to be nearly as simple in real life struct examples (natural sort + field precedence).

Compare to the same code in Java:

  Collections.sort(theList, (SomeType s1, SomeType p2) -> p1.field.compareTo(p2.field));

D:

  sort!("a.field < b.field")(theList)

C++:

  thelist.sort([](const someType& a, const someType& b) { return a.field < b.field; });

So Golang is 5x more verbose than Java in this instance. This a particularly bad example, but that Golang is actually more verbose than Java is not an exception in my experience.