Люди, подскажите, как выглядит распространённая практика размазывания кода по файлам. Будет много пакетов, хотелось бы как-то структурировать. К примеру, где хранить интерфейсы, структуры, методы?

Водопад

Водопад

А поподробней?

А поподробней?

если возник такой вопрос, то приходят в голову два варианта. Либо вы переписываете что-то на Го, либо только учитесь использовать Го. В обоих вариантах вы с ходу не заложите идеальной структуры хранения. Подумайте заранее какие запчасти вам нужны в нескольких сервисах и вынесите их в отдельные пакеты.

В целом водопад - waterfall - подход итеративного развития идеи

или разработки

если возник такой вопрос, то приходят в голову два варианта. Либо вы переписываете что-то на Го, либо только учитесь использовать Го. В обоих вариантах вы с ходу не заложите идеальной структуры хранения. Подумайте заранее какие запчасти вам нужны в нескольких сервисах и вынесите их в отдельные пакеты.

Учусь, 4 день чидаю.

Учусь, 4 день чидаю.

тогда начните с 1 файла

чтобы компилилось, запускалось

потом усложнять будете, и от задачи обдумаете как луче разнести

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

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

я конечно могу повторить, но не буду. Предложу вам другой путь. Зайдите на гитхаб и поищите популярные репы с Go проектами.

посмотрите как там организован код

Кстати тоже интересует такой вопрос, тоже новичок. Встречал и два подхода: в одном все разбивают на разные пакеты и складывают в директорию pkg, в другом просто "традиционно" раскидывают все по папочкам, но я так понимаю это антипаттерн

вариантов и подходов много

Да, я уже подумал об этом, спасибо.

Кстати тоже интересует такой вопрос, тоже новичок. Встречал и два подхода: в одном все разбивают на разные пакеты и складывают в директорию pkg, в другом просто "традиционно" раскидывают все по папочкам, но я так понимаю это антипаттерн

не хочу поднимать волу, но как по мне, выносить по "папочкам" надо крайне аккуратно и только если понимаете зачем это делаете.

не хочу поднимать волу, но как по мне, выносить по "папочкам" надо крайне аккуратно и только если понимаете зачем это делаете.

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

но я понимаю зачем и почему я это сделаю, и это точно не ради самой папочки

сначала все-таки задача, потом ее решение

успехов в бою) го рулз)

Короч предлагаю метод какашки - сваливаешь весь код в одну кучу, потом если понадобится - рефакторишь :)

Всем привет! Подскажите пожалуйста, как можно лучше решить эту проблему: Есть такой почти псевдо код (проверки ес-но на err есть, для примера убрал): var positionChange actions.PositionChange // это структура json.Unmarshal(data, &positionChange) var orderCreated actions.OrderCreated // это структура json.Unmarshal(data, &orderCreated) и такого копипаста ввиде json.Unmarshall.... err != nil предвидится очень много. Как можно копипаст свести к минимому, учитывая что данные структуры унаследуются от одной общей. Как можно красивее код написать? В Джаве прям напрашиваются генерики. А в го каким путём лучше пойти тогда?

путем копипасты. а если их реально много - путем кодогенерации

путем копипасты. а если их реально много - путем кодогенерации

копипаста - лень. Кодогенерация, каким образом? Мб есть уже готовая реализация, не подскажете в какую сторону капнуть?

я вот с помощью text/template генерирую, а исходник описываю в yaml.

но это когда у меня 400 структур с полностью однотипной обработкой

жесть)

у easyjson красиво сделана кодогенерация

в отдельный файл помещается, добавляет методы

можно там чтото почерпнуть

но готовых генераторов нет - да и откуда им взяться

но готовых генераторов нет - да и откуда им взяться

https://github.com/dc0d/goreuse/blob/master/README.md

Недавно для себя открыл

это, конечно, совсем не то, чего хочется.

хочется темплейтов, хотя в том виде, в котором они есть в яве, и генератора кода на их базе

хочется темплейтов, хотя в том виде, в котором они есть в яве, и генератора кода на их базе

темплейтов в смысле для текста или темплейтов в смысле дженериков?

но эта задача, насколько я понимаю, не решается на уровне текста, тут надо язык понимать

я уже говорил, но повторюсь, я больше страдаю от отсутствия типов-сумм (

да есть от чего пострадать, так-то :)

