It is a perfectly reasonable way to test for interfaces. A single struct may satisfy a hundred interfaces which it doesn't even know about, this is actually one of the best traits of go.
But then what would the following "if" look like ?
This check is not really needed as the code would fail when a function which accepts scan.Writer would fail (compilation) if ColumnWriter is sent and if it doesn't satisfy the interface. However, this is easier to debug.
Other languages provide constructs to check for interface compliance, Go requires writing dummy code.
This is a debugging trick because Go interfaces use structural subtyping instead of explicitly declaring which types implement an interface. This is a calculated design decision with several trade offs. There is nothing "sad" about it.
Both by design, as well as, by accident (usually it different method semantics).
You don't need to teach me Go, I was into it before 1.0 given its Oberon influences, and like everyone on gonuts that disagrees with the design gets told, I went elsewhere.
By design, you can't.
> You don't need to teach me Go
Then don't state patently false claims. "Other languages provide constructs to check for interface compliance, Go requires writing dummy code." This is false because interface compliance is checked statically. This is orthogonal to whether you can list all interfaces satisfied by a given type.
> I was into it before 1.0 given its Oberon influences, and like everyone on gonuts that disagrees with the design gets told, I went elsewhere.
That's not a feature unique to gonuts. If you disagree with a project's fundamental design and stated goals, then I'm not sure what else you might expect.
For example, I'm not particularly interested in the JVM/Java world due to a myriad of design decisions that they've made. But I don't go around trolling the Internet with near content-free comments and inaccurate statements about their ecosystem.
That question doesn't make any sense. I can write a new interface that an existing type supports and then use that type as that interface. That's the awesome power of go interfaces. Using existing types for things their original creators couldn't have thought of.
You are a consultant playing fireman in a Fortune 500 corporation.
Your task, in case you accept it, is to fix a performance problem no one from in-house teams has been able to track down.
The code is developed in three sites, all in separate time zones, with an overall size of 40 developers ideally churning code 8 hours a day.
Now dive in into this code and fix the issue.
It is a fixed price project of one week.
This is an example how code navigation is valuable.
> That's the awesome power of go interfaces.
Like any language that supports structural typing, nothing awesome about it.