zlacker

> I do feel like C++ can defend that one from first principles though, in a way that Go cannot.

How do you propose Go interfaces should be implemented then, to avoid the multiple issues the current implementation causes (more than one kind of nil is only one such issue, memory corruption under data races is another)?

>>ncruce+(OP)
As someone with extremely similar experience to thomashabets2 over my life, but less go and more rust, please allow me to compare go's Interfaces to rusts dyn Traits, both of which are implemented pretty much identically under the hood. Rust just doesn't let you construct the data nor vtable part of the interface/trait as nil/null, in any form. Either the interface/traits instances entirely whole or it can't be instanced at all. This is the way to do it, not partially filled in one part (the vtable) and not the other (the data pointer).

>>Overmi+bk
OK, so it again all boils down to zero values.

I don't necessarily disagree that that was a design mistake, but there's zero mention of the word zero in the article.