Где посмотреть, как устроена мапа внутри го? Я имею в виду исходный код

в гугле

Где посмотреть, как устроена мапа внутри го? Я имею в виду исходный код

исходники го не дают с официального сайта скачать? )

да, я нашел уже

спасибо

https://play.golang.org/p/JAf0H8qgxIl Народ, а вот кто как бы реструктурировал такой код? покритикуйте пожалуйста с одной стороны можно конечно декомпозировать на несколько функций, но тогда придется return err делать в этих функциях и делать return чтобы сработал defer в основной =) я понимаю что CH не транзакционный но я просто хочу подобный подход применить для транзакционности в PgSQL и MySQL в дальнейшем

Друзья, насколько правильно данное решение - мап функций с ресивером https://play.golang.org/p/zGcPYPkeNbx

нормально, только непонятно, зачем

Мне удобно хранить функции в мапе чтобы по string key их вызывать

чтобы что?

ну вот реально - чтобы что?

у тебя этот string key откуда то снаружи передается?

ну вот реально - чтобы что?

Чтобы не делать switch 😅

у тебя этот string key откуда то снаружи передается?

Да

Чтобы не делать switch 😅

свитч будет быстрее

свитч будет быстрее

Lookup в мапе О(1)

и проблемы будут отловлены при компиляции, а не при работе

и проблемы будут отловлены при компиляции, а не при работе

Я проверяю если нужный метод есть и если нету то отвечаю клиенту ошибкой. Если есть, то он достаётся из мапы и исполняется. Быстрее ведь чем свитчом?

медленнее

Поясните пожалуйста почему, если не сложно.

инструкция в коде скомпилирована, а залезть в мапу - это динамисческий доступ

инструкция в коде скомпилирована, а залезть в мапу - это динамисческий доступ

Мне казалось switch будет сравнивать в стиле ==

да, он при этом не лезет в переменную типа мап

да, он при этом не лезет в переменную типа мап

Но ведь медленнее сравнить 20 раз чем один раз посмотреть в мапе (?)

вряд ли, это в коде выглядит коротко

Хм, чот фигня какая-то, ЧЯДНТ? gox -build-toolchain Программа 'gox' на данный момент не установлена. Вы можете установить её, выполнив: sudo apt install gox

Но ведь медленнее сравнить 20 раз чем один раз посмотреть в мапе (?)

Сделай бенчмарк и поделись :)

Интересно, какие значения будут

Да

снаружи в смысле за пределы процесса?

Сделай бенчмарк и поделись :)

Я думал может у кого уже есть опыт )

Что быстрее - свитч на 100 кейсов или мапа с функциями

существенной разницы быть не должно

но немножко выйдет вперед свитч

Я думал может у кого уже есть опыт )

единственный вариант map[string]func оправданный это только если string передается откуда то снаружи процесса

но немножко выйдет вперед свитч

Почему?

Хм, чот фигня какая-то, ЧЯДНТ? gox -build-toolchain Программа 'gox' на данный момент не установлена. Вы можете установить её, выполнив: sudo apt install gox

ну а вот написано (по-русски) что gox не установлен. он что, установлен?

потому, что смещение для джампа задается статически, и, скорее всего, соответствующий код будет в кеше

Что быстрее - свитч на 100 кейсов или мапа с функциями

что-то близкое к твоей теме https://hashrocket.com/blog/posts/switch-vs-map-which-is-the-better-way-to-branch-in-go

ну а вот написано (по-русски) что gox не установлен. он что, установлен?

Да я уже понял)) Странно. почему через go get ведь поставилось, да и в свежести пакета в убунте были сомненья.

Да я уже понял)) Странно. почему через go get ведь поставилось, да и в свежести пакета в убунте были сомненья.

$GOPATH/bin есть в $PATH ?

$GOPATH/bin есть в $PATH ?

go env GOARCH="amd64" GOBIN="" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/home/marlik/go" GORACE="" GOROOT="/usr/lib/go-1.9" GOTOOLDIR="/usr/lib/go-1.9/pkg/tool/linux_amd64" GCCGO="gccgo" CC="gcc" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build418155158=/tmp/go-build -gno-record-gcc-switches" CXX="g++" CGO_ENABLED="1" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config"