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

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

Он ничего не считает, это чья-та тупая нейросетка.

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

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

• На нем написаны yay, docker и caddy.
• yay — это обертка над pacman, поддерживающая aur.
• caddy — быстрый проксирующий сервер…
• docker в представлении не нуждается…
• yay и docker можно было бы написать на питон, но go тут используется за его портативность, его бинарники жирные, так как содержат рантайм и зависят лишь от сишной либы, если собраны без спец флага…
• caddy хорош своей простотой… на этом все. на c сложнее писать, но любой сишный код на порядок эффективнее может управлять памятью

Итого: Go - это говноязык с примитивным синтаксисом, разработанный для «як-як и в продакшен», когда некогда думать над красотой кода и тп, поэтому из него выбросили все ненужное для быдлокодеров.

Ты пишешь чушь. Про C++ тот же. Go не призван его заменить.

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

The Go Programming Language первые 10 минут рассказа.

Go - это говноязык с примитивным синтаксисом, разработанный для «як-як и в продакшен»,

В Go не примитивный синтаксис; одна концепция slice как структуры над array чего стоит. Синтаксис Go однозначный и без синонимов — это да, но он не примитивный. И как раз «як-як» и в продакшен быстре на более высокоуровневых языках с динамической типизацией таких как Ruby, Perl и Python. На строгом Golang требуется больше строк кода.

При всём уважении к вашим заслугам на LOR, ваша квалификация немного не дотягивает до уровня создателей UNIX, UTF-8 и инженеров компании Google. Golang это больше чем язык, это подход к разработке, который надо хотя бы постораться понять. Чего вы не собираетесь делать.

«Go is a project to make building production software easier and more productive.» (c) Rob Pike

https://youtu.be/yE5Tpp2BSGw?si=Zl1C4YBZ3Fj0fpws

Поэтому любой рекурсивный алгоритм грозит закончиться былинным отказом

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

ненужное для быдлокодеров.

Вы очень токсичны, категоричны и самоуверенны.

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

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

Супер. Респект.

UPD:

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

caddy хорош своей простотой… на этом все. на c сложнее писать, но любой сишный код на порядок эффективнее может управлять памятью

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

Вот в магазине двадцать два она может расщепиться, экономика! На экономистов, на диспетчеров, на продавцов, на культуру торговли…

Микросервисы на Go: расщеплённый учебник.

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

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

Conclusion

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

Go создал Гугл для себя, тк тысячу индусов Пишущих на С++

Нет, Go создали сотрудники гугла, на деньги гугла и для решения проблемы гугла индусы vs C++.

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

Другими словами Go такой из-за его основной аудитории, а не аудитория такая из-за языка.

Какая аудитория? Там минимум два концепта slice и прокладки в виде io интерфейсов которые уже недоступны типичным вайтишникам. Про устройство HTTP серверов я уже не упоминаю. Там и близко не RoR/Laravel.

Использовать C++ для серверов протоколов уровня приложений — это как стрелять из пушки по воробьям; ручное управление памятью избыточно. Скорости выполнения интерпретируемых языков и Java недостаточно. Сделали Go специально под конкретную задачу.

Народ потянулся: там, где 20 серверов на Ruby, нужен 1 на Golang. Хитрые крупные сайты писать на высокоуровневом языке не проще; там начинается конструирование того же Golang с линтерами и выбором подмножества языка. Всё висит, еле проверяется, требует 164 дополнительных инструмента. Вносятся правки в фреймворк. Написать все сразу на Golang в данной ситауции не сложней.

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

Народ потянулся: там, где 20 серверов на Ruby, нужен 1 на Golang. Хитрые крупные сайты писать на высокоуровневом языке не проще; там начинается конструирование того же Golang с линтерами и выбором подмножества языка. Всё висит, еле проверяется, требует 164 дополнительных инструмента. Вносятся правки в фреймворк. Написать все сразу на Golang в данной ситауции не сложней.

