Golang в крупных проектах возможен (back)?

В python есть свой unicorn - uvicorn который лишь немного быстрее.

Python и Ruby сейчас приблизительно одинаковы по скорости.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ruby-python3.html

Мой тейк был в другом - если замена application-сервера на другой, написанный на том же языке, может увеличить метрики по RPS в 5-7 раз, то спецификация языка не является каким-то блокирующим и краеугольным камнем не позволяющим далее увеличивать производительность приложений при сохранении исходной лаконичности и выразительности.

В общем go так-то нормальный, но на нем нельзя делать игры, гуишные программы, серверные монолиты…

Так никто в здравом уме это на нем и не будет делать. Go заточен для веб микросервисов и api шлюзов. Вот это вот «язык общего назначения» - от лукавого.

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

Чувак, ты бы не позорился. Вы в совершенно разных лигах. То, что ты прочитал Столярова не делает из тебя эксперта.

Дженерики тоже существуют. Не все их хотели, но разработчики языка точно не были против.

Сколько они их добавляли 10 или 15 лет? При этом, так и не осилили сделать нормально.

Если «примитивно» обозначает неразвито, то жду предложений по развитию. Только не с академической стороны. Я тоже могу сказать, что линукс говно, потому что не Plan 9. Найди реальный недостаток текущих средств, которые используют для решения современных проблем пользователи этого языка, и покажи как можно делать лучше. Все только спасибо скажут.

Фейспалм.

Python и Ruby сейчас приблизительно одинаковы по скорости.

Что очень плохо для обоих. И если на ruby еще можно что-делать на mid tier, то python уползает в нишу однопользовательских вычислений с развитым мат аппаратом, инференсов для сетей и прочих fastapi поделок-прототипов для 10 одновременных подключений.

Мой тейк был в другом - если замена application-сервера на другой, написанный на том же языке, может увеличить метрики по RPS в 5-7 раз,

Так если в PHP Apache заменить на Nginx то и памяти меньше жрать будет и скорость повыситься без изменения кода. Что не является показателем языка, а является метрикой качества той программы которая используется в качестве сервера.

По тому что философия Go: readability over cleverness.

А философия RubyOnRails: Convention over configuration.

Потому что величина, оторванная в область дипломатии, даёт свои колебания на всю дипломатию. А Илья Муромец даёт колебания только на семью на свою.

Тебя не смутило, что ты сравниваешь палец с жопой? Архитектурный принцип фреймворка с синтаксическими особенностями ЯП.

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

Ты, должно быть, считаешь, что это гениальность, а по факту это простой эффект Даннинга-Крюгера: «Stupid People Have No Idea How Stupid They Are».

Да, тут чет совсем было мимо. Я тоже люблю обезъянничать и передергивать (во всех смыслах), но тут прям широкими мазками.

Сколько они их добавляли 10 или 15 лет?

А сколько нужно было? И почему?

Потому что ты и programmingcirclejerk так захотели. А приоритетам проекта отсутствие дженериков не мешало.

При этом, так и не осилили сделать нормально.

Почему они сделаны именно так, как сделаны, написано здесь: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md

Жду критику.

Фейспалм.

Повтори тоже самое себе между ног.

Тебя не смутило, что ты сравниваешь палец с жопой? Архитектурный принцип фреймворка с синтаксическими особенностями ЯП.

Там вообще провалы в базовых знаниях, определениях и аналогиях.

Молодой человек хочет казаться, а не быть. Отсюда вся тяга к типа академичности, «низкоуровневости», авторитетам и кумира «золотой» эпохи XX века, Юниксы там и Керниганы всякие. Отсюда и эта одержимость Столяровым, так как выяснилось, что кумиры и авторитеты из той эпохи могут оказаться неприятными в общении луддитами.

Это как хипстеры ходившие с молескинами и плёночными фотоаппаратами, в очках с роговыми оправами, просто не заставшие этого и начавшие идеализировать определённые эпохи и подражать эстетике. Так и здесь молодому человеку хочется прикоснуться и быть частью великого и ушедшего. Роб Пайк, Plan 9 тут как величественные заклинания и упоминания магов прошлого, а Go как оставшийся могучий артефакт и концепт старой эпохи в современной обёртке готовый к использованию, в отличие от Паскаля.

Отсюда и эта одержимость Столяровым

Котирование Столярова это признак проф непригодности. Тут даже и обсуждать нечего.

Если бы дело было именно что в спецификации языка, то такие проекты как GopherJS уже давно бы вытеснили Typescript на фронте

Они в компиляторе Go этот GopherJS взяли за основу при реализации компиляции в WASM.

