Golang в крупных проектах

Примеров перехода на Golang много. Но в основном это закрытые проекты:

— https://habrahabr.ru/post/273535/
— https://habrahabr.ru/post/172795/
— https://www.digitalocean.com/company/blog/new-super-fast-droplet-console-than...

Обратных примеров, когда уходили с Golang, пока, вроде, не встречал :)

Есть ли у кого-либо опыть использования Golang в столь сложных проектах?

Бекенд, 25К строк кода, 25 таблиц (число мало, поскольку мы на микросервисах и данные разбросаны). Сойдет?

Может ли кто-нибудь подсказать примеры столь сложных проектов с открытым исходным кодом?

Не видел

Есть ли у кого-нибудь веские аргументы не делать этот переход на Golang?

Есть проблемы, но в целом с ними жить можно и они устраивают. Питон по моему мнению хуже.

Может ли кто-то рассказать, как решить те проблемы, которые были мной выше описаны в Golang?

Ну, самая главная ошибка, которая возникала — хотелось больше «сокрытия реализации», поэтому сначала пытались разбивать все на кучу пакетов. Но, как известно, в go нельзя циклически импортировать пакеты и идея провалилась. Если посмотреть на даже больше опенсорц-пакеты — там тоже практически все находится буквально в нескольких пакетах. Это не неудобно, просто другой способ организации.

Структура проекта выглядит как-то так: http://storage5.static.itmages.ru/i/16/0921/h_1474438233_4783744_64393b43f3.png