Нужно быть душевнобольным, чтобы сравнивать это. Линтеры используются повсеместно и давно, по общепонятным причинам, или golint и go vet это не линтеры? Причём тут линтеры?

Какие ещё подмножества Ruby?

Когда у вас будет 20 серверов на современном Ruby, где именно VM Ruby станет узким местом, то у вас уже будут миллионы ревеню, чтоб переписать узкие места на чём угодно или вынести написанный на чём угодно микросервис.

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

Поэтому именно что

Написать все сразу на Golang в данной ситуации сложней

Если вы с нуля захотите написать свой Shopify, Airbnb, Stripe или Kickstarter.

И просто зачастую в связи с этим ненужно. Не говоря уже о том, что затянутое прототипирование устраняет самое главное преимущество прототипирования - понимание того нужно ли это вообще сейчас.

Линтеры используются повсеместно и давно, по общепонятным причинам, или golint и go vet это не линтеры? Причём тут линтеры?

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

Какие ещё подмножества Ruby?

Синтаксические.

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

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

Вот на Golang в микросервисы и выносят. Потому, что потребление ресурсов в сравнении с Ruby на порядок меньше.

И просто зачастую в связи с этим ненужно. Не говоря уже о том, что затянутое прототипирование устраняет самое главное преимущество прототипирования - понимание того нужно ли это вообще сейчас)

Вот видите каокой вы умный. Раз раз и доказали что Golang не нужен. А люди мучаются, пишут на нем зачем-то. Не понимают про прототипроивание.

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

Пониматете, тут такое дело. Что код RubyOnRails практически не подлежит чтению, его можно только разбирать с дебагером. Когда проект действительно большой то кодовая база Ruby начинает расти и захламлятся, появлястся всякие настройки, над настройками, над настройками как например https://trailblazer.to/2.1/. Их много и они разные.

По этому наступает такой момент, когда написать на Go: быстрей, проще и надежней. И команда будет лучше понимать код. По этому люди пошли с Ruby на Go массово.

Хотя для мательнких проектов, Ruby это очень уобный и лаконичный язык.

Синтаксические.

Примеры?

Вот на Golang в микросервисы и выносят. Потому, что потребление ресурсов в сравнении с Ruby на порядок меньше.

Разумеется выносят, как выносят и на Java, .NET Core, Rust, Crystal.

Я сам выношу, в том числе и на Go, но это считанные проценты от общей кодовой базы.

Вот видите каокой вы умный. Раз раз и доказали что Golang не нужен. А люди мучаются, пишут на нем зачем-то. Не понимают про прототипроивание.

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

Скорости выполнения интерпретируемых языков и Java недостаточно.

Скорости выполнения интерпретируемых языков и Java в преобладающем количестве случаев для веб-бэкэнда абсолютно достаточно. Мало кто пишет фейсбуки по три штуки в неделю.

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

Примеры?

В Ruby большое количество синонимов, множество дублирующих управляющих структур. В Golang унифицированный ситатксис, однозначное форматриование через go fmt. Об унификации кода и его читабильности как о основном достижении сказано Робом Пайком. Вам этого не достаточно?

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

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

Конечно. В преобладающем количестве случаев. А вот в Google был не преобладающий случай и там написали Golang.

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

Какое это отношение имеет к языку спроектированному в Google для решения внтуренних задач крупной корпорации?

Пониматете, тут такое дело. Что код RubyOnRails практически не подлежит чтению, его можно только разбирать с дебагером.

Если не знать Ruby on Rails, то конечно. Вот такое дело, понимаете. Если не уметь читать, то текст не подлежит чтению.

По этому люди пошли с Ruby на Go массово.

Кто куда пошёл? Опять никаких примеров. Массово люди начали распиливать свои монолиты в пользу гибридной архитектуры: полумонолит с микросервисами. Тут есть место для Go, как и для других упомянутый мной вещей: Java, .NET Core, Rust, Crystal.

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

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

