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.

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

А что такое «оправданный выбор»?

Это когда по итогу выясняется, что другие варианты точно не лучше.

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

Ну и про:

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

Интересно, изменилось ли у Yahoo впечатление от выбора Пола Грэма Лиспа в качестве языка реализации веб-магазина после того, как Yahoo пришлось взвалить на себя расходы по его сопровождению и развитию?

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

Скорее всего, Scala слила бы ещё эпичнее, т.к. это JVM. Строки там точно так же не в UTF-8 внутри. Лисп компилирует в машинный код, а не байткод исполняет, а все эти басни про JIT компиляцию разбиваются об опыт работы в явовских IDE.

Вот уж не думал что мне, как C++нику, придется защищать производительность JVM. Но таки вы сильно недооцениваете производительность оной после «прогрева».

Вообще ваша апелляция к UTF-8 выглядит странно. Если все упирается в производительность низкоуровневого кода, манипулирующего байтами в буферах, а Python и Lisp – это всего лишь клей, которым вызовы написанных на Си функций собираются воедино, то в чем был смысл переписывания на Lisp?

Неужели вопрос упирался в быстродействие решения на Python-е?

А преимуществ лиспа у Scala при этом нет.

На Scala запросто можно написать код, который кроме его автора никто не поймет.

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

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

Далее, в программе были алгоритмические проблемы, и я ускорил её примерно в 10 раз. Оставалось лишь где-то 3-кратное отставание от Python, но на эту оптимизацию ушло время. А начальство всё это время стояло над душой.

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

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

то в чем был смысл переписывания на Lisp?

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

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

Но не факт, что это было бы легко реализовать.

Ты ж сам написал "...ПРОСТО научиться..."

лишь где-то 3-кратное отставание от Python

Прекрати, я не могу столько орать, мне больно уже.

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

я написал «просто научиться работать с utf-8», а дальше уже ты сделал выводы о том, что это легко. Не надо было считать собеседника идиотом просто. Просто это в том смысле, что это дало бы возможность избежать конвертирования строк, и проблема производительности была бы решена. Но не факт, что вообще просто.

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

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

И вот тут облом. Лишп можно юзать для устраивания лиспосрачей на ЛОР. Для остального сразу облом.

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

Далее, в программе были алгоритмические проблемы, и я ускорил её примерно в 10 раз. Оставалось лишь где-то 3-кратное отставание от Python, но на эту оптимизацию ушло время. А начальство всё это время стояло над душой.

O_o

O_o

O_o

Да что же такое стало триггером для переписывание на Lisp работающего кода на Python, что в результате всех потраченных усилий результат все равно был тормознее оригинала?

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

Ну это твой выбор, орать или нет. Ты же сам пишешь, что клей. Перекодировка из utf-8 в ucs-2 или как оно там называется - это достаточно дорогостоящая операция по сравнению с простым оборачиванием указателя, и в нашем случае она оказалась дороже всего остального вместе взятого.

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

сокровенное знание больше сегодня не раздаю

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

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

Продолжайте в том же духе если уж вам так нравится.

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

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

например они используются в web assembly для описания кода.

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

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

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

Ох нет, для конфигов s-expr неудобны вообще никак. За s-expr в конфигах надо бить по яйкам с ноги.

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

Это когда по итогу выясняется, что другие варианты точно не лучше.

А что, у кого-то есть ресурсы перебирать все варианты?

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

Это хорошо что вам всем не нужен Lisp.

Мне когда-то ни Visual Basic, ни Ruby не были нужны. А как потребовались, так нашел, въехал и заиспользовал.

Вряд ли Lisp какой-то особенный.

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

А что, у кого-то есть ресурсы перебирать все варианты?

Все и не надо. Трех-четырех, обычно, достаточно. И, что самое смешное, эти три-четыре, как правило, всегда на поверхности в шаговой доступности.

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

смотри какая красота

(system_prefs 
	(single_instance 1)
	(autosave_enable 0)
	(autosave_interval_min 1)
	(check_inactivity 1)
	(check_inactivity_sec 300)
	(save_copy_on_open 0)
	(max_search_results 5000)
	(max_files_search_in 1000)
	(open_ext_docs_readonly 1)
	(web_search_url "http://www.google.com/search?q=$text")

	(files_associations  
		(text 		(".txt"))
		(c++ 		(".cpp" ".h" ".hpp"))
		(scheme 	(".scm"))
	)

	(apps
		(web_search_url "http://www.google.com/search?q=$text")
		(terminal_call "qterminal --workdir $path")
		(ext_editor_call "gedit $path")
		(filemanager_call "nautilus --new-window")
		(merge_tool_call "meld")
		(git_viewer_call "git-cola")
	)
)
alysnix ★★★
()
Ответ на: комментарий от hateyoufeel

