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.

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

Ну и кресты, и возня с языком вместо решения задачи - один из ключевых

А это уже определяет твой уровень и опыт на конкретном языке.

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

Чтоб у браузера были системные требования как у Киберпанка 77?

Разве у них не такие требования вот прямо сейчас? Требовательность ПО следует проверять на престарелом оборудовании, когда всё видно по часам с кукушкой, что сколько запускается, как отзывчиво работает…

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

Нет.

На крестах условно говоря, надо городить дохерища нахрена не нужного boilerplate. Даже для того чтобы определить простенький всратый класс(конструкторы-херукторы, плюс операторы копирования, плюс move-операторы, плюс все остальное). Даже на Си - надо писать объективно меньше.

Когда этот boilerplate пытаются абстрагировать - вот тогда то и выходит сракотан с шаблонами.

Выхода два

  1. Не писать на C++ (самый лучший вариант)

  2. Писать как на Си с классами, абсолютно игнорируя все «modern» фичи, но это чревато тем, что в библиотеках, эта сранина все же может встречаться и конфликтовать с твоим кодом, и приводить к сранине в твоем коде. Т.е. на C++ нельзя, на самом деле, просто взять и не использовать какую-то фичу - потому что в C++ все фичи НЕОРТОГОНАЛЬНЫЕ. Это лечится только жестким запретом какой-то фичи к полным херам(типа как исключения и другое в Google Code Style), но чтобы такое контролировать надо быть тупо гуглом, и писать вообще всё, начиная со стдлибы, самим. Поэтому если придерживаться такого подхода, и вне гугла - то C++ надо использовать сам по себе вообще по минимому, по самому необходимому минимуму, а остальное писать либо на Си, либо на высокоуровневых языках(популярна связка с тем же бидоном)

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

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

Причем во многом - именно из-за того что обмазаны костылями типа смартпоинтеров и прочего везде где можно.

Это все надо взять и переписать хотя бы на дотнете или жабе. Станет реально лучше.

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

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

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

Это все надо взять и переписать хотя бы на дотнете или жабе.

надо на жабе переписать 18 процентов дотнетовского рантайма. которые на гнусных с/с++. чтобы всем крышу вообще сорвало

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

На крестах условно говоря, надо городить дохерища нахрена не нужного boilerplate. Даже для того чтобы определить простенький всратый класс(конструкторы-херукторы, плюс операторы копирования, плюс move-операторы, плюс все остальное).

Не нужно, если тебя устраивает поведение со специальными членами по умолчанию.

но это чревато тем, что в библиотеках, эта сранина все же может встречаться и конфликтовать с твоим кодом, и приводить к сранине в твоем коде. Т.е. на C++ нельзя, на самом деле, просто взять и не использовать какую-то фичу - потому что в C++ все фичи НЕОРТОГОНАЛЬНЫЕ

Можно пример?

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

Даже для того чтобы определить простенький всратый класс(конструкторы-херукторы, плюс операторы копирования, плюс move-операторы, плюс все остальное).

Ну вот, а говорили, что не джун.

Даже на Си - надо писать объективно меньше.

А Сишечку, наверное, вообще в глаза не видели :)

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

Не нужно, если тебя устраивает поведение со специальными членами по умолчанию.

Только оно тебя в большинстве случаев нихера не устраивает, и например копирование объекта по значению прямо со всеми полями в большинстве случаев, прямо подавляющем большинстве случаев - нам нахер не сдалось.

Можно пример?

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

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

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

Это все происходит, потому что в браузеры всунули херову гору избыточной функциональности, кучу фичей js/html/css движка, а еще то, что сам ui браузера пишется частично на js. Лет 15 назад браузеры не были таким неповоротливым монстром как сейчас.

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

Цель любого бизнеса – получить прибыль и меньше головняков.

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

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

Что такое ортогональность фич?

Поясняю, если непонятно.

В Common Lisp Object System есть метаобъектный протокол. Если он тебе не нужен - ты его не используешь, и вообще, пишешь код так, как будто его нет. Я думаю, даже, что большинство кода на CL так и написано.

Точно так же с макросами. Хотя, естественно, их все используют - но если тебе вдруг приспичило писать на CL как на питоне - то просто берешь и пишешь.

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

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

У меня так: template, class, STL, стандартное API... не использую.
Всё свое.
API эффективно.
Почему так?
«Где просто, там ангелов со ста, где мудрено, там ни одного».
Удивляет нынешний «современный» С++.
К счастью C++ ещё не поломали, а это радует.
Впрочем разрабатываемый код можно скомпилировать любым компилятором С++ (даже начала 90-х).

Цель то разработки, не в «надувании щёк».

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

Ты всегда должен держать в голове исключения, и что станет с твоими объектами если у тебя в коде случится раскрутка стека, что будет с недосконструированными объектами, и так далее.

facepalm.jpg

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

Джуном были, джуном и остались.

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

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

Рекомендую переехать в Европу и посмотреть на уровень местных интернетов. После этого вы можете изменить своё мнение.

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

Код на CL чтоли никто не видел?

Да видел, конечно. Но лучше бы не видел.

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

Только оно тебя в большинстве случаев нихера не устраивает, и например копирование объекта по значению прямо со всеми полями в большинстве случаев, прямо подавляющем большинстве случаев - нам нахер не сдалось.

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

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

Можешь использовать функции, которые не бросают исключения. Если варианта без исключения нет, то оборачиваешь в try catch. И что? В С# нет исключений?

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

Уровень аргументации «бох» :)

Ну а чего еще ожидать от джуна, который никогда не сталкивался с нарушением инвариантов из-за return-а из середины метода.

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

Всё свое.

И не ты один такой. Это вообще повальная херня. И это не только в гуглояндексах.