А почему мне должно быть этого достаточно?

Какое это отношение имеет к языку спроектированному в Google для решения внтуренних задач крупной корпорации?

Точно дурка. А я то думал откуда корни сталкеризма за Столяровым.

Вы с кем спорите? Я комментировал ваше:

Скорости выполнения интерпретируемых языков и Java недостаточно. Сделали Go специально под конкретную задачу.

Народ потянулся: там, где 20 серверов на Ruby, нужен 1 на Golang.

Народ в Google потянулся? Они никогда его не использовали, отдавая предпочтение Python. Я знаю только один продукт Google на Ruby и то купленный в 2017: https://fastlane.tools

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

Если не знать Ruby on Rails, то конечно

Ага, то-то на конференция по RubyOnRails создают доклады как быстро разобраться в коде RubyOnRais.

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

Кто куда пошёл? Опять никаких примеров

От противного. Ни кто ни куда не пошел. Golang это редкий, мало испльзуемый экзотический язык. И вам надо привести примеры его использования, потому-что их нет.

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

Тут есть место для Go, как и для других упомянутый мной вещей: Java, .NET Core, Rust, Crystal.

Не понятно зачем вы это пишите. Ни где я не говорил что Golang безальтернативен. Он популярен и на это есть свои причины. И он сложен в ряде параметров, по этому не многими не любим, на это тоже есть свои причины.

Golang это не язык для новичков. Хоть он и заявлятется как супер простой и понятный. Это не так. Он не простой и не понятный для человека без основательного фундамента знаний по программированию. Почему я писал выше.

А почему мне должно быть этого достаточно?

Точно дурка. А я то думал откуда корни сталкеризма за Столяровым.

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

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

Ага, то-то на конференция по RubyOnRails создают доклады как быстро разобраться в коде RubyOnRais.

Внезапно! А что делают на конференциях по Go? Не создают доклады как в чём-то разобраться или чему-то научиться, а играют в карты и пьют портвейн?

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

Это моя основная работа уже лет 17. Равно как и Go, но 5.

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

Классические черты школьника-фанбоя,

Ага, именно так: оскорбляете и обзываетесь вы, а фанбой я.

Это моя основная работа уже лет 17. Равно как и Go, но 5.

Что-то я вам не верю. Что вы так плотно работаете с Ruby. У вас бы вопросов про синонимы не возникало c reduce/reject, map/collect и с добрый десяток способов писать все разновидности lambda.

Хотя всё зависит от интенсивности, можно 25 лет работать и много чего не знать и не уметь. В целом, смешно получается: полагаться на авторитет создателя UTF-8 и Plan 9 — это дилетанство, а хвастаться временм работы — профессионализм.

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

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

Это моя основная работа уже лет 17. Равно как и Go, но 5.

Время и результат

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

— Почему я должен поступать так, как ты мне говоришь? — спросил Насреддин.

— Потому что я тебя старше! — вскричал человек, оглаживая бороду.

Тогда Насреддин заметил:

— Насыщает не время, проведённое в чайхане, а количество съеденного плова!

Что-то я вам не верю. Что вы так плотно работаете с Ruby. У вас бы вопросов про синонимы не возникало c reduce/reject, map/collect и с добрый десяток способов писать все разновидности lambda.

Потому что с синонимами нет никаких проблем, равно как и с лямбдами.

В целом, смешно получается: полагаться на авторитет создателя UTF-8 и Plan9 — это дилетанство, а хвастаться 17 годами работы — профессионализм.

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

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

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

Это не проблема для интепретируемого языка.

Я попытался перечислись крупные проекты, где Ruby был и остаётся ключевым языком - Github, Stripe, Airbnb, Shopify, Kickstarter, Twitch, Zendesk, Soundcloud. 100% из них используют микросервисы и несколько стеков одновременно, но ни никакого полного замещения не наблюдается, наоборот, компании получают бенефиты от мультипарадигмы. Вот цитата из блога Stripe

