4 ms·

Common Interface Mistakes in Go

25 points by nnx 2y ago

silisili 2y ago
Overall this is pretty solid advice, with only two things I disagreed with a bit: > Go is still a new language Go is between 12 and 17 years old, depending on how you look at it. It's not as old as the big players, but it's far from new. > Do not think returning an interface is a bad idea It's almost always a bad idea to return an interface. Return a type that implements said interface(s). If you want to hide away details, use lowercase to not export them. This section had a solid point, then backtracked a little, and I wish it hadn't.
- DSingularity 2y ago
  He wrote an entire section on why you shouldn’t return an interface and then gave a concrete example of an exception to the rule. It seems to me that it is indeed a valid exception.
  - silisili 2y ago
    I don't disagree with the specific example given, but rather that because those cases exist, we blanket say it's not a bad idea to do so...if that makes sense. It's why I used 'almost' there. Perhaps it needed to be a little segregated. The initial section is written from the perspective of a library author, asking them not to nuke away types. The example seems more of a middleware/client side thing. More often than not of course it'll make more sense to deal with types at the base layer, and interfaces at the client layers, as that's the point of them, after all.
- kazinator 2y ago
  But that's clearly in a section which poses interface returning as one of the interface mistake: 5. You are returning interfaces The author just backpedals little; it's not absolutely wrong to return an interface.
randomdata 2y ago
> You create interfaces purely for testing The interface cost is real, but I'm not yet convinced the other solutions for simulating errors while under test are not even more costly. testcontainers is a complete non-starter. I'm not, for example, going to physically crash my hard drive to get the appropriate errors out of it. If you are not documenting your failure cases in your tests, you may as well not write any code at all. The failure states are the most important part of your application.
kazinator 2y ago
Should be titled, "Advice for people coming to Go from working on nothing but 1990s COM objects". Don't return an interface? Why would I do that, when I can store it through void ** parameter you pass to me? Ha! HRESULT QueryInYourFace( REFIID riid, void **ppvObject ); And I won't make a move without designing interfaces. Interfaces is all there is, all the way down! Before we write a line of code, we fill a whiteboard with boxes that have antennas with little balls on the end. Those are interfaces.
BrannonKing 2y ago
The article doesn't go into pointers to interfaces, which is a place of many footguns. It also leaves out generics. Suppose I have this structure: type State[TValue cmp.Ordered, TCost any] interface { TransitionTo(context Context[TValue, TCost], value TValue) State[TValue, TCost] ... other methods where Context is also a generic interface. I should add a TContext generic type to State instead of casting it inside my State implementation. It definitely leads to a proliferation of generic types being required on all methods that touch these things. I used to use Go for its terseness. Generics make it much less terse, but I like what they enable.

25 points by nnx 2y ago

Overall this is pretty solid advice, with only two things I disagreed with a bit: > Go is still a new language Go is between 12 and 17 years old, depending on how you look at it. It's not as old as the big players, but it's far from new. > Do not think returning an interface is a bad idea It's almost always a bad idea to return an interface. Return a type that implements said interface(s). If you want to hide away details, use lowercase to not export them. This section had a solid point, then backtracked a little, and I wish it hadn't.

DSingularity 2y ago
He wrote an entire section on why you shouldn’t return an interface and then gave a concrete example of an exception to the rule. It seems to me that it is indeed a valid exception.
- silisili 2y ago
  I don't disagree with the specific example given, but rather that because those cases exist, we blanket say it's not a bad idea to do so...if that makes sense. It's why I used 'almost' there. Perhaps it needed to be a little segregated. The initial section is written from the perspective of a library author, asking them not to nuke away types. The example seems more of a middleware/client side thing. More often than not of course it'll make more sense to deal with types at the base layer, and interfaces at the client layers, as that's the point of them, after all.
kazinator 2y ago
But that's clearly in a section which poses interface returning as one of the interface mistake: 5. You are returning interfaces The author just backpedals little; it's not absolutely wrong to return an interface.

randomdata 2y ago

> You create interfaces purely for testing The interface cost is real, but I'm not yet convinced the other solutions for simulating errors while under test are not even more costly. testcontainers is a complete non-starter. I'm not, for example, going to physically crash my hard drive to get the appropriate errors out of it. If you are not documenting your failure cases in your tests, you may as well not write any code at all. The failure states are the most important part of your application.

kazinator 2y ago

Should be titled, "Advice for people coming to Go from working on nothing but 1990s COM objects". Don't return an interface? Why would I do that, when I can store it through void ** parameter you pass to me? Ha! HRESULT QueryInYourFace( REFIID riid, void **ppvObject ); And I won't make a move without designing interfaces. Interfaces is all there is, all the way down! Before we write a line of code, we fill a whiteboard with boxes that have antennas with little balls on the end. Those are interfaces.

BrannonKing 2y ago

The article doesn't go into pointers to interfaces, which is a place of many footguns. It also leaves out generics. Suppose I have this structure: type State[TValue cmp.Ordered, TCost any] interface { TransitionTo(context Context[TValue, TCost], value TValue) State[TValue, TCost] ... other methods where Context is also a generic interface. I should add a TContext generic type to State instead of casting it inside my State implementation. It definitely leads to a proliferation of generic types being required on all methods that touch these things. I used to use Go for its terseness. Generics make it much less terse, but I like what they enable.