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.

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

ну всяко не брэйнфак

сама идея косвенного шитого кода - интересная диковинка

как и S-выражения - буквально ассемблер

M-выражения жаль

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

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

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

жаль что

медиа и есть сообщение (ага его самого )

так сильно повлияло

т.е реальная сильная сторона Лиспа собственный интерпретатор на себе в пару страниц - заслонено одним из вариантов представления:

оскобачиванием

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

а так конечно точечная пара универсална

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

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

Украинский вполне хороший язык

как и любой ествесвеный язык(диалект и прочая прочая) общения отражающий ту или иную общность

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

А если у кого-то криокамера протечёт и он начнёт тут язык падонкаф восстанавливать, нам тоже общаться с ним, как с нормальным?

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

оскобачиванием

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

другое дело, что «нечто другое» может быть более читабельно, но это особенности нашего восприятия.

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

ну при борьбе с чем либо не есть победа уподобление тому с чем.

тут нет нормы :)

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

Надо сперва сформулировать: «какую проблему мы пытаемся решить». Потому как для лисперов скобки это решение, а не проблема. А остальным лисп не нужен ни со скобками, ни с пробелами.

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

форту и скобки не нужно

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

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

я вот тоже когда-то переходя с модула-2/дельфи на си++ не мог воспринимать этот сишный синтаксис. дабы не ломать глаза просто написал макры

#define IF if(
#define THEN ){
#define ELSE }else{
#define END }
ну и так далее

после чего сишный текст почти превращался в текст на Modula-2

IF a>b THEN ... ELSE .... END

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

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

«Спізнитися». «С» обозначает совершенную форму.

лат. forma, греч. μορφή

Где-то за пределами цивилизации записали «при».

лат. civilis — гражданский, государственный

Они смогли представить только физическое место к которому не успели.

др.-греч. φυσική — «природный

Ничего абстрактного.

лат. abstractio «отвлечение»

Есть языки, которые пытаются быть ближе к своему древнерусскому ядру и языки «пылесосы» - активно вбирающие в себя иностранную лексику.

Богатство и разнообразие языков это хорошая аналогия к языкам программирования. На таких языках очень хорошо и детально можно выражать свои мысли, заниматься творчеством. Есть канцелярит - когда текст становится машинным и безжизненным. Сложилось впечатление, что Lisp это больше творческий язык с богатыми возможностями, а Go это вот тот самый язык для бюрократии - минимум выразительных средств и только один явный способ реализации. Вот хотите сделать неповторимую интелектуальную систему - берите CL какой, а если «перекладывать кирпичи» с утра до вечера, то берите Go (Java, C#).

Каким языком пользоваться определяется вашими целями.

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

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

хэкскодом больше килобайт помещалось - тем более у тех компов был монитор вшит с возможностью ввода heх - т.е инженерно это(печать листингов байтов как пар hex) - было годно

а вы не грустите

А, конечно. Вспомнились статьи из детства про катастрофическую ситуацию с производством компакт-кассет. Они доступными стали в 90-х.
И в сёлах СССР не было телефонных линий в частные дома. В городах частично.
Тогда объяснимо.

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

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

Есть языки, которые пытаются быть ближе к своему древнерусскому ядру и языки «пылесосы» - активно вбирающие в себя иностранную лексику.

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

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

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

вот как раз - пылесосить - это активно расширять понятийный аппарат.

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

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

Твой выбор - оператор. Можно добавить чего.

Тот кто у компа - оператор ЭВМ.
Statement - оператор.
«+» - оператор.
Оператор крана-манипулятора.

В общероссийском классификаторе профессий (ОКПДТР) приводятся около 350-ти различных операторских профессий и 20-ти операторских должностей.

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

Lisp: (+ 1 2)

Forth: 1 2 +

А как будет (lambda (x) (* x x)) на Форте?

как такое без скобочек изобразить?

Полагаю, что так же — 3 2 1 +. Все аргументы на стек, потом функцию, которая их оттуда заберёт и поместит туда результат.

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

3 2 1 + +

4 3 2 1 + + +

  • 2 1 + 3 +
  • 2 1 + 3 4 + или 2 1 + 3 + 4 +

Но зачем, если можно просто 4 3 2 1 +? Опасаетесь, что у стека днище выбьет? %)

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

А как будет (lambda (x) (* x x)) на Форте?

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

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

А как функция узнает когда пора перестать забирать аргументы со стека?

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

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

Но зачем, если можно просто 4 3 2 1 +? Опасаетесь, что у стека днище выбьет? %)

Слово «+» не функция. В Forth нет функций, нет параметров.

… Пусть это будет оператор.

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

как функция узнает когда пора перестать забирать аргументы со стека?

Пробежал по диагонали туториал — для разного количества аргументов нужны разные функции, например, 2+ для сложения двух чисел и 3+ для сложения трёх. Для разных типов аргументов тоже разные функции.

Зато становится понятно, откуда растут уши у вимовских : и 2b345dfgh %)

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

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

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

форт это отличная замена той же сишечке

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

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

В C указатели.
В Forth опираторы.
В Lisp скобочки.
В Python пробелы.