Stripe’s entire Ruby codebase, currently amounting to over 15 million lines of code spread across 150,000 files. Ruby fits in alongside a handful of other languages in use at Stripe. Stripe is also deeply investing in building new product backends in Java, building delightful frontend experiences with TypeScript, and various pieces of infrastructure in Go.

Из крупных проектов вспоминаю только Twitter, но перешли на Java/Scala ещё при царе Горохе.

Все вышеописанные продукты это сложные системы с кучей customer-facing бизнес-логики под капотом.

Go 1.0 вышел в 2012. Из самого популярного и крутого на нём написанного за 13 лет приходит на ум только Docker, Kubernetes, Terraform. Как уже было сказано кем-то в этой теме, основным преимуществом тут был не сам язык, а удобная форма дистрибуции, которая очень хорошо ложится на задачу. Сама же суть тут это обвязка и клей, основанная на дёрганьи примитивов GNU/Linux (capabilities, cgroups etc.), c чем бы справился прекрасно и Python и Ruby и Perl и т.п., но распространять это дело и зависимости было бы гораздо менее удобно.

Никакого победоносного шествия не наблюдается, гибриды подавляюще преобладают. Задача и сроки предполают выбор инструмента, а не инструмент ставится во главу угла. А Python шагает на первом месте, потому что экосистема, простота и сообщество важнее.

Это не проблема для интепретируемого языка.

Т.е. концепцию читабильности кода вы так осознать и не смогли.

Вот цитата из блога Stripe

and various pieces of infrastructure in Go.

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

• https://go.dev/solutions/case-studies
• https://medium.com/@AzilenTech/golang-development-144c0c4e6228

И статья пятилетней даностии о экономии ресурсов, описывает миграции с Ruby на Golang в то время. Что я описал как «вместо 20 серверов на Ruby, один на Go».

Никакого победоносного шествия не наблюдается, гибриды подавляюще преобладают. Задача и сроки предполают выбор инструмента, а не инструмент ставится во главу угла. А Python шагает на первом месте, потому что экосистема, простота и сообщество важнее.

Все же любите вы ломиться в открытые двери.

https://medium.com/@AzilenTech/golang-development-144c0c4e6228

И это тоже про various pieces of infrastructure in Go. Про полный отказ кого-либо в пользу исключительно Go в виду его какой-то там исключительности - ничего такого нет.

И статья пятилетней даностии о экономии ресурсов

Это статья ничего не говорит про кодовую базу. Без метрик выработки (churn) и сложности (complexity) непонятны как тут замешаны ограничения языка, как такового.

Касательно содержимого статьи: cейчас в Ruby вместо обычных тредов есть файберы, что даёт прирост в конкуретных задачах используя MRI в 5+ раз:

https://habr.com/en/companies/ecom_tech/articles/705510/

https://www.codeotaku.com/journal/2018-06/improving-ruby-concurrency/index#performance

Тут получили такой прирост просто поменяв application-сервер, никакая спецификация и синтаксис языка Ruby при этом не изменялись, использовалась одинаковая версия MRI.

Вы ещё, кажется, не понимаете разницу между реализацией и спецификацией.

Далее:

I was a fresh graduate and I neither had the knowledge nor the experience

We were using capistrano to deploy and unicorn as the http server, devise to authenticate.

Основная проблема тут это однотредовый application-сервер unicorn и в том, что первый проект писал абсолютный новичок. Тут хоть переписывание на Python или полный рефакторинг с высоты опыта уже бы дало многократный прирост.

Если этот нонейм-пример является примером какого-то мирового триумфа Go в качестве языка для разработки web-бэкенда, то всё весьма печально с аргументацией, конечно…

Из крупных проектов вспоминаю только Twitter, но перешли на Java/Scala ещё при царе Горохе

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

Итого: Go - это говноязык с примитивным синтаксисом,

Типа если синтаксис не примитивный то + что ли? Хм.

