There is such a sentence in the above answer:
The experience of using other languages tells us that using multiple methods with the same name but different signatures is sometimes useful, but it may also cause confusion and fragility in practice.
Then it went on to say: in the type system of Go, it is a simplified main decision to match only by name and require the same type.
The last sentence: It seems more convenient than the absolute requirement about operator overloading. Similarly, without it, things would be simpler.
The whole solution is very beautiful and concise. After reading it, I understand that the designers of Go language did not overload methods in Go, and there is no complicated reason. The core principle is to keep Go simple enough. It can also be seen that the designers of Go language have great choice and restraint.
In fact, the author thinks that overload is not of great practical significance in essence. It's just that there are some differences in expressiveness and forms of expression. The key to defining a function call in a specific context is the function signature. In languages that support overloading, function names and function parameters usually constitute function signatures. In Go, you can think that the function name is the signature. There is not much difference in logic, that is, the difference between doing work in front of the stage and doing work behind the scenes.
Of course, if we must take it seriously, we may write the parameters as interface{} or ... slice when declaring methods in Go. When passing in parameters, do one-step verification, judge the type and number of parameters, and then handle them separately.
Different people have different opinions. If you have a different understanding, welcome to communicate with us.