Статьи на эту тему чаще всего пишут: "а вот приходится писать строчки кода, а где Dry, а где Kiss, а где ООП, а почему все процедурно, а где моя простата" – но это (меня недавно научили фразой) "пердеж в лужу"

Есть реальные причины почему Go считают языком для "слабых разработчиков" и 2 основных пункта это:

– Отсутствие memory management
– Отсутствие управления конкуренцией (вы можете делать это кодом, но на том уровне, на котором разрешил Go)

То есть, Go-разработчик может абсолютно не думая написать приложение, которое будет простое и быстрое по IO, но не сможет довести его до "идеала"

Так ведь это блин ахуенно!

Я обожаю Go за его главную фишку – строгость и границы позволяют junior / уставшему / пришедшему из другого языка разработчику написать приложение, которое будет 10х быстрее и оптимальнее по ресурсам, чем если бы он написал его на любом другом языке и при этом код будет понятен аболютно всем

Однажны я пришел тим лидом в команду из 5 человек, где все кодили всего 1 год и смогли написать приложение, которое имело десятки тысячь активных пользоветелей (новостная лента + чат) и при этом им вообще не приходилось задумываться о скорости или потреблении ресурсов, Go сам все делал за них

Когда я наладил процесс разработки, мы начали выкатываться раз в 1-2 недели вместо каждых 2-х дней к моменту деплоя сервисы начали "тупить". Метрики сервера показали, что Ram и CPU в норме, но на нем было открыты миллионы дискрипторов. Оказалось что ребята просто не знали, что нужно закрывать дескрипторы вручную (!!!) и поскольку деплоились через день, дескрипторы каждый раз падали в ноль и проблемы не было видно

Вы представьте: Go способен был жить неделями при многотысячном RPS и такой "ну открыто миллионы дескрипторов и открыто"

И у нас небыло никакого куба и подобного: все микросервисы просто раскрыты на нескольких тачках по 1-2 инстанса на docker-compose и ansible book для редеплоя

Все

Возможность супер-просто и быстро написать понятное и быстрое приложение, имея всего 2 извилины – это лучшая фича для любого языка программирования

Ко всему прочему вы можете контроллировать аллокации в Go на очень многих уровнях, даже написать и использовать свой malloc и free-list

Но это опишу в другом посте

для серверлесс есть knative, мой фаворит платформенного стека такой:
Cloudflare
Kubernetes
Knative
Istio (knative required)
TriggerMesh stack

А как там с cold start? Потому что это основная боль всех serverless решений на докер образах

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

Оставь один инстанс всегда работать и будет всегда горячий. Холодный только у cloudflare workers действительно быстрый, но это закрытые коммерческие решения

и при этом им вообще не приходилось задумываться о скорости или потреблении ресурсов, Go сам все делал за них

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

Когда у тебя задача обработки 10-100 000 IO операций, где ты принимаешь что-то на вход, модифицируешь по бизнес-правилам и отправляешь дальше в другой IO (базу, кэш), можно, конечно, написать это на языке, в котором есть memory management, только работать с памятью придется не потому что "нам нужна скорость аллокаций", а потом что по-другому такой код не напишешь

Тоже самое с CLI утилитами и даже нативными приложениями (за хранилищем обращаются в нативные прослойки)

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

Стоит стараться следить, чтобы все лежало в стэке (а go имеет уже встроенные анализаторы кода, которые подскажут что будет в стеке, а что попадет в heap) и для этого в Go есть куча разных подходов и структур

Поэтому да, можно написать backend, cli или нативку например на C, но только времени потратиться во много раз больше, придется кучу времени дебажить случайные ошибки работы с памятью и при этом ты вряд ли получишь что-то больше, чем если бы просто сделал на Go и если 1 инстанс не справляется (а это миллионы активных коннектов) раскрыл бы еще один (причем даже ручками)

Обратная ситуация, когда тебе нужно оптимизировать по памяти: например, у тебя есть ограничение в этой памяти (микроконтроллеры) или ты пишешь систему, которая завязана на памяти (БД, кэш), тогда вопросов нет, нужен management памяти

«Я обожаю Go за его главную фишку – строгость и границы позволяют junior / уставшему / пришедшему из другого языка разработчику написать приложение, которое будет 10х быстрее и оптимальнее по ресурсам, чем если бы он написал его на любом другом языке и при этом код будет понятен аболютно всем.»