разработанный для «як-як и в продакшен»,

Ну мы вроде в рынке живем, денег быстрее срубать.

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

Вот это вообще не понял.

• Примитивный синтаксис и и думать над красотой кода, т.е. красота кода это когда синтаксис через мерно сложный что ли?

поэтому из него выбросили все ненужное для быдлокодеров.

Иными словами в ЯП пихают все ненужное для людей думающих что они не быдлокодеры так что ли?

Ну хорошо.Такой пример. В govno нет шаблонов. Поэтому нужны MaxInt, MaxInt32, MaxInt64, MaxFloat… Это примитивно и неудобно. Ты копипастишь код вручную в то время как это может делать коНпелятор…

Я мало на go писал и не совсем вас понимаю причем тут это. Насколько я помню : MaxInt, MaxInt32, MaxInt64, MaxFloat это из пакета math, math.MaxInt и т.д.

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

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

Насколько я понял его делали для замены питона на серверах … но не уверен.

А что такое: серверные монолиты?

Ну в нем есть все основные принципы ООП и по сути его таким и считают.

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

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

дженерики…

Кстати вот что написали в патчноуту к go 1.24

...
Go 1.24 now fully supports generic type aliases: a type alias may be parameterized like a defined type. See the language spec for details. For now, the feature can be disabled by setting GOEXPERIMENT=noaliastypeparams; but the aliastypeparams setting will be removed for Go 1.25.
...

Если этот нонейм-пример является примером какого-то мирового триумфа Go в качестве языка для разработки web-бэкенда, то всё весьма печально с аргументацией, конечно…

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

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

Первое строка мего первого сообщения в этом треде:

• Golang — это язык, на замену C++, написанный для команд инженеров Google.

С превого сообщения повторятся одна и таже мысль: нишевый язык для высокого быстродейтсвия. Нишевый язык для выского быстродействия и экономии ресурсов. Нишевый язык для высокого быстродействия и экономии ресурсов для команды опытных инженеров.

примером какого-то мирового триумфа Go в качестве языка для разработки web-бэкенда,

Про полный отказ кого-либо в пользу исключительно Go

Вы серёздно? Контекст обсуждения не до вас не доходит.

«По этому люди пошли с Ruby на Go массово.» — вы воспринимаете это буквально: удалили Ruby с компьютера и начали переписывать всё, что можно, на Golang.

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

Без метрик выработки (churn) и сложности (complexity) непонятны как тут замешаны ограничения языка, как такового.

Т.е. вам, опытному специалисту с 17 годами стажа, нужны метрики, чтобы доказать, что программа написанная на Ruby потребляет значительно больше ресурсов, чем тот же код переписанный Go. Для вас это не очевидный факт, который не требующий доказательств.

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

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

Вопрос? Зачем с вами общаться?
Ответ: Не знаю. Каждый остается при своем.

kubernetes - это достаточно крупный проект? Или, может, это не достаточно back?

Эту хрень и на баше можно было написать.

То есть то, что конкретно ты решился реализовать это портянками на баше, как-то превращяет это не в крупный проект, или он перестаёт быть бэком?

• Проект крупный? - Крупный?
• Бэк? - Вроде да?
• Написан на go? Да, написан на go (некоторые могут и на баше, но написан на go)

Всё, на вопрос ответили.

Это не то. Там слово type как бы намекает, что оно для type Foo... чтобы писать Foo[int]{}, Foo[string]{} и тп

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

Так этому чудаку из топика и Java медленная.

Причём, что Twitter переезжал в бородатые годы, когда и оптимизаций в Python/Ruby/PHP было гораздо меньше и сервера были гораздо медленнее по всем параметрам (скорость CPU и размер кэшей, объём и пропускная способность RAM и т.п.).

10 лет спустя этот разрыв наоборот сократился и разница с мейнстримными скриптовыми языками стала ощущаться ещё менее остро. и стала в разы меньше.

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

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