Во-вторых, ORM. Используем gorm (https://github.com/jinzhu/gorm), и у него есть добрая куча проблем. В целом жить можно, но если упор на производительность, то я бы взял https://github.com/go-pg/pg (вроде, оно, точно не помню) и реализовать плюшки gorm поверх. Но с проблемами go-pg/pg я не знаком, поэтому точно сказать не могу.

Достаточно продвинутое ООП для реализации сложной логики

Продвинутое ООП != сложая логика. Придется использовать несколько другие паттерны, я полагаю. Сам не любитель терминального ООП головного мозга, поэтому с этим проблем не было.

Еще про микросервисы: из-за них по-полной сейчас огребаем с транзакциями (и из-за gorm тоже), но в целом жить можно. Деплой удобен, сервисы маленькие, поддерживаемые и независимые, правда, ядро у нас толстовато. В качестве шины используем grpc и nats, первый — зрел и прекрасен.

На качество гитхаболиб я бы не полагался — в целом они ужасно, ужасно жирные (за немногими хорошими исключениями), и чаше лучше реализовать что-то самостоятельно.

Возможность рефлексии в языке совращает, но лучше сразу копипастить/использовать кодогенерацию, поскольку это место придется переписывать. Но в целом с использованием interface{} проблем нет, я про более продвинутые случаи. Относится и к дефолтным json и protobuf-энкодерам — нужно заменять на версии с кодогенерацией для адекватной производительности (например, https://github.com/pquerna/ffjson).

Задавайте свои вопросы.

+ еще дополнения.

Для сборки используется gb и он ужасен. Из-за этого всё перенесли в один большой репозиторий с одним gb-проектом.

В GO нету ООП, вообще нету.. Технологии ? Какие? Все, что там есть вполне устоялось. ОРМ есть, тот же gorm, однако для меня понятия сложный, нагруженный противоречат слову ORM.

Что касается структуры проектов, тут все просто, смотри как пример тот же revel и юзай модули для его расширения. От того же Django или Flask слабо отличается.

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

Слабая поддержка ООП в языке

Я бы не сказал, что она слабая. Она нетрадиционная. И перетачивать мозги с привычного ООП может оказаться проблематичным.

Однако для меня понятия сложный, нагруженный противоречат слову ORM.

Суть в том, что нужно писать код, а не возиться с базовыми вещами, которые в ORM уже есть. Поди напиши ОС на языке ассемблера — можно, но не нужно. Так же с ORM.

Вместо бизнеслогики вы будете месить байты, го недалеко от сишечки ушел.

4.2

4.2

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

Гошники все такие. Вместо того чтобы решать настоящую проблему: «борьба с растущей нагрузкой», они считают ее «причиной» и быренько повязывают красные галстуки и бросают зигу дедушке. Срамота.

Есть проблемы, но в целом с ними жить можно и они устраивают.
у него есть добрая куча проблем. В целом жить можно
но в целом жить можно
На качество гитхаболиб я бы не полагался ... лучше реализовать что-то самостоятельно

Вся суть Go.

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

Где ты увидел это, клоун?

В ОП посте. Ты даже не придал этому значения, лол. Гошник, такой гошник.

В ОП посте. Ты даже не придал этому значения, лол. Гошник, такой гошник.

ОП в посте решает проблему «python нормально не может в многопоточность». Сколько не оптимизируй, ничего дельного в этом плане на пистоне не получишь.

Уважаемый ТС, если вы надеетесь, что на го будут писать инженеры, которые способны решать проблемы, то сильно ошибаетесь. Сейчас в наличии только оголтелая пионэрия.

Фишка orm, это абстракция над спецификой используемой бд, оптимизация суть использования этой специфики. Так что или «нужно писать код» или быстро.

Спасибо большое за ваш ответ!

Раз Вы уже так много написали, не могли бы Вы еще ответить, решается ли у вас как-то проблема с err != nil? Стали вы использовать в основном panic-и все-таки для обработки исключений или везде err != nil?

Бекенд, 25К строк кода

Для Го это очень маленький проект. Большая часть — боллерплейт и примитивные конструкции.

ОП в посте решает проблему «python нормально не может в многопоточность»

Ни один крупный проект не упирается в CPU по всей кодовой базе. А упирается в кривые руки. В среднем по больнице, руки кривее у молодежи, которая хайпит за го.

Фишка orm, это абстракция над спецификой используемой бд, оптимизация суть использования этой специфики. Так что или «нужно писать код» или быстро.

Не обязательно. Выше я показывал привязанный к постгресу ORM. Суть в объектной модели, т.е. работа идет с объектами и действиями над ними. ORM вполне может использовать спицифику определенной БД.

Большая часть — боллерплейт и примитивные конструкции.

Держи пятюню, брат, тоже наелся говна?

Ну, да. Писался полутора программистами за несколько месяцев.

Большая часть — боллерплейт и примитивные конструкции.

Всякий сгенерированный protobuf и затычки старался выкидывать.

не могли бы Вы еще ответить, решается ли у вас как-то проблема с err != nil?

Это не проблема. Нужно привыкнуть к этом, оно даёт классную возможность писать ужасно надежный код

Стали вы использовать в основном panic-и

Нет, не нужно и не рекомендуется. Паники не для этого.

Везде err != nil.

Держи пятюню, брат, тоже наелся говна?

Ну, мой опыт с го довольно позитивен, потому что пишем на нём малюсенькие демоночки типа 'взять из очереди сообщение и отправить в чьё-то апи, только делать это с 4к рпс'.

Для чего-то посложнее страшно юзать

Обратных примеров, когда уходили с Golang, пока, вроде, не встречал

А они есть. Обычно на раст.

https://medium.com/@robertgrosse/my-experience-rewriting-enjarify-in-rust-723...

Это конечно не готовый проект, но отзывы на HN и reddit не в пользу Go.

ядро у нас толстовато

Не могли бы Вы тут сказать подробнее? Что у вас является «ядром» и почему оно «толстовато»?

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

Микросервисы. Ядро — сервис, в котором находятся основные модели и админка. Собственно, из-за админки (http://www.qorkit.com) и толстовато: она прибита гвоздями к gorm и пустить это по RPC сложно.

Вы о чём вообще?

О других неуспешных попытках писать утилиты на go. Довольно неудобно пакетить и распространять, короче.

Ааа... А какие там проблемы? Он же в статику собирается.

На rust таких проблемы нет. Cargo сам все зависимости скачает и соберёт в статику. Одна строчка и всё готово.

Ааа... А какие там проблемы? Он же в статику собирается.

В сборке как раз.

Cargo сам все зависимости скачает и соберёт в статику. Одна строчка и всё готово.

Да тут так же. Но мейнтейнеры пытаются каждую из сотни либ опакетить отдельно и получают dll hell, lol.

По крайней мере, видел такие жалкие попытки.

А они есть.

Что-то я там не заметил ссылок на масштаб проекта. ИМХО, что-то персонального уровня... Ну и сам факт выбора Rust в качестве замены... :)

Начнём с того, что масштабных проектов на Go, не больше чем на Rust.

Ну и я говорил не о самой статье, а об отзывах. Хороших отзывов о Go там мало.

В сборке как раз.

В Go не бум-бум. Можно поподробнее?

мейнтейнеры

Мейнтейнеры чего? Дистров? Так это их проблемы.

Лорчую, всё так. Равзе, что у нас нету ORM и прост используем маппер на структуры.

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

плюсану анонимуса. медленный кусок переписать на го - ок, но не весь проект.

Начнём с того, что масштабных проектов на Go, не больше чем на Rust.

У Rust есть что-то масштаба хотя бы Docker? :) На Rust сидят инфраструктуры таких монстров, как DigitalOcean?

Ну и я говорил не о самой статье, а об отзывах. Хороших отзывов о Go там мало.

Пока это мнение отдельных пользователей — это субъективщина чистой воды. Таких негативных отзывов можно найти сколько угодно по абсолютно любому языку :)

