zlacker

> All the examples you've shown in your article were "huh? isn't this obvious?" to me.

It is. None of this was new to me. In C++ defining a non-virtual destructor on a class hierarchy is also not new to me, but a fair critique can be made there too why it's "allowed". I do feel like C++ can defend that one from first principles though, in a way that Go cannot.

I'm not sure what you mean by the foo99 thing. I'm guessing this is about defer inside a loop?

> Is fixing those perceived footguns really a missed opportunity?

In my opinion very yes.

>>thomas+(OP)
> 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+wB2
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+HV2
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.