У меня сейчас под рукой есть средний проект на Ruby: 4 тысячи классов, 203 тысячи строк кода, несколько сотен эндпойнтов, около 200Гб БД и под десять петабайт данных на S3. У проекта годовой ревеню в прошлом году был 80 миллионов USD, но всё это при не больше 2 тысяч единомоментных пользователей.

Это гибридный монолит, где несколько узких мест вынесено было в микросервисы в том числе и на Go.

Всё это крутится на VPN c 14Гб оперативки, где никогда не бывает занято больше 7Гб. И ещё несколько мелких серверов с 1-2.5Гб для обработки очередей задач.

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

В то же время эти 4 тысячи классов и 203 тысячи строк кода (это бизнес-логика, не включая код самого феймворка и библиотек), без предыдущего метапрограммирования и кодогенерации в лучших традициях Smalltalk, распухнут в несколько раз со всеми этими портянками почти одинаковых гошных функций на каждый чих, обмазанных портянками if err != nil {} и поддержка и развитие этого всего той же самой командой из нескольких человек сильно усложнится, а скорость внесения изменений вырастет кратно.

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

Плюс сейчас ещё модно дёргать LLM, тут тоже Go никаким боком не помогает и не имеет никаких преимуществ.

на [Go] нельзя делать игры, гуишные программы, серверные монолиты

Потому что ты так сказал?

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

Гуишные программы делают на го и особо не жалуются. Недавно в новостях ЛОРа что-то было. Я не сомневаюсь, что в гуишке есть свои проблемы, которые лучше всего решаются уже другими зрелыми языками, но это так, потому что с ними дольше работали напильником. По этой же причине сегодня пишут на Си — потому что это язык индустрии, против индустрии не попрёшь, а не потому что люди не хотели бы что-нибудь лучше. Го — относительно молодой язык, который не успел в своё время занять все ниши.

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

нужны ооп, дженерики

ООП существует в Го. Если вам этого недостаточно, то я сомневаюсь в том, что вам нужно такси, а не шашечки.

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

максимально примитивный язык

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

[язык] с синтаксисом не сложнее баша

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

It is remarkable that in the four most recent editions of the UNIX system programmer's manual the Bourne shell grammar described in the manual page does not admit the command who|wc. This is surely an oversight, but it suggests something darker: nobody really knows what the Bourne shell's grammar is. Even examination of the source code is little help. The parser is implemented by recursive descent, but the routines corresponding to the syntactic categories all have a flag argument that subtly changes their operation depending on the context. Rc's parser is implemented using yacc, so I can say precisely what the grammar is.

https://www.scs.stanford.edu/nyu/04fa/sched/readings/rc.pdf

Кроме того, простой синтаксис — это достоинство. В Го, возможно, самое большое количество существующих применяемых на практике линтеров, новые появляются почти каждый день на замену старым. Я не уверен на 100%, но мне кажется, что это не в последнюю очередь благодаря простому синтаксису.

Сколько для баша существует линтеров, два? Я знаю только про shellcheck и checkbashisms. И это lingua franca администрирования на протяжении более 30 лет.

На нем можно писать, не зная языка

Розовые очки такие розовые.

не решает более глобальных проблем

Даёт пищу для попугаев. Можно кричать всякий бред, а люди принимают за своего. Вполне глобальная проблема.

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

Пониматете, тут такое дело. Что код RubyOnRails практически не подлежит чтению, его можно только разбирать с дебагером

Ага, то-то на конференция по RubyOnRails создают доклады как быстро разобраться в коде RubyOnRais.

Вот тут мне необходимо внести пояснение для читателей, так как смысл не до конца понятен. Речь идет не о коде, написанном с использованием фреймворка RubyOnRails, а о исходном коде самого фреймворка RubyOnRails. Именно исходный код составных частей RubyOnRails, различных библиотек с приставкой Action.

