LINUX.ORG.RU

Почему Go это плохо, и он вам, на самом деле, не нужен.

 ,


7

15

Давайте я вам поясню про язык Go, откуда у него растут корни, и почему его на самом деле не стоит использовать. То что напишу ниже, это взято как из инсайдерской информации, так и из материалов, доступных в интернетах.

Дело в том, что Go это, на самом деле, «решение» внутренних гугловских проблем. Но отнюдь не проблем горизонтального масштабирования серверного ПО, как многие почему-то думают. Он приспособлен специально для использования в гугле вот в каком контексте.

Гугл нанимает большое количество тупых студентов, только-только после вуза или ПТУ, и заставлять их писать хоть какой-то простой код. И делать минимум ошибок, при этом. Для этого Go сделан таким тупым и упрощенным. И выкинут в паблик он только для того, чтобы вероятность, что у такого студента, только пришедшего в гугл, было хоть какое-то знание Go, была выше нуля.

Но дело вот в чем. В гугле, на самом деле, над каждой командой гошников стоит тимлид, или целая группа, который/которая вот этим взаимозаменяемым роботам-гошникам расписывает всю систему, чуть ли не вплоть до состояния конечного автомата, до if-ов, и показывает куда и что писать. Поэтому же Go на корню режет всю креативность, поэтому там нет практически никаких средств абстракции, и поэтому он не дает делать вообще ничего сложного. Дабы программисты на нем вообще ничего лишнего не думали, а кодировали все чуть ли не побуквенно по указаниям умных людей.

Из гугла же идет маразматическая система управления зависимостями Го, которая заточена на монорепы.

Тут возникает вопрос - а почему этому тимлиду не дать в руки кодогенератор, вместо всей этой accidental complexity, возникающей из-за огромного количества строк кода, и из-за затрат на коммуникацию?

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

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

Естественно, это все отражается на качестве продуктов, и это видно как по полному прекращению инноваций в гугле, так и по постоянно мелькающим и закрывающимся высерам этой компании - hangouts, duo, google plus, google wave, и прочее и прочее, можете еще вспомнить много чего.

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

Никакой мифической простоты в отладке и в понимании кода Go не приносит. Да и сложность программных систем растет совершенно не из-за понятности/непонятности какой-то отдельной взятой строчки кода или функции. Потому, что, во-первых, понятность это понятие субъективное, во-вторых потому, что, отдельно взятая фунцкия на 5 строк понятна любому опытному программисту, будь она написана хоть на Rust, хоть на Common Lisp.

Сложность программных систем возникает из-за их размера. И Go эту проблему значительно ухудшает. Человек не может удерживать в голове слишком много вещей, даже если каждая отдельная вещь - очень простая. Количество RAM в голове ограничено.

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

★★
Ответ на: комментарий от Calm

Даже не в курсе вообще про что речь, на разных языках говорят.

Гошники это не капитаны дальнего плавания, это как правило либо менеджерки-распильщики, либо умственно отсталые.

Соответственно, пример надо другим образом переписать.

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

Гошник ему отвечает - ничего не знаю, мне вон папа лобзиком из ДСП выпилил кораблик и я его в ручейке пускал, возле моего интерната для умственно отсталых! ДСП рулит и педалит!!

lovesan ★★
() автор топика
Ответ на: комментарий от Nervous

Еще и 8 пробелов. Перебор, как по мне.

urxvt ★★★★★
()
Ответ на: комментарий от lovesan

Гошники это не капитаны дальнего плавания, это как правило либо менеджерки-распильщики, либо умственно отсталые.

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

slew
()
Ответ на: комментарий от lovesan

современные суда давно делаются из различных сплавов стали

Вот, значит, в чём скрытый смысл называть дотнетоязыки Iron $lang.

Боюсь подумать, каким сортом чего в этой притче был борщелисп %)

Nervous ★★★★★
()
Ответ на: комментарий от slew

на го в три пота пилят тучи проектов, как горячие пирожки

Ну так это говно распильное, в основном. Там на результат насрать вообще, как и на стоимость продукта.

lovesan ★★
() автор топика
Ответ на: комментарий от lovesan

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

Зато в Goвне есть GC, корутины и нормальная библиотека а в сишке - нет. Азаза.

Skullnet ★★★★★
()
Последнее исправление: Skullnet (всего исправлений: 1)

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

хотелось бы Golang+элементы функционального программирования из rust

Cergoo
()
Ответ на: комментарий от Skullnet

Вопрос только - что делать с достаточно качественным и очень нужным софтом уже написанным на Go: lazygit, micro, hugo и др.

Продолжать использовать, игнорируя визги шизофреников-борщехлёбов, которые даже указатели не осилили.

alex1101
()
Ответ на: комментарий от alex1101

Продолжать использовать

Использовать что? Язык, застрявший по фичам в 70-х годах? Error handling в Golang-е это просто нечто. Прям удовольствие писать if err != nil после каждого чиха.

