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

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

Для SE/SA/IT модель конвейера в принципе не подходит, сколько бы менеджерье об этом не рассуждало.

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

В противоположность механизированной штамповке массовых однотипных и более простых вещей на конвейере на заводе.

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

потоковое промышленное производство давно превзошло на многие порядки возможности «уникальных мастеров».

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

В IT - аналог производства электроники роботами это кодогенерация.

Когда есть условно говоря, парочка инженеров, которые настраивают кодогенератор/DSL, напишут пару высокоуровневых рулов, и оно само за них все делает. Это, кстати говоря, к вопросу о лиспе, потому что он как раз для этого заточен.

Такое до сих пор мало где. В основном идет выделка уникальных изделий вручную, как у ремесленников до середины-конца 19 века.

Очевидно, что Golang и модель «понрабрать джамшутов и дать им в руки самотык» не ложится ни на первую, ни на вторую модель. Это попытка сделать конвейер аля штамповка гаек на заводе. Проблема в том, что штампуются не гайки, а те же уникально под заказ сделанные изделия как и у ремесленников, и не на заводе. Как я уже написал про тот же гугл - там большую часть работы делают архитекторы и тимлиды, на самом деле. Гошники по сути дела вообще не нужны ни для чего, кроме как для изображения бурной деятельности и аргументацией о размере подчиненного стада на промоушнах.

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

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

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

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

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

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

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

В кулебяках есть своя прелесть, спору нет (особенно если они действительно качественные). Но и у инженерии есть свои преимущества.

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

Я о том же. Для чего языку системного программирования, каковым является Go, избыточная сложность?

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

Дак вот IT не настоящая инженерия. Переиспользуемые компонентные архитектуры типа COM и CORBA либо сдохли либо существуют только в каких-то узких отраслях.

А если про гошников говорить - там вообще «all you really need is stdlib», и пошло поехало клепание NIH говнокода и копипасты.

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

Фреймворк или либа вроде React это ремесленничество или инженерия?)

Дело-то ведь не в фреймворке, а в том, как им пользоваться %) Реакт позволяет создавать композабельные и переиспользуемые компоненты и собирать из них разные решения, но и накулебячить неописуемую хтонь он тебе помешать никак не может.

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

Дак вот IT не настоящая инженерия.

Какой-нибудь Java-enterprise или Dotnet это вполне себе инженерия, потому что фреймворки.

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

На чем сервисы писать?

На Java, вестимо. Разработчиков тонны, язык стабильный, есть LTS версии, есть фреймворк под общие нужды, jdk / jre от разных поставщиков. Это идеальный язык / платформа для разработки что монолитов, что микросервисов по совокупности требований. Да, в этой бочке мёда есть несколько ложек говна, но в целом если нужна стабильность, приемлемая производительность, тулинг, документация, крч всё что хочешь - оно там есть.

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

Колбасить мешает обычно flux или redux.

Java-enterprise или Dotnet это вполне себе инженерия, потому что фреймворки

Это всё, конечно, облегчает структурирование приложения — но только если у человека уже есть понимание, зачем это нужно, то есть инженерный уклон в мышлении. Настоящему же кулебячнику никакой фреймворк не помеха %)

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

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

Мне вот тут подумалось: бо́льшую часть научной работы, наверное, делают люди со степенями, а не простые студенты. Но что в итоге станет с профессорами (и наукой вообще), если разогнать всех студентов? Может, в их присутствии здесь есть ещё какой-то смысл? %)

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

Когда есть условно говоря, парочка инженеров, которые настраивают кодогенератор/DSL, напишут пару высокоуровневых рулов, и оно само за них все делает.

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

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

то есть не программу, а кодогенератор, порождающий программу

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

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

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

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

Потому что технические характеристики продукта никого не волнуют уже. Чему пример Golang, и то что я написал в первом сообщении.

В современном IT никто уже почти, блеать, не руководствуется техническими соображениями, а только хайпом, модой, дуростью и предрассудками en masse.

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

Что значит «уже»? Сколько лиспу и светлым идеям кодогенерации лет и что их удерживало от покорения вселенной до появления голанга?

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

но крутить педали все же нужно?

Зато на нашем кодовелогенераторе сиденье ручной работы! И вообще оно хотя бы есть — а гляньте-ка вон на гошников, сердце кровью обливаетца.

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

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

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

мне лень историю пересказывать как-то.

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

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

Сколько лиспу и светлым идеям кодогенерации

Кстати, любопытное наблюдение, гошечка пользуется кодогенерацией там, где сам язык слишком дубовый (пост от идейного вдохновителя). Это емнип даже преподносилось как замена женерикам. Теория подковы годится не только для политики, но и ЯП?)

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

C++, Lisp и Haskell очень сильно отличаются семантикой.

... и контекстно-зависимым синтаксисом, что есть жесть жестяная

На C++ думаешь в терминах указателей/итераторов/классов

А надо думать в терминах предметной области.

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

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

thesis ★★★★★
()
Ответ на: комментарий от goingUp
go get golang.org/x/tools/cmd/goyacc
goyacc -o gopher.go -p parser gopher.y

Нужен язык программирования под названием Hu.

А то вот почти красиво, но не совсем.

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

А надо думать в терминах предметной области.

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