вот только от человеческого фактора не избавиться

Factor это развитие Forth, создатель Slava Pestov, автор редактора jEdit.
Это был лучший редактор на Java, что-то в нём привлекало.

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

Брейнфак ещё проще, а толку? Хрен поймёшь как из стека и примитивных операций над ним сообразить что-нибудь полезное.

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

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

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

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

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

С нормальными инструментами любой может дачный дом построить

Ещё есть отстатки от совкового запрета на постройку капитальных зданий со снятием грунта на выданных участках(«дачах»)?
У «дачного» дома должны быть особенности.

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

стек и примитивные операции это буквально описания языка Си

но чето да соображают на нем

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

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

О, лиспосрач. Как в старые добрые времена. Я приведу несколько аргументов за Го:

  • это компилятор. Значит сразу хороший множитель для скорости
  • сборка мусора. Отличный множитель к надёжности
  • в нём достаточно встроенных структур данных: массивы и словари. Как в лиспе почти что, только консов не хватает.
  • для него можно создать IDE, т.к. статическая типизация и нет препроцессора. Это редкое преимущество. Ни для лиспа, ни для С++ IDE создать нельзя. Хотя для Жабы можно, но см. пункт 1
  • новые люди становятся всё тупее, сказывается развращённость родителей, включая увлечение разными веществами, и детство, проведённое за гаджетами, поэтому Гугл правильно оценил рынок рабочей силы
  • бюрократия одинаково ест любую крупную организацию, будь то даже Эпл или Микрософт, поэтому тут все в равном положении
  • минимальные средства абстракции в лице интерфейсов есть, а ООП в стиле C++/Java всё равно сильно неудачное, поэтому избавление от него может считаться выигрышем
  • горутины неплохи и могут считаться шагом вперёд для своего класса задач по сравнению с тредами и циклом обработки сообщений
  • объявление имя: тип, а не тип имя для сложных типов даёт большое преимущество, т.к. оно читается слева направо, в отличие от Си, Явы, C#. Т.е. тоже исправлена многолетняя ошибка проектирования, которая не столь важна, как ООП, но тоже влияет на производительность труда.

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

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

ulisp. Не знаю, что я хотел этим сказать, но я вчера чуть не взялся его запускать. Удержался. Если не врёт ChatGPT, то ulisp для STM32 умеет в горячую замену кода, ассемблерные вставки и им можно управлять через SLIME. Какой там форт тогда.

Но форт я уважаю, через него я пришёл к лиспу. Компилирующие слова. Хотя на нём ни строчки не написал, только книжку прочитал.

Но мне кажется ли, что Форт оптимизирован под экономию памяти, а скорость у него уступает ассемблеру и сям и поэтому он не вполне конкурентоспособен для промышленных применений? В таких устройствах КМК дешевизна устройства обычно важнее дешевизны разработчика, потому что очень большой тираж. Вот на этапе исследований и прототипирования Форт может быть по делу. Или если дешевизна важнее скорости.

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

Проблемой являются не сами скобки, а их количество и вложенность. Правильное решение:

(perga
  (let a 1)
  (:@ with-open-file (b "file" ...))
  (let *print-base* 16)
  (print a b))

Я это написал без IDE и не ошибся в количестве скобок. А вот как это выглядит по канонам:

(let ((a 1))
  (with-open-file (b "file" ...))
    (let ((*print-base* 16))
      (print a b))))

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

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

Хотя если бы в Го была библиотека pygments, то я бы, наверное, начал писать на Го. Возможно, она и есть, просто я про неё не знаю.

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

особенно в части с++

В C++ есть шаблоны, раскрывающиеся в compile-time по принципу утиной типизации. Поэтому когда вы пишете шаблон:

template< typename T >
void f(T & a) {
  a. // (1)
}

то в точке (1) IDE не может вам предложить autocomplete, т.к. не известно что за T вы ожидаете.

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

Из-за препроцессора и отсутствия понятия «проект». Программа на Си/Си++ является бесконечным параметрическим семейством программ, потому что при сборке можно передать -Dprintf=шли_всё_в_АНБ и так для любого символа, и так отдельно в каждом файле.

Поэтому прочитать программу на Си/++, не собрав её, принципально нельзя. Есть костыли - compile_commands.json, bear и иже с ними. Но они позволяют работать лишь с одной конфигурацией из бесконечного множества. Считать ли работу с одной конфигурацией работой с программой - это дело совести того, кто так говорит.

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

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

то в точке (1) IDE не может вам предложить autocomplete, т.к. не известно что за T вы ожидаете.

это честно и нестрашно. зато если тип известен, даже в шаблоне, автокомплит будет.

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

это честно и нестрашно.

Кому как. Для кого-то среда, которая не может в подобный автокомплит (и завязанные на него рефакторинги) уже и не IDE.

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

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

все это можно сделать для с++ и потому IDE для c++ существуют.

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

массивы и словари. Как в лиспе почти что, только консов не хватает.

Берёшь структуру с двумя полями, тяп-ляп — вот и вышел конс.

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

Из-за препроцессора и отсутствия понятия «проект».

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

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

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

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

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

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