Skullnet ★★★★★
()
Ответ на: комментарий от Skullnet

Использовать что?

Изделия, которые ты перечислил.

Прям удовольствие писать if err != nil после каждого чиха.

На фоне обработки ошибок в плюсах - это не так уж и плохо выглядит) А какие есть варианты лучше?

alex1101
()
Ответ на: комментарий от alex1101

На фоне обработки ошибок в плюсах - это не так уж и плохо выглядит) А какие есть варианты лучше?

try catch. Прям бешено плюсую, что Go создавался для неосиляторов Java.

Skullnet ★★★★★
()
Последнее исправление: Skullnet (всего исправлений: 1)
Ответ на: комментарий от Skullnet

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

try catch

Чем это лучше гошного варианта? Без троллинга

alex1101
()
Ответ на: комментарий от Skullnet

Прям бешено плюсую, что Go создавался для неосиляторов Java

Будто что-то плохое. Джава может просто не нравиться по ряду причин.

alex1101
()
Ответ на: комментарий от rumgot

Так и я о том же: можно так же, можно не так же, можно вообще свой велосипед изобрести. Это палка о двух концах.

alex1101
()
Ответ на: комментарий от alex1101

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

Ага, и поэтому в Go решили выбрать самый худший из способов.

Чем это лучше гошного варианта?

Тем что обернул в него блок кода и готово.

Skullnet ★★★★★
()
Ответ на: комментарий от alex1101

Лучше бы тогда Crystal маркетили так как Go. Он этого больше заслуживает. Либо запилили Kotlin native.

Skullnet ★★★★★
()
Последнее исправление: Skullnet (всего исправлений: 1)
Ответ на: комментарий от Skullnet

обернул в него блок кода

Это не всегда удобно.

в Go решили выбрать самый худший из способов

Да чем он худший-то?

alex1101
()
Ответ на: комментарий от alex1101

Это не всегда удобно.

Удобно копипастить if err != nil. Я вас понял.

Да чем он худший-то?

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

Skullnet ★★★★★
()
Ответ на: комментарий от Skullnet

Удобно копипастить if err != nil

Копипастить конечно удобно, какие могут быть сомнения?

Вот есть сишные либы…

Не понял, как это относится к теме разговора.

alex1101
()
Ответ на: комментарий от alex1101

Копипастить конечно удобно, какие могут быть сомнения?

Ну да, у макак по поводу копипастинга сомнений быть не может.

Не понял, как это относится к теме разговора.

Одинаковые паттерны программирования. Go взял из языка СИ самое худшее, а самое лучшее не завёз.

Skullnet ★★★★★
()
Ответ на: комментарий от Skullnet

try-catch блоки это дорогое удовольствие. придумайте как это может быть примерно реализовано.

alysnix ★★★
()
Ответ на: комментарий от Skullnet

самое лучшее не завёз

Переполнения что ли? 😁

alex1101
()
Ответ на: комментарий от Skullnet

Неудобно в асинхронном коде. Например: есть функцияA(), которая принимает в качестве аргумента функциюB() как некий callback. Внутрь этого callback-а в числе прочего будет передан код ошибки того кода, котрый будет вызывать функциюB(). Обращаю внимание: функциюB() вызовет не функцияA(), а совсем другой код позже. Примеры можно увидеть в boost.asio.

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 2)

Как известно, языки программирования достаточно четко делятся на 2 категории - те, которые все ругают (к примеру, PHP или Python), и те, которыми пользуются 1.5 пассионарных крикуна-фанбоя (как, к примеру, Haskell или Common Lisp), полезного для общества выхлопа от которых никто не видел.

Очевидно, что Go относится к 1й категории. И это в общем-то уже успех.

Minoru ★★★
()
Ответ на: комментарий от Minoru

Очевидно, что Go относится к 1й категории. И это в общем-то уже успех.

Где успех? PHP то ещё старались пофиксить, а где Go фиксят?

Skullnet ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Поддерживаю. Аргументы уровня «Go плохой, посмотрите какой у меня большой… скилл, потому что я фанат Erlang». Сложность ради сложности, чтобы кидать понты на форумах.

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

Go хорош для своей ниши. Чем тупее — тем лучше, потому что так говнокодеры напишут меньше говнокода.

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

Не согласен. Bun уделывает Go в производительности, он даже быстрее C в некоторых кейсах. Это особенно заметно на тестах веб-сервера, по некоторым параметрам отрыв от Go более чем в 5 раз, включая сравнение с fasthttp.

InterVi ★★★★★
()
Ответ на: комментарий от InterVi

Чем тупее — тем лучше, потому что так говнокодеры напишут меньше говнокода.

Непонятно, зачем о себе говорить от третьего лица 🤷‍♂️

Virtuos86 ★★★★★
()
Ответ на: комментарий от alex1101

В плюсах обрабатывать ошибки можно 100500 разными способами

гошный вариант