А если вы применяете C++ вне этих прикладных областей, то может вы изначально делаете что-то не так?

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

Переиспользуемые компонентные архитектуры типа COM и CORBA

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

Наверное, не хватает инженеров %) Инженерной культуры. А где её взять?

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

Прежде суждения о COM/DCOM/Activex скажу о том, что много лет использую при разработке эти технологии (в основном из-за того, что фирма 1С много лет использовала эту технологию).

Windows вся пронизана COM/DCOM (любая версия).

oleview.exe (в частности) позволяет увидеть, какие приложения используют COM (их тысячи).

Любопытно то, что ActiveX, разработанные даже в 1997 году прекрасно работают в любой версии Windows.

Профит COM/ActiveX в том, что они позволяют использовать функциональность, используемую в иных приложениях.
Например интегрировать Excel в любой проект.

Иногда даже проще разработать ActiveX, содержащего биндинги к какому-либо API, чем использовать API нативно в проекте.
При этом API не «прибито гвоздями» к COM.

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

Фух, ... где-то так.

Вообщем в Windows эта технология «живее всех живых».

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

Эшо.

Некоторые думают, что ActiveX это всегда диалоговые формы.
Это вовсе не так.

Ээээ, а эшо можно в run-time динамически добавить новые методы, элементы управления, ... («Широка страна моя родная. Много в ней полей и рек»).

https://learn.microsoft.com/en-us/previous-versions/windows/desktop/automat/a...

И ещё - рекомендую использовать WTL, которая много упрощает работу с COM.

Ой, я же на Linux форуме ...

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

А надо думать в терминах предметной области.

Это возможно только до выбора конкретных структур данных. А структуры данных определяются языком.

Например, решаешь задачу о рюкзаке. В предметной области у нас объём рюкзака и множество пар из массы и ценности. Объём, масса и ценность — вещественные положительные числа.

В C++ это множество пар скорее всего будет массив структур. Вещественные положительные числа превратятся в числа двойной точности в формате IEEE.

В лиспе скорее всего будет список пар. Чуть менее вероятно список структур. Вещественные положительные, скорее всего, превратятся в рациональные.

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

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

Это всё наследие времен, когда венду разрабатывали инженеры

А надо думать в терминах предметной области.

Это возможно только до выбора конкретных структур данных. А структуры данных определяются языком.

Например, решаешь задачу о рюкзаке. В предметной области у нас объём рюкзака и множество пар из массы и ценности. Объём, масса и ценность — вещественные положительные числа.

В C++ это множество пар скорее всего будет массив структур. Вещественные положительные числа превратятся в числа двойной точности в формате IEEE.

В лиспе скорее всего будет список пар. Чуть менее вероятно список структур. Вещественные положительные, скорее всего, превратятся в рациональные.

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

Но почему в хаскелле не написать тип Рюкзак и оперировать потом им и его содержимым в терминах предметной области, а не какие-то числа в списках кортежей перекладывать, тьфу, это же ЯП по настоящему высокого уровня!

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

Но почему в хаскелле не написать тип Рюкзак

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

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

По-моему, ты меня немного не понял (потому что C++ к моему вопросу не имеет никакого отношения), ну да ладно, я уже на другое отвлекся.

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

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

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

В C++ это множество пар скорее всего будет массив структур.

Это будет множество std::unordered_set из пар std::pair.

Xintrea ★★★★★
()

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

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

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

Это будет множество std::unordered_set из пар std::pair.

Да ладно. Погугли и покажи хоть одно решение с таким выбором. Так-то и в лиспе с хаскелом массивы есть.

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

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

Собственно, какая нам разница, как внутри представлен тип Thing, если он соответствует нужному интерфейсу — скажем, с ним работают функции, возвращающие его объём и массу, и в терминах этих функций реализован алгоритм набивки рюкзака? Мы даже можем выкатить сразу несколько разных представлений, потестировать и выбрать оптимальное по некоторым критериям.

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

Ну вот сделал Гугл также и Dart.

Дарт, он сейчас во флаттере, а флаттер это быстрый способ сделать мультиплатформенное приложение, под всё, плюс каноникал его продвигает.

sbu_shpigun
()

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

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

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

Фреймворк или либа вроде React это ремесленничество или инженерия?)

Ну реакт вынуждает тебя писать костыли. Так что вполне инженерия. А вот vue это уже ремесленничество, ибо там всё есть, и тебе не нужно заниматся сбором конструктора, ты можешь сразу творить.

sbu_shpigun
()

Простым задачам пускай и инструменты будут простые.

Как раз задумывался, на чем несложные утилиты писать. Лучше go ничего не придумал.

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

Простым задачам пускай и инструменты будут простые.

Не бывает простых задач, есть незавершенные. Оно может быть простым «в моменте», а в перспективе взять и вырасти. Раз так в сто.

Как раз задумывался, на чем несложные утилиты писать. Лучше go ничего не придумал.

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

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

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

WTL

Для упрощения работы с COM в Windows используется ATL (Active Template Library)

Все-таки ATL наверно?

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

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

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

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

Насчёт CORBA не знаю, а вот COM был не так поган как казалось, но практика показала, что разве что на .net с его interop получилось эти компоненты делать так, чтобы не было мучительно больно.

Про DCOM и COM+ даже говорить не охота, там мрак и содомия.

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