А это похоже никто не используют, в вакансия 3+ лет на Go почти всегда. 😁 Так что может этот довод не верный?

А существует серверный язык, на котором почти всегда набирают с годом опыта?)

Ко всему прочему, я говорю из реальной практики: люди или начинали с Go, или были мидлами в другом далеком от скорости или типизации языке (Ruby, Python) и пересаживались на Go и их код был как минмум достойного уровня при достаточно высокой скорости и оптимизации по ресурсам

это так. Видел питонячьи комманды которые перепесывали сервис за несколько месяцев когда бизнес начинал идти хорошо и упиралось в производительность.

Хотя некоторые, ты хорошо его знаешь, говорят что когда начинают упираться в производительнотсь питона это не из за языка, а из-за базы - тупит она. @davidshekunts как ты смотришь на такой коментарий?

Во-первых, я всегда говорил: данные важнее кода

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

Если правильнее выносить данные в сторонее хранилище, выбирай подходящее хранилище

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

Когда реальность покажет что ты не увидел и где ошибся оптимизируй, рефактори и меняй И тут всегда надо смотреть на месте производительность чего именно идет по жопе: система работает долго потому что ждет коннектов до БД, или сами запросы идут долго? Что у вас с показателями Memory, CPU и коннекшенов на железе базы и сервисов? Что у вас с задержками итераций самого кода (Event loop на Node.js и stop-the-world GC на Go)? Что у вас с memory leak?

И уже в совокупности надо решать вопрос

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

Сейчас напишу пост о причинах перехода с Node.js на Go и опишу там пример когда именно производительность становится причиной перехода

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

оптимизации также оптимизациям рознь.

О вот это интересно!

Тогда два вопроса:

- Что именно значит отвратительно?

- Какой язык ты предпочитаешь вместо Go?

P.S.

Для любого человека любой язык может быть отвратительным, я это отлично понимаю

Мне интересно что именно тебе не нравится

А в Го многое может не нравится)

1. низкоуровневые вещи мешают с высокоуровневыми (выразительных средств не хватает для хороших, обобщенных абстракций)
2. подход «собери все сам» работает в го плохо. отсутсвие главенствующего фреймворка, конвенций, не самый простой клей и отсутсвие четких подходов вместе с несколько проблемным менеджментом зависимостей (тут не то, чтобы вкусовщина, просто есть где это сделано хорошо - Cargo или Lein, например).
3. инжереная культура кода. да, тут у ребят обычно все хорошо со знанием базы и они предпочитают прям вот фигачить как есть. тут и сложное тестирование (подгтовка окрудения, см 1 пункт), и любовь к преждевременным оптимизациям, и забивают на другие процессы, вроде документации (фиксится в крупных компаниях, но для них го обычно как раз хороший выбор, для фигачки микросервисов и тулзов для инфраструктурной части)
4. из всего этого выливается боль в сопровождении кода - фичи релизятся долго (даже с Rust’ом лучше - при том, что он намного низкоуровневее и из другой оперы + нужно быть «умнее» - выше порог входа, да)
5. головная горутина разрабочиков ))) - везде и все на го-блоках.

сам предпочитаю clojure :D, хотя пишу в основном на ноде. как раз для fatigue driven development Clojure топ!

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

1. Можешь дать пример? Не совсем понимаю "низко" / "высокоуровневность" и "обобщенные абстракции" в данном контексте

2. "Главенствующий фреймворк" – дело вкуса, я как раз ЗА подход "научись на фреймворк, а потом собери все сам", потому что чаще всего чем больше фреймворк дает, тем намного больше он забирает.

Отсутствие конвенций? О каких конвенциях речь? Дело в том, что в Го их как раз очень много

"несколько проблемным менеджментом зависимостей" – я кстати выпал из Го на 3 года и вернувшись импорт по ссылке репы и go vendor меня полностью удовлетворили, какие в нем остались проблемы? Я помню, что что-то было не так, но не помню что именно

3. Имеешь ввиду документацию кода приложения или кода библиотеки? Если про второе, то пока ни разу не видел кодовой базы без нее, если про первое, то я всегда придерживался тактики "код должен быть самодокументируемым" и этой технике достаточно просто следовать на Go из-за максимальной прямолинейности ("тупости") кода

