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.

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

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

Это да. Но даже в случае виртуальной функции, например:

class base {
public:
  virtual void accept(std::string && data) = 0;
  virtual void accept(std::string_view data) = 0;
};

компилятор будет определять какой из accept-ов следует вызывать в зависимости от типа аргумента.

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

Выглядит неплохо. А вот насколько оно расширяемо я, за невежеством в С++, судить не возьмусь.

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

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

А шо тут спрашивать?
Мычать будет.

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

Грэм как раз в середине 90-х свой viaweb на лиспе пилил и был доволен, но почему-то он такой оказался один, а viaweb потом то ли сдох, то ли переписали на что-то ещё когда в яхусторз переделали.

ЕМНИП, его переписали на C++, поскольку Yahoo не смог нанять лишперов, которые смогли бы поддерживать творение Грэма дальше.

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

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

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

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

Кажется последний такой срач был про метапрог…

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

компилятор будет определять какой из accept-ов следует вызывать в зависимости от типа аргумента.

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

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

я думал вы поделитесь каким-то простым, как и сам вопрос, хоть и сокровенным знанием. а тут оказывается надо читать некое AOMP.

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

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

Нет, не поэтому.

даже железо уже в середине 90-х было,

Для запуска CL массового железа в 90х не было.

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

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

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

Они определены. Ты никаких данных не вытянешь, которые исходят из модели. Надо всё ручками-ручками.

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

Уууу. А я в руках настоящий платный диск с ватком си держал.

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

Как такой же трюк с расширением языка провернуть с императивным языком, например с Go, раз уж мы о нём тут толкуем. Только чуть к кодогенерации внешними средствами не прибегать!

Сделать на нём свой лишп. Модели определять всякими структурами данных.

crutch_master ★★★★★
()

Кстати, многие не знают о компьютерах начала 90-х и ранее.
Например https://ru.wikipedia.org/wiki/ПО_«Искра»
Так вот в те года разработчики старались оптимизировать алгоритмы.
Что касаемо Лисп, то исходники компилировались быстро, так как синтаксис Лисп был крайне прост для парсинга.

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

Естественно, не поэтому.

А кто и где мог писать на лиспах(пусть не CL, а что?) когда настольники начали убивать мейнфреймы и прочие Юникс Сервера?

Это ты опять включаешь аутизм

Это скорее ты его не выключаешь.

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

будет определять в какой из слотов VMT ему лезть.

Ну вот и я о том же. Компилятор в момент компиляции точки вызова посмотрит на тип аргумента для accept и либо выберет один из accept-ов, либо откажется компилировать. После того, как выбор сделал, никакой другой accept (в смысле списка параметров), уже вызван быть не может.

Тогда как в динамическом языке у объекта может появится новый accept и при вызове этот новый accept будет принят во внимание.

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

Тогда как в динамическом языке у объекта может появится новый accept и при вызове этот новый accept будет принят во внимание.

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

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

А кто и где мог писать на лиспах(пусть не CL, а что?) когда настольники начали убивать мейнфреймы и прочие Юникс Сервера?

В гугле забанили? Ну можешь спросить вот здесь: https://www.reddit.com/r/Lisp

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

Раз уж вы решили отыгрывать литературного персонажа из эссе Пола Грэма, то мне показалось правильным отправить вас в книжку.

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

Ты вообще не вдупляешь о чем идет речь.

У тебя в крестах, естественно, динамической диспетчеризации по типам дополнительных аргументов нет. У тебя есть только диспетчеризация по this.

Конкретный виртуальный метод будет выбираться в рантайме, в зависимости от this.

В лиспе таких this может быть больше одного, вот и всё.

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

У тебя в крестах, естественно, динамической диспетчеризации по типам дополнительных аргументов нет. У тебя есть только диспетчеризация по this.

Я вам больше того скажу: в моем примере и this-а то и нет.

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

Аргумент this в виртуальных методах всегда, естественно, есть, и идет там первым в вызове метода. И это тот самый аргумент по которому идет динамическая диспетчеризация.

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

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

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

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

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

Опять какие-то «преимущества» полезли… Ох.

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

