I guess the author meant that interfaces are defined by methods, not data members. Thus, you can't have an interface that describes you should have a member field "Foo", but instead will need to create a "getter" Foo(), for it, if you want it to be part of an interface definition.
Go willingly chose to not support this behaviour causing me to write a lot of duplicated code. For example, my SAP analysis web interface uses three different product group structures, as the required amount of details varies between user stories. Go forces me to maintain the same code in three different places.
I think his reference to "duplicated code" means that he has the same data members in different structures, and that he duplicated those members, instead of using structure embedding. He then looked for a solution in interfaces, and naturally did not find it there. If so, he is at a very basic level of Go knowledge. Having dealt with complex Go codebases, I have never seen "code duplication"
Yes, that's annoying. Luckily though through embedded structs he could inherit all the methods to access each of those fields in whatever types he creates and make matching some interface easier.
Access to data members violates encapsulation. This is OOP 101. Complaining that a language doesn't allow declaration of data members in an interface declaration (and thus reliable direct access to data members) is basically complaining that the language enforces best practices for a 40 year old programming paradigm.
Go permits struct fields to be public. Ergo, Go doesn't care about enforcing the notion that field access violates encapsulation. It is up to the programmer to decide what is being encapsulated.
