это в смысле не оборачивать функцию в функцию только ради вызова функции, а просто создать алиас и не страдать ерундой

Интерфейсы в сущности своей в других ЯП имеют то же назначение что и в Go. Разница только в деталях реализации (В Go например они разрешаются неявно). Из-за этого вам не нужно возвращать их везде, потому что компилятор сам понимает, когда структура реализует интерфейс. Но если моя задача - скрыть детали реализации, я буду вынужден вернуть интерфейс.

значит вы не совсем поняли идею

Не уверен, что для этого нужно возвращать интерфейс. Для этого достаточно корректно разграничить приватные и публичные методы.

ну расскажи, чем вызов функции из другой функции без какого-либо изменения входных или выходных параметров, будет отличаться от алиаса, кроме увеличения длинны стэка?

на самом деле - у нас интерфейсы могут и должны использоваться как инструмент decoupling

но на пракктике есть проблемы :)

и даже стек, скорее всего, не пострадает, оптимизатор выпилит прослойку

https://github.com/google/exposure-notifications-server/tree/master/internal/storage вот гляньте на этот пакет.
Посмотрите что возвращает каждая реализация Storage. Она возвращает интерфейс Blobstore.
И я не вижу здесь никакой проблемы.

Никакой проблемы, если фабрика параметризуема и в зависимости от параметров возвращает разные объекты, удовлетворяющие единому интерфейсу.
Мы скорее про привычку возвращать интерфейс там, где можно обойтись структурой.

Спасибо!

С этим я согласен, но почему то на это акцент никто не ставит. Как итог очень часто правило "Возаращай структуры" возводят в абсолют и руководствуясь им начинают священную войну. Я поэтому и сказал выше, что это всего лишь рекомендация. не нужно воспринимать ее буквально.

В том, чтобы возвращать интерфейс, проблемы как таковой нет. В некоторых случаях иначе никак бывает. Просто надо понимать, что возвращая интерфейс вместо реализации, мы просто лишаемся гибкости в некоторой степени. И никогда заранее не угадаешь, где и когда эта гибкость может понадобится. Поэтому и существует эта _рекомендация_ - по возможности всегда возвращать реализацию. В общем случае минусов нет, зато плюсы есть.

Вот тут я совсем не понимаю, объясните, какой гибкости? Возвращая интерфейс, на мой взгляд мы наоборот получаем гибкость, т.к. можем подменить его любой реализацией (не нарушая контракта). Все чего мы лишаемся, это грязных хаков и говнокода, когда мы возвращая везде структуру, в какой то момент захотим таки нарушить контракт и дернуть оттуда деталь реализации которую не должны дергать напрямую. Потом мы дернем в другом месте другое поле структуры, а потом третье, и так далее, пока код не превратится в лапшу.

ну во-первых, вызов конструктора не сильно-то создаёт проблемы с временем выполнения программы
2) если мы говорим о пакете, как о реализации конкретного сервиса, то с чего бы использующим этот код нужно заглядывать внутрь и искать какие интерфейсы он реализовывает
3) для чекалки полноты реализации интерфейса обычно юзают хаки типо var _ = NewIncrementer(newIncrement), а тут всё и без этого работает

Если в месте использования объявляется свой интерфейс, то да, не теряем. Однако обычно завязываются на интерфейс, предоставляемый вами, пишут под него моки для тестов и прочее, что увеличивает связанность.

интерфейс определяется в месте использования, если ваша функция возвращает интерфейс вместо реализации, то эта функция не сможет быть использована в другом пакете например где определяется свой интерфейс по месту использования.

А ещё если твоя структура реализует несколько интерфейсов - другие интерфейсы теряешь просто.

В месте использования еще не означает "обязательно в кодовой базе клиента (использующего интерфейс)". Пример тому любая реализация IoC, например интерфейс http.Handler.

в месте использования означает там где непосредственно используется

Кем?