О других неуспешных попытках писать утилиты на go. Довольно неудобно пакетить и распространять, короче.

В последнее время всё больше утилит именно на Golang встречается. Он всё активнее встречается там, где раньше работал Python.

В сборке как раз.

А чего там с ней ? Мне пока что только это и подкупает в Go, что я могу без заморочек собирать в один бинарник. В отличие от того же питона, где без pip-а сторонние библиотеки ставить целая проблема. (Оче полезно когда один из рабочих компов (основной) без интернета, а на серваках даже не везде питон установлен)

Ещё доставила работа с потоками. Давно пора научить языки создавать потоки по простенькому ключевому слову, а не городить системы пулов, какие-то там объекты с определенными методами и тд. Но вот в плане скорости я пока что не заметил прироста. Я конечно же написал пару hello world-ов, но вот запиханые в горутины GET-реквесты выполнялись в 4 раза дольше чем, аналогичные в python 3.5 + aiohttp

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

не городить системы пулов

с рутинами медленней

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

Вся суть Go.

Вся суть X. Работать с чем-то и не видеть недостатков == быть фанатиком.

Если у вас там

борьба с растущей нагрузкой

, то

переписать всю систему на

— просто акт идиотизма.

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

Всего база данных состоит из ~200 таблиц. Т.е. это проект с достаточно сложной бизнес-логикой

Я вас огорчу: двести таблиц это детсадовская херня. Сложная бизнеслогика это от десяти тысяч.

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

На Rust сидят инфраструктуры таких монстров, как DigitalOcean?

Dropbox?

Не спорю, но в данном случае имеет место процент недостатков.

Dropbox (по крайней мере, на момент нагугленной записи) в основном на go сейчас, только некоторые сервисы на rust'е.

ну само собой, Hello world же на реддите мне по этому поводу сказали только не замерять скорость time (будто я своими глазами не вижу разницу, хех)

Есть пара проектов крупных проектов, написанных на Go:

https://github.com/kubernetes/kubernetes https://github.com/docker/docker

И? Раз уж они доверили ему ключевые компоненты, то наверное это о чём то говорит.

1) для больших и сложных проектов go не берут. по крайней мере, не в моей конторе. небольшие тулзы/сервисы, где куцость го не столь страшна

2) работающие проекты именно из-за нагрузки переписывают редко, просто добавляют сервер и балансируют нагрузку

3) в случае второго питона можно было бы поэксперементировать с pypy и pyston. pypy есть и для третьего питона, но работает оно медленнее, чем для второго

У Rust есть что-то масштаба хотя бы Docker

Ну куда же теме про Go без Docker'a. Других проектов правда нету, но ничего.