3 ms·
I really enjoyed Go until I started trying to work with interfaces. The fact that you have to understand the implementation details at this level in order to us
by seandougall 8y ago
I really enjoyed Go until I started trying to work with interfaces. The fact that you have to understand the implementation details at this level in order to use them reliably, IMO, shows that when the Go team talks about language simplicity, what they really mean is _compiler_ simplicity. At some point, the complexity starts getting offloaded onto the end developer.
That said, the fact that the crowd only offered an incorrect guess four times out of 16 is telling. This really didn't have the same feel to me as the original WAT talk, which is really full of truly strange things.
- int_19h 8y agoIMO, Go is an attempt to design a modern language using C philosophy, and it shows. Like, this whole thing about slices is because they insist on trying to make arrays + slices into a data structure that does everything "good enough", while mostly retaining their performance profile. And so you end up with all of those abstractions that look kinda sorta like what you'd expect in a more typical modern language - but the moment you start poking hard at them, they leak like a sieve.
- slrz 8y agoIt doesn't have anything to do with implementation details, even though the weird set of rules from the article implies that. Dump those rules for a much simpler insight: When comparing interfaces, type and value must match to compare equal. So, (nil, nil) compares NE to (*myFancyErrorType, nil) for the same reason that (float64, 0) and (uint16, 0) do. It isn't all that complicated. I don't see a real and non-insane alternative to it. Do you?
- Groxx 8y agoSure there is. Do what the vast majority of other languages do - don't bundle behavior and nil like this. Or even better, make nullability a proper first-class citizen so this nonsense can be prevented at compile time.