За s-expr в конфигах надо бить по яйкам с ноги.

Когда-то очень давно повезло познакомиться с не взлетевшим языком Curl (что-то вроде Lisp-а здорового человека, но с фигурными скобками вместо круглых). После чего лет 15 использовал конфиги в стиле Curl-а, навроде того, что alysnix показал. Очень удобная штука. Аналоги на XML, YAML и JSON, как по мне, так и рядом не стояли.

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

{port 8080}

затем могло стать

{port 8080 {reuse-port}}

что затем могло стать

{port 8080 {reuse-port {failure-timeout 5s}}}

но при этом и самая первая версия все равно оказывалась корректной (остальные значения брались по умолчанию).

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

Мне когда-то ни Visual Basic, ни Ruby не были нужны. А как потребовались, так нашел, въехал и заиспользовал. Вряд ли Lisp какой-то особенный.

Ruby это скриптование для «C». Ousterhout’s dichotomy.
Как и Python. Они склеивают код на «C»(который разрабатывают/поддерживают другие).

tp_for_my_bunghole
()
Ответ на: комментарий от Elidee

Стоит ли смотреть Clojure или это вообще не имеет отношение к лиспу?

Смотреть стоит и даже обязательно, а вот начинать с неё — вряд ли. Для учебного языка лучше взять SICP и схему, затем PCL и common lisp.

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

Однозначно РЕСПЕКТ! за пост.

Не имею права ни критиковать, ни хвалить Лисп, так как не использовал его для разработки.

Надеюсь «лисперам» Вы дадите советы по его использованию.

Что касаемо UTF-8.
Для сайтов - «самое то», для разработки - «самое не то».

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

Ruby это скриптование для «C».

Ну, вам-то конечно же, виднее.

Ruby язык для администрирования системы на замену unix shell.
Случайно один датчанин помог с PHP компании из Чикаго, и его наняли написать web framework на Ruby(on Rails), язык который он сам предложил.

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

Ruby язык для администрирования системы на замену unix shell. Случайно один датчанин помог с PHP компании из Чикаго, и его наняли написать web framework на Ruby(on Rails), язык который он сам предложил.

Ну я же и говорю, вам виднее.

Я, правда, взял Ruby в работу в 2004-ом году, когда RoR еще только-только начинался и никакого хайпа вокруг него не было.

Но да, у меня из Ruby внешние приложения запускались и контролировалось с каким результатом они завершились. Так что, с известной долей гибкости совы, на глобус под названием «замена unix shell» оная натягивается :)))

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

Для учебного языка лучше взять SICP и схему, затем PCL и common lisp.

Emacs лучше чем SICP.
Это Lisp Machine. Хотя мало кто доходит до того что можно прыгнуть курсором на любое определение в Emacs и сразу инструментировать его(рекомпилировать «на лету» со вставкой дебаггера).

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

Так-то у нас в IT сплошь одни истории успешного успеха. Непонятно только чего индустрия всё больше болото напоминает.

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

Встроенная документация в Emacs

по сравнению с SICP как телефонный справочник по сравнению с монографией по истории родного края.

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

В SICP интересные моменты.
«3.3 Modeling with Mutable Data» с инфографикой.
Это поможет в Clojure?

Например queue(очередь). Oдна CONS, где CAR указывает на первый элемент листа, CDR на последний.

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

За s-expr в конфигах надо бить по яйкам с ноги.

Когда-то очень давно повезло познакомиться с не взлетевшим языком Curl (что-то вроде Lisp-а здорового человека, но с фигурными скобками вместо круглых). После чего лет 15 использовал конфиги в стиле Curl-а, навроде того, что alysnixпоказал. Очень удобная штука. Аналоги на XML, YAML и JSON, как по мне, так и рядом не стояли.

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

{port 8080}

затем могло стать

{port 8080 {reuse-port}}

что затем могло стать

{port 8080 {reuse-port {failure-timeout 5s}}}

но при этом и самая первая версия все равно оказывалась корректной (остальные значения брались по умолчанию).

Ну, типа…

port: 8080

port:
 - 8080
 - reuse-port
 
port:
 - 8080
 - { reuse-port: "5s" }

Так? Это YAML.

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