Как высокоуровневый инструмент создания CRUD-приложения за день у Ruby on Rails нет конкурентов. Но если вам требуется читать исходный код самого фреймворка, вот тут начинается буйство синтаксических решений, расширений классов и модулей, замешиваний новых методов, отсутствие контекста вызова методов.

До такой степени, что ctags становится просто бесполезен: некоторые методы и объекты появляются сами по себе, так как во всю работает autoload объектов, а метод может быть определен где-то далеко и впоследствии подмешан. Код не читабелен, его надо пошагово интерпретировать при помощи специальной консоли pry.

Тот вопрос, который в Golang решен коренным образом: четкая структура, малый арсенал синтаксических решений, композиция вместо наследований и замешиваний, и расширений в спонтанном месте кода. Однозначный контекст вызова метода.

Метод в Ruby может вызываться без ЯВНОГО указания контекста: вы просто пишете do_something_good, и эта строчка запускает какой-то метод какого-то объекта, автоматически отслеживая контекст точки вызова. do_something_good может быть определен практически в любой точке проекта.

В Golang такая неоднозначность и загадочность невозможны. Владелец метода строго указывается и обязательно находится где-то в списке указанных пакетов, который ОБЯЗАН быть представлен в верхней части файла с исходным кодом.

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

Clear is better than clever

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

При этом на Ruby писать малые проекты гораздо быстрее. Не требуется указывать и без того понятный автору кода контекст, не требуется определять тип хранимых объектов в структурах данных. Синтаксис богат, лаконичен и выразителен, что является огромным преимуществом на короткой дистанции, но серьезным недостатком на длительной дистанции.

Две строки кода на Ruby могут заменять страницу кода на Golang.

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

Ну я тоже могу писать на C++ не зная языка. Всё-таки опыт, интуиция, stackoverflow и chatgpt имеют вес. Но ведь везде есть тонкости языка. У меня вот знакомый разраб наоборот говорит, что Go нечитаем, а он в университете языки программирования изучал, дипломную писал.

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

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

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

для тех кто пишет на руби - это не проблема

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

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

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

Всё верно, это уже уровень индивидуальной изменчивости Homo sapiens sapiens. Кто-то пишет музыку и формулы (вполне даже приходя вечером с завода), кто-то может только рубить дрова. С этим надо мириться, Go тут, действительно, хорошо помогает, утилизируя когнитивные возможности и последних ребят.

А так как появился язык Golang

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

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

А так как GopherJS до сих пор уже более 10 лет маргинальное поделие, то сам язык как таковой, в вакууме, его синтаксис и парадигмы, без батареек эталонной реализации - даром никому не нужен.

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

Причем тут галера? Это авианосец. Но у них та же проблема «выебщиков» которые учат как проходить собеседования в гугл, прокачивают софт скилы и зазубривают ответы на алгоритмы, а не реальные знания. В итоге получается ситуация что в гугле на одного рокстара сотня-другая середняков. Вот для них и внедряют Go.

Точно также как в Microsоft набирали индусов, но там проблема не так выражена потому что у микрософта изначально есть свой «Go» со всем нужным стеком в виде C#/.Net.

Какая аудитория? Там минимум два концепта slice и прокладки в виде io интерфейсов которые уже недоступны типичным вайтишникам. Про устройство HTTP серверов я уже не упоминаю. Там и близко не RoR/Laravel.

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

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

Каждой задаче свой инструмент, PHP и Ruby не для top tier high load когда сервисом в ДЦ пол континента пользуется. PHP идеален для mid tier, за что и любим обезъяном.

Golang это не язык для новичков.

Go это язык для С/С++ миддлов и синьоров. Так он задумывался, так он и получился. ЧТо не отменяет того что он внедрялся как заменяя С/С++ для С/С++ миддлов и синьоров.

Основная проблема тут это однотредовый application-сервер unicorn и в том, что первый проект писал абсолютный новичок. Тут хоть переписывание на Python или полный рефакторинг с высоты опыта уже бы дало многократный прирост.

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