4 ms·

> Accept interfaces, not structs Besides the fact that there is zero justification from this claim, the simple fact that Go think it's important to distinguish

> Accept interfaces, not structs Besides the fact that there is zero justification from this claim, the simple fact that Go think it's important to distinguish the two is another illustration of late 90s programming language design. There is really no good reason to separate these concepts today, it only causes confusion and fragments the code base in arbitrary chunks that accumulate smelly code over the years. But I'm happy to hear a good justification of why it's important to have both structs and interfaces, if there is one.

chewxy 9y ago
> But I'm happy to hear a good justification of why it's important to have both structs and interfaces, if there is one. Performance is a good reason. If you are familiar with Java or C#, Go interfaces can be seen from one point of view as boxing (i.e. making a primitive value an object). Think what that would require: vtables for function dispatch. A bunch of inlining opportunities cannot happen with that (well, it can, if you allow for name mangling during your compile phase, but that's very gross). JIT is the second fix to that, but with JIT, you're bringing in a lot of unpredictability - useful in some contexts, not so in others. Perhaps you are fine with the "Everything Is An Object/Function" paradigm, but I'm not entirely fine with that.
yegle 9y ago
Why would you think struct and interface should be treated the same? To me the fact a struct can implement multiple interfaces means they are not on the same "layer" of abstraction.
- hota_mazi 9y ago
  Imagine a struct with functions that don't have an implementation: that's an interface. If it has some implementations and some without, it's an interface with default implementations. See how Kotlin does it, it's really nice and consistent, and you never need to agonize over the decision of picking a class or a struct.
tepidandroid 9y ago
I don't think interface segregation can be simply dismissed as just 'another illustration of late 90s programming language design' (implying there's something wrong with late 90s language design...). The clearest benefit is the decoupling of dependencies which leads to more testable, extensible and maintainable code. That any struct can simply implement the desired behaviour to implicitly satisfy externally defined interfaces is an extremely powerful notion. Of all the things to complain about in Go, interfaces seem like a strange bone to pick.

chewxy 9y ago

> But I'm happy to hear a good justification of why it's important to have both structs and interfaces, if there is one. Performance is a good reason. If you are familiar with Java or C#, Go interfaces can be seen from one point of view as boxing (i.e. making a primitive value an object). Think what that would require: vtables for function dispatch. A bunch of inlining opportunities cannot happen with that (well, it can, if you allow for name mangling during your compile phase, but that's very gross). JIT is the second fix to that, but with JIT, you're bringing in a lot of unpredictability - useful in some contexts, not so in others. Perhaps you are fine with the "Everything Is An Object/Function" paradigm, but I'm not entirely fine with that.

yegle 9y ago

Why would you think struct and interface should be treated the same? To me the fact a struct can implement multiple interfaces means they are not on the same "layer" of abstraction.

hota_mazi 9y ago
Imagine a struct with functions that don't have an implementation: that's an interface. If it has some implementations and some without, it's an interface with default implementations. See how Kotlin does it, it's really nice and consistent, and you never need to agonize over the decision of picking a class or a struct.

tepidandroid 9y ago

I don't think interface segregation can be simply dismissed as just 'another illustration of late 90s programming language design' (implying there's something wrong with late 90s language design...). The clearest benefit is the decoupling of dependencies which leads to more testable, extensible and maintainable code. That any struct can simply implement the desired behaviour to implicitly satisfy externally defined interfaces is an extremely powerful notion. Of all the things to complain about in Go, interfaces seem like a strange bone to pick.