Constraints in Go

But "methods are only needed because of interfaces" is simply not true. Not true in all other OOP languages that I know of, not true in go, and not true in go's stdlib (that is, in practice).

Methods bind state with a function.

That an object can satisfy an interface is secondary here. In different languages, an interface could be satisfied with a combination of methods, fields, or nominality.

If the statement "we could decide that parameterized methods do not, in fact, implement interfaces, but then it's much less clear why we need methods at all" was true, then there should not be a single struct in go (stdlib nor elsewhere) that does not implement some interface (and it must be used via that interface to make sense). This is obviously not the case.

If the method is not dynamically dispatched, it is exactly equivalent to a function with receiver passed as the first argument. The receiver-dot notation is just a convenient form of implicit namespacing, then, nothing more. And, in Go, methods are only dynamically dispatched on the receiver in the context of interfaces. So, everything else is just syntactic sugar. And what the doc is saying is that supporting this syntactic sugar makes the spec much more complicated, so they deemed it not worthwhile, given that a global function works just as well in this context.

Yes, we all know what dynamic dispatch is, which is exactly what the docs talk about.

> Or, we could decide that parameterized methods do not, in fact, implement interfaces, but then it's much less clear why we need methods at all.

I will say it again: the go docs want to gaslight the reader into believing everything is allright, a design decision, and never a bad one. Constantly. It reads between a cult and a marketing piece, sometimes.

Methods have many more upsides than dynamic dispatch, or else there would be no (or little) methods that don't have an interface. We could all code like it's C, yet we don't. The only times I have been forced into this C style is when I wanted a method with generic parameters.

I don't see what other upsides are there aside from the slightly more convenient syntax, though. In other languages methods also serve as part of encapsulation mechanism, but in Go all visibility is handled on package level. What other upsides do you have in mind?

Don't get me wrong, BTW, I'm not at all a fan of Go overall design and numerous inconsistencies and limitations. But, in this case at least, they have a valid point wrt complexity of the feature (which, to be fair, is largely induced by design of Go's other features, but it is what it is at this point) versus its usefulness. I can only wish for other PL warts of Go to be as minor as this one.

Don't ask me, ask why go does it, all over the stdlib, 3rd party libs, and projects (your project too), and why this fact directly contradicts your interpretation of the doc comment about being "questionable".

I am okay with go doing lots of type complexity tradeoffs for one of the fastest and leanest compilation times out there. I'm not okay with the go creators consistently gaslighting readers into believing that this tradeoff is not happening. In other words, they want to have the cake (speed) and eat it too (my type system is actually good).

I understand that in this day and age, you are forced to do marketing (manipulate the truth) to make a PL popular. But the go project just does it too blatantly for my taste.