Prompted by this question I got to thinking about methods in C# and Go. It’s another example, I realized, of Go’s (logical) insistence on orthogonality and (stylistic) insistence on flatness/lack of hierarchy.

Go does not allow methods to be defined within a struct (ersatz class) definition. Instead of this, where the method lives in the declaration: type Foo struct { Count, Price int Total() int { // nope return Count * Price } }

…one writes this: type Foo struct { Count, Price int }func (f Foo) Total() int { return f.Count * f.Price }

Which is to say, the method is its own free-standing declaration.

In C#, you have a choice of doing either (eliding access modifiers): struct Foo { int Count; int Price; int Total() { return Count * Price; } }

…or, using extension methods (eliding the outer class): struct Foo { int Count; int Price; }int Total(this Foo foo) { return foo.Count * foo.Price; }

Go achieves two things in this design decision. First, orthogonality: there is one way to write a method.

Second, a matter of taste perhaps, there is less hierarchy in Go. Methods are just funcs alongside all the others; they don't represent a new level of "indentation" or membership.

There are other design justifications described in the above link, but these advantages are the ones that jump out for me.