Главная причина его нераспространённости в другом: на выходе получаются портянки в десятки мегабайт и авторы не считали это проблемой. В результате, и WASM у них такой же. Русс Членс (Cox) обосновал на багтрекере решение так: на Go никто фронт не пишет, поэтому гнаться за размером нет смысла, главное, чтобы с минимальн. А не пишут именно потому, что размеры неадекватные. Получается замкыми усилиями реализовать поддержку как можно большей части стандартной библиотекинутый круг.

Русс Членс (Cox) обосновал на багтрекере решение так: на Go никто фронт не пишет, поэтому гнаться за размером нет смысла, главное, чтобы с минимальными усилиями реализовать поддержку как можно большей части стандартной библиотеки. А не пишут именно потому, что размеры неадекватные. Получается замкнутый круг.

Ну насчёт игр я согласен, это экзотическая область сама по себе. Хотя для пет-проекта пойдёт.

Цивилизация 4 была на python, ну уже точно на python2 была Blade of Darkness.

Go заточен для веб микросервисов и api шлюзов. Вот это вот «язык общего назначения» - от лукавого.

Так не заточен. Просто всё, чего нет объявляется ненужным. И все стандартные примитивы, от структур данных, до роутера в нём с самого начала были абсолютно убогими, написанными под девизом «и так сойдёт».

Так не заточен. Просто всё, чего нет объявляется ненужным.

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

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

Лучше объясни как куб написать на баше. Это интересно, люди ещё о таком, вроде, не слышали.

И все стандартные примитивы, от структур данных, до роутера в нём с самого начала были абсолютно убогими, написанными под девизом «и так сойдёт».

Го примеры. Желательно с комментарием «и так сойдёт».

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

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

А я думал потому, что эта ниша занята JavaScript и TypeScript. Я вообще плохо представляю, зачем человек захочет писать фронт на Go. Безусловно, 90% желающих писать фронт на Go будут разочарованы неадекватными размерами, но эти 90% — это условно 1% всего фронтенда, на что, вероятно, и указывал Расс.

Кстати, анон, какая у тебя фамилия?

Так если в PHP Apache заменить на Nginx то и памяти меньше жрать будет и скорость повыситься без изменения кода. Что не является показателем языка, а является метрикой качества той программы которая используется в качестве сервера.

Ещё канонический пример из последних релизов Ruby - переписывание реализаций стандартных итераторов Integer#times и Array#each с сишной реализации на рубишную. Традиционно это было написано на Си (хотя судя по примерам разница со старой реализации с интепретируемой реализацией на Ruby даже не кратна - 1.2 раза для times и 1.36 раз для each в пользу сишной версии).

После внедрения JIT, чистая рубишная реализация в одном и том же бенчбарке стала обгонять сишную в 3.51 и 5.32 раз(!).

За счёт JIT’а и более оптимального кэширования (т.к. артефакты JIT можно использовать и как метаданные для предсказания типов и размера (shape) объектов) и, что не менее важно, за счёт избавления от интенсивного интеропа с Си и оверхеда на дёрганье сишных функций, который раньше был вынужденным трейдофом, а сейчас стал избыточным во многих местах по описанной выше причине. На случай если пост читают идиоты, повторюсь - это не Си функции медленные, а интероп с Ruby VM отнюдь не бесплатен и имеет свои, пусть и небольшие, накладные расходы.

https://github.com/ruby/ruby/pull/6687 https://github.com/ruby/ruby/pull/8388

Т.е. базовая реализация (MRI) постепенно ускоряется за счёт переписывания частей базовой библиотеки на самом Ruby и это сейчас тренд. Спецификация языка от этого не поменялась, весь код использовавший эти методы (а это любой код сложнее Hello, world) как работал так продолжает работать без изменений.

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

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

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

Именно поэтому все эти единороги не тратят уже деньги на переписывание всего и вся, даже несмотря на размер существующей кодовой базы (уж в ковидное время хайрили всё что движется, чтобы застолбить и загрузить хоть какой-нибудь зачастую вообще бесполезной работой), а просто переписали небольшие критические участки на чем-то более оптимальном на свой вкус и в ус не дуют). Потому что профиты и бенефиты не всегда очевидны - одна строчка кода на Ruby ждёт ответа от базы или S3 или десять строчек на Go.

Я знаю только один кейс переписывания (или расширения) Руби на Го. Сбермаркет. Но я в сбере не работал, поэтому, увы, подробностей не знаю.

А я думал потому, что эта ниша занята JavaScript и TypeScript. Я вообще плохо представляю, зачем человек захочет писать фронт на Go.

Выше ж товарищ доказывал, что это уникальный дизайн самого языка делает его почти идеальным:

Golang читается как художественное произведение