Вот это я в частности, тоже отношу к бесполезному задротству, которое провоцирует C++

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

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

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

Это он еще просто своего кода никому не показывал :)

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

Но иногда да.

Что значит иногда? Если тебя устраивает конструктор копирования по умолчанию, и у тебя большинство кода такое что он норм - нахрена тебе вообще C++? Тебе сишечки хватило бы. Копировал бы там эти структурки туда-сюда.

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

Ага, сидим и надеемся на компилятор, или нагенерируем еще кучу бойлерплейта, типа аннотаций, аттрибутов, и прочей сранины чтобы компилятору указать «не копируй». Когда можно просто… не копировать. Да. Например просто не делать этого, и тогда весь этот бойлерплейт лишний абсолютно. Но вдруг чужой код это сделает? Причем неявно? И тут начинается, что таки да, лучше на сишечке писать.

В С# нет исключений?

А C# это C#, там исключения это совершенно другое, потому что там есть GC и все остальное.

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

Только оно тебя в большинстве случаев нихера не устраивает, и например копирование объекта по значению прямо со всеми полями в большинстве случаев, прямо подавляющем большинстве случаев - нам нахер не сдалось.

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

вот надо твой плюсовый код проверить на запрет копирования.

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

Я буду переизобретать все парадигмы.

Да это же лисп.

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

в 95 процентах случаев классы надо делать вообще некопируемыми

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

При должном использовании идиомы RAII с классами unique_ptr и их аналогами, запрет на копирование компилятором выводится автоматически.

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

Какой именно?

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

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

нахрена тебе вообще C++? Тебе сишечки хватило бы.

Хотя бы из-за большей безопасности по типам, ваш К.О.

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

Какая безопасность по типам нахер?

Всё, уносите его, он поехавший. У него в C++ безопасность какая-то.

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

Кстати, раз уж вспомнили за CLOS, в том архитектурном косяке с float обмазываться MOP не пробовали?

Да, костыль, но это лисп, тут или шашечки или ехать.

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

Какая безопасность по типам нахер?

Вот такая, например:

struct S {};

void f(void * ptr) {
    struct S * s = ptr;
}
int main() {
    int i;
    f(&i);
}

В плюсах такое присваивание в функции f не скомпилируется. В Си – легко и непринужденно.

У него в C++ безопасность какая-то.

Не какая-то, а чуть большая, чем в Си.

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

Python/Ruby. Программерская – у нас нет типизации

Чегобл???

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

Ты поехавший, эту твою говнину можно скастануть в сишном стиле, или вообще через reinterpret_cast, и все

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

эту твою говнину можно скастануть в сишном стиле, или вообще через reinterpret_cast, и все

И это будет явно видно. Более того, за Сишные касты в приличном обществе бьют по рукам, а на собеседованиях выставляют оценку «no hire».

А вот в Сишке неявные преобразования по типам и ищи-свищи потом.

И это мы еще про типы с explicit-конструкторами речь пока не завели. Хотя, вероятно, это для вас будет слишком уж «modern С++».

Впрочем, свое джуниоство вы прям наотличненько демонстрируете.

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

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

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

Да на тебя за любовь к C++ надо навечно повесить No Hire, как на тех кто NDA конкурентам сливает. Потому что C++ это диагноз сразу.

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

Как же у вас пригорает, когда в предмет разговора не можете. Любо дорого!

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

Нужно больше экспрессии и эпатажа, а то публика уже начинает терять интерес. Скоро Ваши кудри примелькаются и Вас начнут просто… бить.

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

Так ведь для кого-то и Modula-2 с Oberon-ом были отличными языками, и отлично подходили для чьих-то задач.

Для каких? Писать статьи и выбивать гранты?

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

Ага, сидим и надеемся на компилятор, или нагенерируем еще кучу бойлерплейта, типа аннотаций, аттрибутов, и прочей сранины чтобы компилятору указать «не копируй». Когда можно просто… не копировать. Да. Например просто не делать этого, и тогда весь этот бойлерплейт лишний абсолютно. Но вдруг чужой код это сделает? Причем неявно? И тут начинается, что таки да, лучше на сишечке писать.

Да ничего мы надеемся. Мы точно знаем, когда это будет.

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

Ты не очень понимаешь, как это работает, я полагаю.

Но вдруг чужой код это сделает?

Чужой код от студента или школьника? В проектах такие вещи принято учитывать.

нахрена тебе вообще C++? Тебе сишечки хватило бы

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

А C# это C#, там исключения это совершенно другое, потому что там есть GC и все остальное.

Ну блин, ну не такой аргумент же :-)

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

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

Это нужно делать, если иначе это приводит к проблемам. А просто ради соответствия некоторой парадигме - это превращается в какой-то фанатический ритуал.

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

Ну Оберон это наверно самый минимальный универсальный язык высокого уровня и при этом - объектно-ориентированный (правда object не завезли, кек) со статический типизацией (чем уже лучше CL тк это главная причина той архитектурой ошибки у Лавсанчика). При этом он проще своих братьев - Паскаля и Модулы-2.

(хоть бы клюнул жирный оберонщик)

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

А вот в Сишке неявные преобразования по типам и ищи-свищи потом.

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

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

Ну Оберон это наверно самый минимальный универсальный язык высокого уровня и при этом - объектно-ориентированный (правда object не завезли, кек) со статический типизацией (чем уже лучше CL тк это главная причина той архитектурой ошибки у Лавсанчика).

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

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

(хоть бы клюнул жирный оберонщик)

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

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

Дыра это кастовать один объект в другой. Для void* никакой дыры нет, это просто дурость. Лучше бы int-ы заставляли кастовать, а не приводили неявно.

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

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

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