Типа так. Только в YAML-е вам придется с отступами колупаться. Ну и при добавлении параметра к reuse-port вы вынуждены менять

port:
  ...
  - reuse-port

на

port:
  ...
  - { reuse-port: "5s" }
eao197 ★★★★★
()
Ответ на: комментарий от tp_for_my_bunghole

Это поможет в Clojure?

Знание лишним не бывает, но, по-моему, новичку лучше а) нормально пройти SICP со схемой в руках; б) нормально изучить Clojure. А затем уже пытаться комбинировать полученные навыки.

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

Априори считать, что любое событие не является следствием заговора - не менее глупо, чем считать, что любое событие является следствием заговора.

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

Технология NPAPI появилась в 1995 году и использовалась 19 лет. За это время WEB поменялся до неузнаваемости, а NPAPI - нет. первые звоночки что нужно что-то делать появились еще в 2006м, поэтому Гугл и начал делать V8, создав первый прототип в 2008. А от NPAPI отказались аж в 2014м.

Если бы этого не сделали, сейчас у Вас в браузере был бы одновременно колл-центр из Днепропетровска с DDOS-агентом оттуда же.

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

Для учебного языка лучше взять SICP и схему

Спасибо за совет. Есть несколько вопросов по схеме.

  • Есть ли на схеме библиотеки для AWS?
  • Как из схемы работать с базой данных? Тот же Postgres?
  • Как из схемы читать данные из Kafka в avro формате?

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

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

и я ускорил её примерно в 10 раз. Оставалось лишь где-то 3-кратное отставание от Python,

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

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

Вы смогли так поступить потому что у Вас в проекте не было системного архитектора, одна из задач которого и есть «you shall not pass» для подобных моментов.

Спасибо Вам за откровенность в описании неудач и внезапную адекватность как от Лиспера, нынче это редкость.

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

Терпите, лиспер описывает свой процесс взросления и набирания опыта, это же прекрасно и познавательно.

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

пайковский Acme, куда из идеологических соображений не завезли даже (!) подсветки синтаксиса. Зато есть жесты мышью, очень инновационно :)

В дистрибутивах линукса есть его порт под названием «wily». Интерфейс правда «шикарный»: придумать что-то ещё более непонятное и неюзабельное чем vi надо сильно постараться. Спс за на водку. :)

ps. Я тут анекдот про CL вспомнил: примерно в 2010м swizard в своём блоге, кроме разбора как он дизассемблировал bios на acer’овском ноуте и ел овсянку из одной тарелки со своим манулом, запостил решение одной задачи на CL. Не помню какой – был разбор какой-то структуры данных, решение заняло примерно 2-3 экрана текста. На это в комментариях вылез хаскеллист и ту же задачу решил примерно в 5 строчек кода.

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

В команде должен быть человек принимающий на себя ответственность выбора, в чьи обязанности и входит «перебрать все варианты». Частично в голове, частично накидав прототипов. В средне/больших командах это архитект, в маленьких это Синьор/Лид. В соло разработке Вы сам себе сам.

В 90% случаев корни геморроя на проекте лежат в «ну мы знали только язык X»/«наш главный разработчик ХОТЕЛ поработать с Y» поэтому для решения задачи выбрали его. Спрашиваешь, а где этот главный разработчик? Хочется в глаза ему посмотреть. А он уволился полгода назад…

Аж трясет.

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

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

Далее, SICP это не учебник по схеме, схема там используется как иллюстративный материал, потому что так удобнее. Предполагается, что полученные навыки вы потом сможете перенести на любой язык (или написать свой). А практические задачи лучше решать на практических языках — CL и Clojure (которая сама может использовать все Java библиотеки, куда уж больше?).

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

ну мы знали только язык X

Думаю не ошибусь, если предположу, что в плане кругозора лисперы кроют С++/Java/Go кодеров как бык овцу (sic).

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

Думаю не ошибусь, если предположу, что в плане кругозора лисперы кроют С++/Java/Go кодеров как бык овцу (sic).

Что позволяет им с умным видом рассуждать о вещах, в которых они не разбираются (вспоминая того же @den73 с парой его часовых лекций на тему того, на чем нужно писать российскую ОС и российский софт (надеюсь, с темой не напутал))

;)

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

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

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

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

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

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

Да вы просто бох аналогий.

Много довелось в боевых действиях покомандовать?

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

Ну, по крайней мере с превосходством в кругозоре вы согласны. Остальное обсуждаете с den73 как-нибудь без меня.

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