Про преждевременные оптимизации – в данном контексте я вижу, что речь идет не о конкретных индивидах, а про Go-коммьюнити в целом, поэтому хочу уточнить примеры преждевременных оптимизаций, которые свойствены Go коду? Мне интересно, что можно преждевременно оптимизировать в процедурном языке с GC и конкуренцией из коробки на Scheduler (до которых доступа напрямую у разработчика нет)

4. Очень интересный пункт, на моей личной практике и с тем, с чем я сталкивался в media на Go как раз можно очень быстро написать и зарелезиться, а в дальнейшем сопровождать код (потому что там самый минимум магии и 2 самые сложные темы взяли на себя GC и Scheduler)

5. Да, несомненно когда даешь что-то разработчику он с гигантским удовольствием этим злоуботрбит) Но с наличием async preemption даже если сделать перебор в горутинах сам scheduler не позволит им работать секциями более 10-20 мс, поэтому в итоге твой код останется максимально бысрым (такого я не видел из коробки в других языках)

Ого, я Clojure вообще ни разу не трогал) Круто) А можешь написать пару классных фич Clojure? Интересно с точки зрения дизайна языка

Переписывать на Rust – хороший вариант, если нравится Rust

1. фигачим голый sql, фигачим голые json для эластика и пр. никаих ds
2. конвенций как раз «как собрать свое быстро и хорошо». опять же у меня есть пример clojure и elexir (но там феникс уже победил).
3. вытекается из пункта 1
5. тут в целом все ок

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

cloJure 😄

Вот топ для мения лично:
1. Интерактивная разработка (ОЧЕНЬ МОЩНЫЙ REPL) - совсем иной способ писать код
2. Либы написанные 10 лет назад все еще актуальные и рабочие (язык с момента написания не поменялся)
3. Открыто-скрытая многопоточность (future, core.async - оч похоже на goрутины и каналы, только на макросах, не надо ничего тащить в язык)
4. Примитивы синхронизации и STM
5. Расширяемый язык (мета-языковые абстракции) и практика написания DSL
6. Очень просто писать «клей» между библиотеками (все предпочитают работу с иммутабельными структурами, а их проще всего дружить)
7. Это лисп (со всеми прелестями и к тому, что многим будет сложно, а кому-то невозможно привыкнуть)

Ну и для меня clojure это немного язык-фильтр как раз, с кем мне будет кайфово быть в команде, а с кем мы по ценностям не сойдемся. Вот go также :D, я вряд ли сойдусь по ценностям в работе и в практиках с большенством go-разрабов, которые готовы все переписать на go.

1. Вот тут мы и разошлись) Я как раз в целом за фигачить голый SQL, НО с заранее (xo) или постфактум интроспекцией (sqlc) и как раз против абстракций в ввиде Data Source / Repository

Вот здесь я описал почему

2. Понял, да эту роль на себя для новичка будут брать курсы (качество которых достаточно высокое), а для более продвинутого разработчика возможность посмотреть open source проекты (коих на Go ооочень много)

3. Преждевременная оптимизация засчет голого SQL кода? Тут больше про выбор отсутствия абстракции, которая как раз-таки дает возможность написать более "конкретно" (что = оптимально), чем "универсально", не потеряв в понятности и выразительности

5. В чем именно выражается coloring?

Про поддерживаемость: для меня это соответствие вот этим пунктам и Go соответствует им лучше других языков из-за своего дизайна

Но опять же, лично я вижу, что у нас просто разные подходы и разные вкусы, вот и все)

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

Поправил на "clojure")

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

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

Ну вот ты сказал и да, я вспомнил когда однажды я пришел в команду и весь сервис был написан в 1 огромный файл с битовыми операторами вместо == ||

Но там была проблема скорее в том, что человек чисто С-шник и ему сказали "сделай сервис с массивным IO" и ему ничего не оставалось как взять Go и начать писать)

В целом, я бы сформулировал так – это как с армянами (я один из них): московских армян я могу понять, ереванских впринципе тоже, а вот сочинских боюсь как огня

Вот люди пришедшие в Go из Python, Ruby, Java, C# или с нуля чаще всего какой-то нормальный уровень абстракции будут держать, а вот C-шники которым нужен IO (от неимения близких к C альтернатив с быстрой обработкой IO) придут и сделают грязь

Ну вот на кложе они просто ниче не сделают :D