В Go тоже есть panic и recover так-то. И их тоже приходится использовать в приложениях больше hello world’а. И не только для ловли runtime ошибок, но и обработки разных событий, например CTRL-C. И это стандартная практика, штатный http сервер, например, его использовал для т.н. «graceful shutdown».

Calm
()

Нужна выразительность, все так, и Go намного выразительнее чем Common Lisp, а уж как выразителен JavaScript, одна строка npm install leftpad вместо 100 строк для реализации на Common Lisp.

MOPKOBKA ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

liksys ★★★★
()
Ответ на: комментарий от MOPKOBKA

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

putch
()
Ответ на: комментарий от putch

автор языка не знает про элементраные map, filter, reduce и тебе приходится писать их самому каждый раз

Справедливости ради, зачем автору языка об этом знать — кому надо, может это всё реализовать в виде библиотеки. Чай, не рокет саенс.

Вот если бы в языке принципиально нельзя было реализовать что-то подобное — то да, это была бы трагедия %)

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)

Хороший срач. Уже 15-я страница и он никуда не скатился идёт строго по теме. ТСа надо как-то отметить.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от Minoru

полезного для общества выхлопа от которых никто не видел.

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

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от Cergoo

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

Давно появился как раз, это Common Lisp. Покрывает все ниши в которых можно использовать Go

lovesan ★★
() автор топика
Ответ на: комментарий от DumLemming

настоящих разработчиков языков всегда отличало бесстрашие и нетрадиционализм.

alysnix ★★★
()

Вот это наброс… Моё почтение, столько комментариев обычно собирают только новости про Debian и GNOME.

Werenter ★★☆
()

Давайте я вам поясню про язык CL, откуда у него растут корни, и почему его на самом деле не стоит использовать. То что напишу ниже, это взято как из инсайдерской информации, так и из материалов, доступных в интернетах.

Дело в том, что CL это, на самом деле, «решение» психиатрических проблем. Но отнюдь не проблем разрозненных диалектов Lisp, как многие почему-то думают. Он приспособлен специально для сдерживания шизов вот в каком контексте.

Бизнес нанимает большое количество адекватных, нормальных программистов, и заставлять их писать рабочий код под требования бизнеса. И делать минимум ошибок, при этом. А шизов - не нанимает. Но сдерживать их как-то надо. Для этого CL сделан таким умным и усложненным. И выкинут в паблик он только для того, чтобы была вероятность, что шиз наткнется на него в современном мире, заинтересуется метапрограммированием, созданием новых синтаксических конструкций и прочими компилируемыми макросами головного мозга.

Но дело вот в чем. В комитете X3J13, на самом деле, понимали что над каждой командой программистов стоит тимлид, или целая группа, включая архитекта, который/которая вот этим программистам ставит задачи и выбирает язык программирования под условия задачи. Поэтому же CL на корню режет всю адекватность, поэтому там нет практически никаких средств быстро и просто решить поставленную задачу, и поэтому он не дает делать вообще ничего простого. Дабы программисты на нем вообще ничего лишнего не думали, а изобретали велосипеды без сидений чуть ли не поскобочно по указаниям голосов в голове.

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

Тут возникает вопрос - а почему этому шизу не дать в руки кодогенератор, вместо всей этой метаамфетаминовой свободы, возникающей из-за огромного количества скобок в коде, и из-за затрат на коммуникацию?

А тут надо понимать, как внутри устроены люди познавшие CL.

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

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

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

Никакой мифической осознанности в отладке и в понимании кода CL не приносит. Да и сложность программных систем растет совершенно не из-за понятности/непонятности какой-то отдельной взятой строчки кода или функции. Потому, что, во-первых, понятность это понятие субъективное, во-вторых потому, что, отдельно взятая функция на 5 строк понятна любому опытному программисту, будь она написана хоть на JS, хоть на GO.

Сложность программных систем возникает из-за их размера. И CL эту проблему значительно ухудшает. Человек не может удерживать в голове слишком много скобок, даже если каждая отдельная скобка - очень простая. Количество RAM в голове ограничено.

В случае если вы не хотите выкидывать кучу денег просто так, и скорее предпочли бы нанять немного, но более-менее опытных программистов, CL будет только вреден, потому что все вменяемые люди от него, на самом деле, плюются. Он реально отталкивает опытных людей, которые способны понять сложные требования и написать, и поддерживать, более-менее сложные системы уровнем хотя бы нескольких сервисов плюс БД и MQ.

P.S.: мимо 16лет на ЛОРе ридонли. Не удержался.

Obezyan
()
Ответ на: комментарий от Obezyan

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

slew
()
Ответ на: комментарий от slew

Я не защищаю Go, вообще не гошник. Из черни мы, из системных архитекторов.

С Go было один раз и по пьяни - когда нужно было ML пайплайн сделать с апи для запуска нейронки с биндингами tensorflow на С.

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

Obezyan
()
Ограничение на отправку комментариев: