My real world AWS sdk s3 experience: I have an uploader interface (I only needed to upload). The concrete uploader has the s3 code. The fake uploader has any custom result/err I need to test against.

No idea why you’re getting downvotes, seems like a clean way to do this.

Your code should accept interfaces, not the S3 struct.

Interfaces are light-weight, and it's okay to define an interface that is just the subset of functionality your code needs.

But this advice is kind of ridiculous in its unqualified form as you have presented it. If folks followed your advice, there wouldn't be an "io" package in the standard library. So why does it exist? Because it's damn useful to not define interfaces every single time you need them. It gets old real fast.

This is exactly what the GP is saying.

To take your point and run with it: in the face of evolving code, returning an interface from a function is actually more conservative than returning a struct. If you return a concrete type of some sort, then as you evolve your code, you are obligated to continue to return that specific concrete type. As your implementation of the function changes, you might want to return a different concrete type, but you are prevented from doing so. You either have to change the signature, which would break callers, or else you would need to grow that concrete type to handle all the possible ways in which it would want to represent its data.

I realize that this goes against the Go ethos of "don't think about the future; think about the now". Having said that, I don't understand why returning interfaces is seen as premature design while accepting interfaces is seen as reasonable and expected. Surely both can be examples of premature abstraction.

I'm certainly not saying that you should always return interfaces, or that returning interfaces will prevent all future refactoring pain. But working with interfaces instead of concrete types is more likely to allow your API to remain stable even as the implementation evolves.

> That makes it bloody hard to mock during unit testing.

Can you share why? Not trying to say you are wrong, but I am guessing that part of this stems from some limitations in the way interfaces work in Go, and this could make a good user experience report.

Agreed, would like to see a concrete example of why that advice is being given.