OSNews

As I've said "up-teenth times" it is still crystal clear.

Your example makes sense in Go. The issue that you're missing is that the only time it matters if something does implement an interface is when you're using an interface as a parameter. In which case your example is more literally:

"Any valid object for this parameter must have the methods defined by this interface"

And again, if it doesn't the compiler will "kick your ass straight away".

In my opinion, you're focusing way too much on the definition of an object and no where near enough on actually using the object. So I'll repeat:

An object has methods defined with it, these methods are sufficient to tell you what the object can do. Interfaces are a separate concept designed to provide a contract for parameters. Thus mixing the interface with the object is redundant.

Go as a language tries to avoid redundancy. Maybe this hurts readability in your eyes, but in practice there's no difference and the "issue" you seem to have never comes up.

You keep on missing the point.

There is a keyword in Java that say

public MyClass implents IMyInterface.

That keyword is unambiguous. I can read the line and say to myself ... If MyClass does implement the interface correctly it won't compile.

It called readability and you keep on ignoring the fact that I keep on saying the say thing and you address it with some bullshit work around. Which I don't think is acceptable.