Аргумент this в виртуальных методах всегда, естественно, есть, и идет там первым в вызове метода. И это тот самый аргумент по которому идет динамическая диспетчеризация.

Спасибо, Кэп. Но в моем примере нет виртуальных методов.

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

а потом не давала особых преимуществ в сравнении с той же java

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

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

... и каждый раз надо учить всё заново.

Если бы только это.
Например, экосистемы разные.

Кстати, как решён этот вопрос для Rust, при использовании его для разработки драйверов Linux?

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

Если шлёпаешь круды, ну да, нахрен тебе это лишп.

Ага, и потом наблюдаешь высеры типа Vue, Angular или React, в которых адский сракотан, через жопу, транспилерами сделанное метапрограммирование, свои DSL, которые абсолютно неотлаживаемые, особенно если случись че внутри фреймворка, которые тянут за собой сотни мегабайт какого-то говна в зависимостях (включая компиляторы C++, причем иногда нескольких, блеать, версий). И которые тормозят и глючат, в итоге, а также в абсолютно невменяемом количестве жрут память и трафик. И теперь это говно еще и на десктопе, через Electron.

Это просто квинтессенция десятого правила Гринспуна

И, ага, попробуй ты поклепай формочки без всего этого говна.

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

(method Obj)

это же просто вызов функции. и не надо было классы городить. опять же

obj.method().method1().method2()...

выглядят легко и приятно.

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

И, ага, попробуй ты поклепай формочки без всего этого говна.

берешь дельфи и клепаешь.

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

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

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

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

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

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

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

Я про frontend не скажу, а вот с typescript через AWS CDK сталкивался. Жить можно, по крайней мере проблемы самого CDK напрягают больше, чем TS/JS/Node, но вот размер зависимостей просто вымораживает. Тебе нужно всего-то дёрнуть пару API и сгереровать yaml по описанию. А в node_modules уже 800Мб непонятно чего накачалось. Винда вместе с МС Офисом во время оно меньше занимала!

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

Это абсолютное непонимание сути лиспа вообще

Суть лиспа в том, чтобы побольше страдать? %) Так это вам к плюсовикам тогда, в одну палату.

рич хики не осилил ридер-макросы сделать

Есть там ридер макросы, просто пользователь не может новые строгать. И это правильно, нечего из уютной кложи слаку коммон лисп делать. Ядро языка должно быть стабильным, для расширяемости есть обычные макросы и tagged literals. Не нравится — чемодан, вокзал, коммон лисп/схема.

В стандартном синтаксисе CL нет сахара по той простой причине, что в нем нету смысла

Это не «просто сахар», это реально фундаментально разные классы коллекций, с разными интерфейсами и разными гарантиями производительности для разных операций. В чём смысл сваливать их в одну кучу? Чтобы ни хрена не понимать, что в коде происходит? %)

Когда ты используешь DSL - тебе детали нижележащего языка - нахер не сдались

Каким бы ты языком ни пользовался, от реальности не убежать. А в ней всегда есть объекты и их коллекции; коллекции в основном бывают последовательные и ассоциативные, и было бы неплохо, если бы они по умолчанию отличались по виду. Удобно, понемаешь? %)

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

Ну, справедливости ради, оно им нахрен не усралось для очередного круда и перекладывателя json'ов тащить лисп. Не того калибра инструмент. А о каких-то более абстрактных вещах обычно никто не задумывается, потому что незачем. Когда возникают проблемы тогда уже поздно метаться.

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

методы через точечку удобнее

зато скобки не круглые а фигурные.

Хорошо, что есть кложа — там тебе и методы через точечку (по крайней мере жабные/жсные/…), и скобки какие хочешь есть в наличии %)

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

оно им нахрен не усралось для очередного круда и перекладывателя json’ов тащить лисп.

Конечно, мы будем делать yamlы из yamlов тупым и убогим как полено go template enginом вместе с обрезком из нескольких функций стандартной библиотеки (я сейчас про helm если что) и пытаться понять какого хрена у нас из этих исходинков получился этот результат. Зато не лисп!

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