GoLang что почитать чтобы норм вкатиться?  Публичный пост

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

На текущий момент как web-фреймворк присмотрел Echo. В целом норм, но есть вопрос как там масштабироваться. Имею тяжелое прошлое ввиде java/spring. По этому подумал про DI. Нашел аж два от убера dig и от google wire. Вроде как wire более нативно. Или все же лучше как-то более просто квадратно гнездово? Предложения других фреймворков тоже рассматриваются с аргументацией почему лучше взять N вместо М. Buffalo если что смотрел. Что-то тяжеловато. Хочу полегче.

Как ORM присмотрел GORM. Норм или есть что получше?

Для конфигов взял viper. Норм? Или лучше взять другое?

В качестве управление зависимостями взял go modules. Нативно и работает. Или у него есть фатальный недостаток?

Ну и да какой-нибудь текст делай в go так, а не так приветствуется, а то я щас как налабаю как в жаве. :)

Связанные посты
19 комментариев 👇
Andrey Shinkevich, Software craftsman 6 июля 2020

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

  • DI контейнеры и прочая радость подобного рода вообще не очень принята, очень мало кто исользует wire. Если тебе нужно от чего-то зависеть – напиши интерфейс. Интерфейсы кстати тут притяно объявлять часто ближе к месту использования, а не к месту реализации из-за неявного удовлетоврения. Ещё одно популярное правило, чем меньше интерфейс тем – лучше. Проще переиспользовать и делать композицию, интерфейсы с одним методом очень популярны в стандартной библиотеке.
  • ORM. Опять же, тут предпочитают более прямой контроль и использовать SQL билдеры. Самый популярный наверное: https://github.com/Masterminds/squirrel. Да и не забывай что тут нет всех этих нагромождений ООП фич, и такие вещи как Hibernate тут в принципе не нужны. Да и ORMы вообще не любят, сложно контролировать что тебе он там сгенерит за запрос. Если нужны круды для реста, то порой используют кодогенерацию.
  • HTTP: в стандартной библиотеке есть уже интерфейс для Http хэндлера, тебе врядли нужен полноценный веб фреймворк, скорее простой роутер, чуть более умный чем стандартный ServeMux из net/http. Похоже сейчас популярен: https://github.com/gorilla/mux. Echo не так много кто использует да и полноценных веб фреймворков тут вообще почти нет и их используют какие-то маргиналы.
  Развернуть 1 комментарий

Кратко. Это печально. Но ничо аннотации и генерики втащат. Все там будем.

ORM педалит когда у тебя 100500 CRUD. Крайне утомляет писать кучу билдеров. Типа LINQ есть что-то? Он больше должно тут подходить.

Про интерфейсы есть какой-то типа норм пример делай вот так будет хорошо. Или все колхозят как придется?

  Развернуть 1 комментарий

Господи, как всё это приятно звучит. Теперь точно Go попробую.

  Развернуть 1 комментарий

@ngrishanov, на самом деле на длительном забеге это генерирует больше проблем, чем пользы. Тот же go modules лишь недавно вкатился в mainline. А до этого я с большим ведром попкорна наблюал драму go и версии модулей.

  Развернуть 1 комментарий

@norguhtar, LINQ тут в принципе невозможен в С# понимании с построением деревьев выражений с помощью примитивов Where, Select, etc... В go нет итераторов и не будет, интерфейсы вроде IEnumerable из шарпа тут тоже никак не сделаешь эффективно соответственно, поэтому умная работа с коллекциями – это не Go-way. Поэтому если, люблил джавовые стримы (хотя стримы в джаве не очень то хорошо и реализованы, но не суть) то будешь страдать, покуда не постигнешь философию Go в лице циклов, копипасты и if err != nil через каждые три строчки. Я тоже долго с этим не мог мириться, но потом кажется понял дзен.

  Развернуть 1 комментарий

@norguhtar, угу, и в принципе заметна многсловность языка. Когда перекатывался из перла в го, а мутило от того, что пара перловых строк занимает десятки в го. Потом, видимо, свыкся. Сейсчас даже глянув на питонячий код удивляюсь его компактности и емкости лол.

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

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

  Развернуть 1 комментарий

@Foxcool, многословность языка тут следсвие упрощения. И да это вы код на C не писали. По сравнению с ним код на Go короток и ясен.

Но да абстракций кое-каких для больших приложений не хватает. Из-за этог процветает велосипедостроение вместо возьми либу N. В дальнем забеге это как я и говорил худший вариант. Но тут как с PHP в определенный момент все втащат.

  Развернуть 1 комментарий

