Comment by thomashabets2

Comment by thomashabets2 a day ago

> 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.

ncruces 6 hours ago

> 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)?

Reply View 1 reply

OvermindDL1 2 hours ago

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).

Reply View | 0 replies