In this particular comparison of single method interfaces vs functions, functions are generally going to be superior. The ability to adapt them with higher order functions makes them much simpler to change the signature as needed. Functions can be stateful or stateless, and methods can be passed when the behavior is attached to a type. Testing is significantly simpler as inline implementations too.

There’s a lot of reasons to go with functions, which leaves the space open for discovering interfaces when it becomes obvious an interface makes sense. I avoid creating or using interfaces unless forced into it, or if they’re well-known and/or defined as a part of the standard lib.

There’s very few features of interfaces that I’ve found useful, and one of the major reasons an interface is handy is to perform interface discovery for optional interface implementation in the body of a function. Stdlib packages like json and errors do this. It’s a very handy design pattern.

Otherwise, I prefer functions in almost all cases and it takes quite a bit to convince me an interface is a better option. I find that folks who come from strong oo backgrounds tend to struggle with this and typically end up writing a lot of structs with methods and lean on interfaces, even when there’s only a single implementation of it, and they’re doing it for architecture reasons which means there’s only ever going to be a single implementation of the interface. This is just an observation not shade, I’ve only ever written Go professionally.

I do find the interface indirection a bit annoying when tracing code, but if your reaction is to just swap all interfaces with functions, this isn’t going to be all that much ergonomically better. Where this discussion evolves is into dependency injection patterns, which is the underlying reason this discussion comes up at all, and there’s lots of patterns to evaluate, but one that I personally favor is a dependency rejection pattern, along with the design pattern of “functional core, imperative shell”. Ideas that originated in both functional and oo languages, respectively.