@norguhtar, По поводу "всё втащат", я бы не радовался раньше времени. Очень много пропоузалов и идей просто откролняют, т.к это не "Go-way". Да и дженерики в Go очень специфичные получатся, своеобразные. Например, аналог "IComparable" в качестве ограничения дженерик типа, который бы одновременно покрывал и примитивные типы и кастомные типы не сделать без хаков.

  Развернуть 1 комментарий

@ashinkevich, меня тут больше даже нормальные аннотации интересуют, чем генерики. Они больше профита дают

  Развернуть 1 комментарий
Andrey Shinkevich, Software craftsman 6 июля 2020

А по поводу "что почитать".

Почитать:
- у Go очень хорошая стандартная документация.
- Effective go с оф сайта. https://golang.org/doc/effective_go.html В духе делай так и почему.
- Memory model in go: https://golang.org/ref/mem
- Сoncurrency in go от O'Reilly. Мне очень зашла, от базовых понятний конкуретности до различных паттернов: https://www.amazon.com/Concurrency-Go-Tools-Techniques-Developers/dp/1491941197
- Блог Дейва Чени, ну и его сборник как лушче писать на Go, ссылку тут уже давали: https://dave.cheney.net/practical-go


Посмотреть:
- Выборочные доклады с https://www.youtube.com/channel/UCx9QVEApa5BKLw9r8cnOFEA/videos
- Канал Good reviewer - Bad reviewer. Там code reviews с разбором разных кодовых баз, как с Go так и растом: https://www.youtube.com/channel/UC8_A5W8g7UV0pk0uL66iQAQ/videos

  Развернуть 1 комментарий
Alexander Babenko, Либертарианец, блогер, архитектор ПО 6 июля 2020

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

Т.е. не нужно до освоения собственно поставки результатов длоя бизнеса бежать везде пихать DI, Репозитории с генераторами запросов и прочие вещи. Сначала нужно в голове освоить конвейер поставки сервисов и новой функциональности, а уже потом оптимизировать проблемные вещи и внедрять те паттерны, которые себя окупают. Тот же репозиторий вполне ок, если велика вероятность замены БД, а стоит недорого. Всратые нерды пишут обертки на все ради мнимой цели потом добиваться 99% покрытия моков юнит-тестами. На деле адеватный лид или архитектор это присечет, а если не присечет, то сраный круд будет выглядеть как нечто неподдерживаемое и слабо понятное.

Го простой ЯП: сначала осваиваем простые вещи и учимся приносить пользу, потом оптимизируем, а не наоборот. Сервис-ориентированная архитектура тем и хороша, что тут нет огромной цены ошибок: даже крупноватый сервис можно полностью переписать в обозримые сроки (А монолиты на го я, честно говоря, уже не очень представляю). А в бизнесе это может и не понадобится даже. Т.е. не надо переусложнять и оверинжинирить простые задачи.

  Развернуть 1 комментарий
Anton Zobnin, Go Developer на пути к Data Engineer 6 июля 2020

Советую почитать статьи в блоге Дейва https://dave.cheney.net/practical-go

Его мнение в целом отражает мнение го коммьюнити

  Развернуть 1 комментарий

Во положу в закладки на почитать.

  Развернуть 1 комментарий
Alexander Babenko, Либертарианец, блогер, архитектор ПО 6 июля 2020

В целом согласен с @ashinkevich.

На голанге как правило работаем в сервис-ориентированной или микросервисной архитектуре. Соответственно, твой сервис скоре всего будет общаться с внешним миром через API или очереди сообщений.

Могу порекомендовать пзнакомиться с кодогенерацией: например, лучший вариант - описать апи специкацию с помощью опенапи и генерировать код генератором https://github.com/Foxcool/homework/tree/master/5-kbs-crud

Таким образом получаем четкую привязку кода к контрактам и не тратим время на бессмысленное ручное написание валидаторов и прочего иф кода.

Вайпер - норм тема. В примере выше можно посмотреть, как там описывать параметры конфигов.

По орм да, скорее перспективнее тема с генераторами кода, чем с орм (очень сложно дебажить ошибки было в том же ГОРМ, а по гибкости и мощности все равно не сравнится с ОРМ у динамических ЯП). В целом практика говорит о том, что если сервису не нужно опеспечивать транзакционность, то тащить РСУБД и потом мучаться с миграциями в плеяде сервисов не стоит.

  Развернуть 1 комментарий

У кодогенерации есть проблема. Как добавлять новые path в API. Или там эта проблема решена?

  Развернуть 1 комментарий

@norguhtar, сгенерированный код нет смысла править. Добавил в спецификацию новые методы и перегенерировал. В папке с хэндлерами создал функции нужные.

  Развернуть 1 комментарий

@Foxcool, ну я могу генерировать допы, по текущему коду или перепишет? И надо отдельно копировать свою реализацию после генерации?

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб