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.

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

Интернет это не только провода. Хотя и с этим есть сложности если в старом доме живёшь, по крайней мере мои немецкие коллеги регулярно жалуются. Но хрен с ним. Бывает заходишь на сайт клуба или автошколы, например, а он выглядит, будто как его в 98-м году племянник владельца сверстал в дримвьювере, так с тех пор там ничего особо не изменилось. Не исключено, что там все умерли уже от ковидлы, просто хостинг на 10 лет вперёд проплатили. Впрочем, есть телефон, так что если интересно чего можете позвонить и спросить. Или, вот, когда в России нужно провзаимодействовать с государством, вы не сходя с места заходите на ГосУслуги и всё, что нужно сделаете. А в Германии нужно записаться на приём, ножками сходить в бюргерамт и потом пару недель ждать ответ по почте (бумажной).

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

Для каких?

В случае Modula-2, как мне помнится, бортовое ПО для всякого разного (типа ракет).

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

И это логично: зачем тебе ещё void* если не для последующего каста.

Проблема в том, что в коде этого самого каста не видно. А в C++ – видно.

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

Т.е. ты хочешь, чтобы при явном указании тобой самого небезопасного каста компилятор говорил такой: «нет! я этого делать не буду!» Тебе самому не странно?

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

Я не понимаю, это C++ на мозги так действует или что?

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

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

Вот в лиспе - типобезопасность. Полная и абсолютная. А в крестах и подобной хероте - ее нет и не было.

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

Да и вообще-то говоря, такая формулировка догматизмом попахивает.

за наложение на копируемость ограничений есть масса аргументов.

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

2.копируемость накладывает ограничения на реализацию класса.

3.понятие копии может быть не четко определено. например что такое копия обьекта типа Тред или Мьютекс.

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

5.создание копии хоть и возможно, но оно приводит к высоким накладным расходам.

6.можно обойтись и без создания копии обьекта.

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

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

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

alysnix ★★★
()

Интересно, что я уже слышал подобное мнение о Гошечке от толковых коллег на частной встрече года три тому назад. Причем, примерно в тех же выражениях. Типа «Гугл придумал monkey language для monkey coding и сам им старается не пользоваться». Ну, вот теперь пусть и ширнармассы узнают правду

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

В языке много кастов, которые не видно. Можно присвоить int в char и ничего, хотя по факту присваивание потенциально теряет информацию.

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

Если что reinterpret_cast это не тоже самое, что сишный каст. Но это к слову.

Какая разница, высирает компилятор варнинги или нет?

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

Этот код в C++ не скомпилируется, это не ворнинг, а ошибка компиляция.

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

Исключительно ИМХО.

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

Ну так не используй явный каст.

Вот в лиспе - типобезопасность. Полная и абсолютная. А в крестах и подобной хероте - ее нет и не было.

В C++ при необходимости можно не использовать типобезопасность. Это опция. Тебя никто не заставляет использовать явные касты.

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

В лиспе я вообще не могу один объект в другой «кастануть»

А как ты вообще предполагал каст для нетипизированного языка? Каст это инструкция для компилятора, что значение меняет тип. Если нет типов, естественно и кастов не будет.

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

потому ты и не напишешь на лиспе менеджер памяти или сборщик мусора.

Для этих всех вещей нужны не кресты, а или Си или ассемблер (в компиляторах лиспа есть встроенные ассемблеры обычно, поэтому нет проблем на таком лиспоассемблере написать и менеджер памяти и все остальное). А кресты там нахер не уперлись, особенно если говорить о менеджере памяти(это который в ядре и MMU оперирует) - лол, кресты в ядре это вообще оксюморон, у крестов рантайм не сильно менее жирный чем у Common Lisp того же.

А вот для высокоуровнего программирования эти фичи уже НАХЕР не нужны, и даже вредны. И вот это кстати еще одна из таких фич в копилку крестов, которые могут вообще все обосрать, и потом иди ищи где у тебя сегфолт или чето подобное.

То есть крестам эти вещи как корове пятая нога. Говно, короче, а не язык. Набор недоразумений и граблей просто. И нет, ведь, умудряются гордиться тем что научились по этим граблям ходить. C++ это все-таки диагноз.

lovesan ★★
() автор топика

К слову, вообще не понимаю о чём тут спорить. Я выделю три ключивые утверждения:

  1. Язык Go простой как валенок.

  2. Программисты пишут на чём им скажет писать начальство.

  3. Начальство играет в корпоративные игры и ему не до технологических тонкостей.

Всё это очевидно верно. Откуда только двадцать страниц болтовни взялось.

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

В C++ при необходимости можно не использовать типобезопасность. Это опция. Тебя никто не заставляет использовать явные касты.

За тебя напишут. И обосрут тебе все «типобезопасные» костыли которые ты так старательно выстраивал наворочав абстракции.

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

у крестов рантайм не сильно менее жирный чем у Common Lisp того же.

у крестов рантайм, если покоцать, строк 100 на самих же крестах. там самый большой кусок - тот менеджер памяти, что дает malloc/free. вот его и покоцать, и прям на с++ и написать новый, любой, какой хошь.

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

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

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

malloc/free это не про кресты, это про сишную стдлибу

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

В языке много кастов, которые не видно. Можно присвоить int в char и ничего, хотя по факту присваивание потенциально теряет информацию.

И это плохо.

Но когда от одного (причем не самого безобидного) можно избавиться, то это же хорошо, нет?

Кстати, в C++ начиная с C++11 сделали инициализацию через {} и там многие подобные фокусы с int/char уже не принимаются компилятором.

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

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

Не обязан. Это от предметной области зависит.

Не вижу проблем с копированием std::string, std::string_view или каких-нибудь point_3d, rgb_pixel и т.п.

А вот вы в догмы ударяетесь.

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

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

Нихера себе новенькие. C++98 есличё.

с уродскими треугольными скобками и длинным названием

Вы что не в курсе, что они специально такими сделаны? O_o

Впрочем, чего с джуна взять.

А в крестах и подобной хероте - ее нет и не было.

Это от кривизны рук программиста зависит.

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

Вы что не в курсе, что они специально такими сделаны? O_o

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

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

Конечно в курсе, потому что синтаксис крестов вообще не продумывался, придумали как попало че попало

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

_cast в C++ специально настолько уродским сделали, чтобы это вот прям даже таким чудикам, как вы в глаза бросалось.

Жаль только, что Сишный каст из плюсов выбросить нельзя :(

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

Эшо

Многие забывают о том, что для разработки 90% алгоритмов достаточно использовать лишь «стандартные» операторы управления (а-ля Си) ...

Как например у меня решён вопрос использования стороннего API?

Сотни функций с разными «выкрутасами».
Можно ли унифицровать код возврата?
Можно.
Делаем биндинг к функциям и в нём прячем все «выкрутасы».
Удобно (но не всегда использую унификацию)...

API для использования метаданных позволяет много функциональней решить вопросы работы с объектами (за одно нет необходимости в использовании template, class, ...).

К примеру, реализована интроспекция (в run-time).

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 6)
Ответ на: комментарий от eao197

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

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

Но идея что авторы C++ сделали C++ таким чтобы его не использовали вообще мне в голову не приходила. Ну, если они действительно это планировали, то вобщем, теория не прошла проверку практикой. Лучше бы это нагромождение костылей вообще было бы не создавать. А еще лучше щас бы вышел бы Страуструп и публично заявил - «Хватит насиловать это говнецо. Ну да, высрал я это поделие, но был молодой и глупый. Виноват. Извините! Не используйте его пожалуйста.»

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

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

Вы еще и читать не умеете? Я не говорил, что _cast-ы такими сделали, чтобы ими не пользовались. Так что глаза разуйте и перечитайте:

_cast в C++ специально настолько уродским сделали, чтобы это вот прям даже таким чудикам, как вы в глаза бросалось.

То, что вы шаблоны C++ не осилили, неудивительно. Вы ведь даже про reintepret_cast думаете, что это нововведение в C++.

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

Типа «Гугл придумал monkey language для monkey coding

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

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

ИМХО C++ прекрасно подходит для системного программирования,

А потом бедные админы ночей не спят, CVE закрывают.

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

Так дураков победить невозможно.
«Вот в чём вопрос».

Ээээээээээээээээээ, не прав я.
Дурак сумеет победить дурака.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 3)
Ответ на: комментарий от ugoday

сорок мегабайт нежатого корфайла, даже не статика, вроде. Десять жатого.

У го - 12 мегов нежатого бинаря, 3.5 под upx. Оперативка есть, не проблема, а вот флеш в дефиците.

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

три ключивые утверждения

Там ещё обертона очень пронзительные — язык Го говно, программисты макаки, начальство мудозвоны. Не все такую музыку спокойно воспринимают %)

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

Воля ваша, но для большинства применений цифры почти идентичные.

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

Допустим. Альтернативы какие? CL? Где примеры, что код на нём легче отлаживается, расширяется, поддерживается, чем любой другой императивный язычок? С примерами.

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

Проблема в том, что в коде этого самого каста не видно. А в C++ – видно.

Вот этот вот плюсовое «static_cast<MyF_ingType*> сильно лучше (MyF_ingType*)» откровенно раздражает. Не использую сишные касты в плюсах только чтобы больных лишний раз не тревожить.

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

Дело же не в том, что мне не нравится static_cast<..>

Мне не нравится, когда претворяются, будто это существенно лучше сишных кастов.

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

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

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

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

Очень похоже на то, что ты просто не знаешь C++. Собственно, 99.9% хейторов плюсов (Линус входит в 0.1% хейтеров) именно такой вот контингент. Говоришь про абстракции в лиспах. На плюсах тоже нужно мыслить абстракциями и классами. Правильно проектировать классы.

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

РФ вообще одна из самых передовых стран по развитию IT. Интернет сервисы, связь, точно лучше чем в ЕС, США (про Азию говорить не берусь, не бывал).

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