From the post you responded to:
> you should be writing the concrete implementations first, then defining interfaces in the client code.
When you need to take an argument that you can swap out for another type, that's when you define your interface. Not earlier.
> Unit testing doesn't become irrelevant because you are using Go.
Unit testing doesn't become irrelevant because you don't architecture astronaut from the start. When you need to test, define an interface. But only the interface that you need when you need it.
> Just because Go is relatively new it doesn't mean software engineering best practices don't apply anymore.
By providing the client the ability to define the interface it removes the need to pretend you can plan for all circumstances upfront.
Instead, at the moment you need to be able to mock things, you make an interface and mock them.
That's not to say that you should never provide interfaces in a library, just that it's no longer the only option available.
I'm not sure why you think that unit testing becomes harder with this approach, because to me it seems far easier.
Unit tests test concrete implementation "units", so this is completely compatible with writing unit tests.
That makes it actually even easier to do unit testing, because for a narrow test you don't need to implement irrelevant methods.
Then how do you unit test your controllers in a web app? or anything that depends on a database connection without decoupling service and repository?
> Go is all about minimalism.
No, it isn't. It's your opinion about Go. Unit testing doesn't become irrelevant because you are using Go.
> you should be writing the concrete implementations first, then defining interfaces in the client code
That's not how you do test driven development via unit testing.
Just because Go is relatively new it doesn't mean software engineering best practices don't apply anymore.