Об унификации кода и его читабильности как о основном достижении сказано Робом Пайком

Focusing on readability over cleverness, compatibility guaranty, and … the most interesting consequence of these matters is that Go code looks and works the same regardless of who’s writing it.

It is largely free of factions using different subsets of the language and is guaranteed to continue to compile and run as time goes on. That may be the first for a major programming language.

(c) Rob Pike

Rob Pike - What We Got Right, What We Got Wrong | GopherConAU 2023

Это ж какие-то киллер фичи и серебрянная пуля, которые по мнению этого товарища должны подминать под себя всё :)

Что GopherJS, что Typescript релизнулись в 2012, а второй просто кишит всеми «недостатками», но как-то занял нишу, хотя маркетинг Google по отношению к Go не то что бы сильно уступал Microsoft и Typescript. Это не Elm какой-нибудь там.

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

Я знаю только один кейс переписывания (или расширения) Руби на Го. Сбермаркет. Но я в сбере не работал, поэтому, увы, подробностей не знаю.

Я сам знаю много кейсов расширения и я только ЗА. Гибридная архитектура и разделение на специализации это очень хорошо и удобно. Бизнесу так в особенности.

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

Fair enough. Я говорил «не знаю зачем Go во фронте» относительно последних пяти лет, когда TypeScript уже имел очень крепкую позицию.

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

Все крупные веб проекты чтобы опен и что я видел написаны на go + ts. Таже графана к примеру.

После внедрения JIT, чистая рубишная реализация в одном и том же бенчбарке стала обгонять сишную в 3.51 и 5.32 раз(!).

Буквально, идете по стопам PHP. JIT завели еще с 8й версии.

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

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

Я понимаю о чем вы говорите, но это никак не даст Ruby догнать Go по скорости и потреблению ресурсов. Даже PHP не догонит, но это хотя бы относительно реальная цель.

Интепретируемый язык не догонит компилируемый. Язык с динамической типизацией не будет быстрее языка со статической типизацией (при прочих равных).

Поэтому я не вижу никакого смысла рассуждать о скорости ruby там где и PHP и Go быстрее.

Golang читается как художественное произведение

Golang читается как выход недоученной нейронной сети. Особенно в местах сборки/разборки вложенных массивов JSON структур.

Котирование Столярова это признак проф непригодности. Тут даже и обсуждать нечего.

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

Огульный хейт Столярова — это хейт программы МГУ. Столяров свои книги не с потолка взял. Это последовательное изложение одного курса лекций за другим.

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

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

Огульный хейт Столярова — это хейт программы МГУ

МГУ большой, не надо так обобщать. Нас на химфаке Абраменков только хорошему учил:)

Огульный хейт Столярова — это хейт программы МГУ

У тебя что ни пост, то аппеляция к авторитету. Ты сам когда-нибудь думаешь?

Членс. Мы с Рассом однофамильцы.

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

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

Когда спрашивают «можно ли срать на потолке»

Как раз это и описывает кубер на баше. Ты сделал мой день…, нет, челую неделю.

Как раз это и описывает кубер на баше

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

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

Чем таким админские задачи принципиально отличаются от любых других задач - бухгалтерских, конструкторских, аналитических

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

бухгалтерских, конструкторских, аналитических

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

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

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

А в чем прикол?

Там много разных компонентов. Только etcd уже жутко неудобно на баше писать. Балансировка нагрузки в соответствии с декларациями реурсов - стрёмно на баше, а вот на go (да хоть на php) намного удобнее.

Поэтому когда говорят «срать на потолок» - это больше про баш, чем про go.

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

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

Там много разных компонентов.

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

ЯП-ы тут вообще по барабану, на любом из них задача полностью не решаема.

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

Собственно, деды так и жили.

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

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

Ну давай, разработай жопоподтирательную машину величиной с карьерный самосвал. Чтоб чувствовать превосходство над дидами. Только дидам не показывай, от смеху с пальмы рухнут.

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

тебе рассказать технологический процесс производства туалетной бумаги от сырья до полки в магазине или сам нагуглишь на ютуб-канале «Как это сделано»?

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

Только etcd уже жутко неудобно на баше писать

У нас же баш. Значит в качестве базы данных нужно использовать файловую систему. В данном случае — кластерную (не пытайтесь повторить это в проде, работают клоуны-профессионалы). После этого половина кубернетеса сводиться к diff между файлами с желаемой и текущей конфигурацией ресурса.

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

Примеров бы, поясняющих о чём речь.

И это не значит, что так и должно быть

Описание того, что есть - не эквивалентно мненению, что так дожно быть.

А то, что есть - «кубер - крупный проект - бэкенд на go». ¯_(ツ)/¯¯_(ツ)/¯