если это opensource

no

а какой?

у вас автоисправление грам. ошибок?)

да, поэтому данная затея далека от прагматики

потому-что нет контекста? ))

думаю оно как минимум предложит

голанд и идея ругаются

значит не надо так делать 🙂 проблема решена (писать так, как не нравится линтерам)

😂

Спасибо. Теперь fasthttp тоже 20 секунд. А почему у net/http нет замедления при создании клиента каждый раз?

я не знаю. Знаю лишь что смысла так делать - нет

@antonikucherov вы тут много понаписали, по интерфейсам к чему пришли? Только действия типа «do something”er или все же интерфейсы для доступа к данным все же признали? :)

Потому как из инфраструктуры при сохранении агрегата все же удобно иметь интерфейс доступа к данным нежели экспортируемые поля :)

Не знаю, каждый остался при своем. Я исхожу из того как в английском принятно. Надо без er значит без er 🙂 Не вижу проблем. В том числе с идиоматичностью, что бы под ней не подразумевали. Я за здравый смысл в общем.

А как ты при сохранении агрегатов данные из них получаешь? :) интересно прост)

Ну и восстанавливаешь как, раз уж в эту степь пошли)

Более того, я не вижу принципиальных отличий между концепциями интерфейсов в разных ЯП (В том числе в Go). Отличия в деталях реализации и в том как их нужно использовать, я вижу, а вот концептуальной разницы в их областях применения нет.

потому что используется один и тот же транспорт — http.DefaultTransport

если вам интересное моё мнение, то я считаю так:

1. Предпочитать стоит более прагматичный подход. Грубо говоря, зачем нам корректный код, который читать сложно?
2. Даже в стд. библиотеке куча примеров того, как, всё-таки, делать, наверное, не стоило. Нежелательно опираться на ошибки прошлого в качестве оправдания плохого нового дизайна. Даже если кто-то когда-то допустил ошибку в стд. библиотеке - исправить её уже невозможно по причинам гарантии обратной совместимости.