from Hacker News

Common Interface Mistakes in Go

by nnx on 6/27/24, 5:28 AM with 7 comments

by randomdata on 6/27/24, 6:24 AM
> 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.
by kazinator on 6/27/24, 7:33 AM
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.
by silisili on 6/27/24, 6:19 AM
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.
by BrannonKing on 6/27/24, 12:33 PM
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.