Что происходит с популярностью Go?

Легковесные исключения для исключительных ситуаций

panic(41) недостаточно легковесно или недостаточно исключительно?

Чем это лучше обычного if err != nil ?

Контролем со стороны компилятора. Особенно в ситуациях, когда возвращается sum type из 3-4-5 вариантов и ошибочный в них только один.

x, err := foo()

err не обработан, ошибка компиляции. Вот и «контроль». Работает в 90% случаев.

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

panic(41) недостаточно легковесно или недостаточно исключительно?

err не обработан, ошибка компиляции. Вот и «контроль».

Вообще-то я перечислял критерии безотносительно конкретного языка программирования. Но вы, как я понял, пытаетесь меня убедить, что Go этим критериям удовлетворяет. Правильно понял?

Но вы, как я понял, пытаетесь меня убедить, что Go этим критериям удовлетворяет. Правильно понял?

Да. Но уже вижу, что вы эту позицию не оспаривали, точно не в том виде, который мне показался.

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

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

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

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

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

Диалектическое единство и борьба противополжностей несёт нам свет, радость и счастье! Ещё можно тов. Мао процитировать.

лисп это вообще не язык, ну точно не человеческий.

Сикрет элиен техноложи же!

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

компьютеры стали мощнее. Теперь если хочется производительность прям до последней капли выжать, то есть Rust

Компьютеры могли бы быть ещё мощнее, если бы в них добавили побольше ядер. Этого не делают, и половина объяснения в том, что программы просто не могут обуздать больший параллелизм. Rust здесь не помощник. На нём возможны мощные параллельные вычисления, но за большую цену. Поэтому Go всё ещё сохраняет здесь свою релевантность, предлагая простую модель совмещённых вычислений (CSP). Будем писать на Go — возможно, нам дадут больше ядер.

При этом самую удачную идею с goroutines из него позаимствовали все кому надо (async/await в JS и Rust, Virtual Threads в Java, Coroutines в Kotlin и C++).

JS лишний в списке: в нём нет M:N бэкенда.

Я думаю, что самая удачная идея Go — это CSP. Без неё мы бы получили стандартный скучный язык. Ни один из перечисленных языков не имеет легкодоступный CSP. А горутины сами по себе — это всего-лишь способ реализации M:N.

Go получается и ни туда, и ни сюда

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

если бы в них добавили побольше ядер
предлагая простую модель совмещённых вычислений

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

Или не приносишь?

Go появился прежде всего потому, что в Google было большое количество обычных людей, для которых даже Java (не говоря уже про C++) была слишкамсложна

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

Скорее всего, речь идёт об этой цитата (мне она очень нравится):

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

Суть цитаты не в том, что молодые выпускники — идиоты. Зачем так плохо думать про автора? Суть в том, что им надо бы к базе данных подключиться, поэтому новый язык не может позволить себе быть слишком экспериментальным. Нет опции защищать концептуальную стойкость а-ля Haskell, когда у людей проблемы с применением.

И здесь нет утверждений «не осилил Джаву» и «Go должен быть легче Джавы». Напротив, знание Джавы ожидается: “probably learned Java.”

Вообще, я лично не помню где они катили бочку против Джавы. В основном, мальчиком для битья был C++. И проблемы были не в концептуальной сложности (не было «студенты не понимают темплейты»), а в том, что обслуживание этого языка проблематично на промышленном уровне 1.

полезную

Я определяю пользу так: 1. Описание длинное, но стоит каждого слова.

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

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

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

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

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

Впрочем, вопрос про панику

А в чем вопрос?

ТС настаивал на позиции о том, что исключения – это зло, поэтому нужно без исключений.

Я всего лишь сказал, что лично мне исключения нужны.

сравнение гарантий компилятора остаются.

О каких гарантиях в Go может идти речь вообще? https://go.dev/play/p/qvaVqEtJEZp

Суть цитаты не в том, что молодые выпускники — идиоты. Зачем так плохо думать про автора?

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

Что, как по мне, полностью соответствует словам Пайка «They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.» Т.е. у них нет способностей/возможностей разобраться с навороченным языком, однако мы хотим, чтобы они (выпускники) таки этот язык использовали, да еще и строили с его помошью хороший софт. Потому мы дали им язык который им было легче и понять, и применять.

И проблемы были не в концептуальной сложности (не было «студенты не понимают темплейты»)

Я не уверен, что в 2007-ом в Google C++ные шаблоны в коде вообще были разрешены.

Кроме того, жизнь показала, что сами авторы Go не особо понимали темплейты. Ибо начать делать в 2007-ом году язык без поддержки обобщенного программирования имея перед глазами опыт Java, C# (а так же D и Eiffel), чтобы затем, спустя 15 лет таки добавить генерики в язык…

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

По-моему поддержка обобщенного программирования и «простой язык с быстрой компиляцией» это взаимоисключающие требования.

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

Кроме того, генерики были добавлены в Java и C#. Стали ли эти языки «предметом надругательств для скучающих александресок»? А Rust, в котором (емнип) обобщенное программирование было сразу в версии 1.0?

PS. Когда Пайк и Ко только размышляли о том, что же они хотят от от своего нового языка, рядом уже был D 1.0, который был и гораздо проще C++, и с шаблонами, и с быстрой компиляцией, и со сборщиком мусора. В котором те же каналы не обязательно было встраивать прямо в язык, а можно было реализовать обычными библиотеками.

Что позволяет мне привести в пример любую программу

Но ты всё равно её не приведёшь.

Восхитительно.

просто если питона не хватает (скорость и т.д.) берут го

ну в гугле старались с помощью go избавиться не только от с++, но и от питона https://github.com/google/grumpy

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

Фреймворки тоже знать не надо. Типичный проект над которым надо работать — легаси с 10+-летней историей, там скорее даже вредно знать что за фреймворк используется, потому что используется он всё равно уникальным для данного проекта способом. Я как-то год или два работал над проектом, пока не понадобилось залезть в код инициализации приложения, и я случайно не узнал что это Flask. Потому что за годы он оброс таким количеством своих собственных решений, что за ними фласка видно не оказалось.

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

Который совершенно неадекватен для микросервисов.

Да вполне можно на нём писать микросервисы.

кровавых разборок с borrow checking

Если писать на Rust как на Go - то есть всё долгоживущее класть в Arc (в языках со сборкой мусора объект был бы ссылкой) и не заморачиваться (а если это долгоживущее надо менять, то класть в Arc Mutex или угореть по иммутабельности и класть Arc в ArcSwap), то борьба с борроу чекером сведена к минимуму. Плюс создавать каналы и гонять объекты между тредами/фичами через каналы. Плюс сейчас можно нейронку попросить «исправь все ошибки компиляции» и уйти пить кофе, пока с борроу чекером борется она (frontier модели уже весьма хорошо умеют исправлять ошибки заимствования).

А вообще проблемы с борроу чекером возникают в первую очередь при попытках писать на Rust как на C++.

Хватит тащить в язык программирования очередную порцию новомодного сахара и прочей фигни.

В Go нет банальных enum (в смысле типизированных, а не просто констант), которые существовали задолго до появления Go. Иронично, что newtype (более новая концепция для массовых языков, чем enum) при этом в Go есть. Плюс надо постоянно писать if err != nil (проблема, возникшая из-за отказа от исключений, поэтому не имеющая аналогов в языках с исключениями), когда в том же Rust (который тоже пошёл по пути отказа от исключений) есть элегантный оператор вопроса. Это достаточно базовые вещи.

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

Когда Пайк и Ко только размышляли о том, что же они хотят от от своего нового языка, рядом уже был D 1.0

вообще, создатели языков несправедливо обходят вниманием dlang, особенно показателен пример в пункте «why build carbon?» https://github.com/carbon-language/carbon-lang

на дишном форуме недоумевают, что пошло не так, почему выбирают go https://forum.dlang.org/thread/mdtago%24em9%241@digitalmars.com

на дишном форуме недоумевают, что пошло не так,

Меньше нужно было свой язык ператрахывать (с). Сперва сам Вальтер Брайт никак не мог успокоится и вносил ломающие изменения чуть ли не в каждый релиз. А затем пришел Александреску и было заявлено, что D1 – это тупиковый путь, что дальше, когда-то в светлом будущем, появится D2.

Оно-то, конечно, D2 вышел лучше, чем D1. Но вот многие сочувствующие (включая меня) прикола не поняли, не захотели ждать D2 и перестали смотреть в сторону D.

Бэк ozon.ru написан на Go. Уверен, что это очень полезный сервис для миллионов людей.

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

Это не то что бы неверно, но очень ограниченно. Ограниченно несколькими потомками Алгола, если за флажки не заходить, то да, между C и Pascal, между Java и C# разницы особо нету. Но если адепт такого подхода увидит, вдруг, случайно transducer, у него отвалится жопа.

Фреймворки тоже знать не надо.

Ясно-понятно. А чего надо-то?

Да вполне можно на нём писать микросервисы.

Да и на С можно писать. Но зачем? Т.е. какие выгоды я получаю от использоания Rust для микросервисов?

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

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

не имеющая аналогов в языках с исключениями

А в ваших языках с исключениями нету перезапусков. Сильно вы страдаете от их отсутствия? Вот, так же и с исключениями в Go. Просто нужно принять, что у Go есть определённый подход и не пытаться гладить его против шерсти.

По сути хорошие идеи Go

Главной «хорошей идеей Go» является комбинация языка, экосистемы и культуры разработки, при которой можно вкатиться в любой, даже большой и старый проект без фрустрации и тягостного недоумения: «зачем вы, гады, всё это на**вертили?!». Я даже в своём собственном коде легко ориентируюсь. А это, определённо, знак качества.

Можно мне замену helm на расте (раз уж в этом дурном обсуждении опять эти весьма различные языки противопоставляют)? Спасибо.

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

Теперь понятно.

1. Монга. Там обмен жсоно-подобными сообщениями идёт. Видимо, клиент не справляется с парсингом. Там должны быть вставки на С, но не обязанны, как говорится. Есть библиотека smongo. Возможно, она пободрее работать будет.
2. grpc. тут нечего сказать. Сам клиент написан на плюсах - должен работать быстро. альтернатив нету. Так что если не хватает, то увы.
3. Клауд. Я подумал, если они заточены под одно приложение в один процесс, да ещё и холодный старт, то тут питон скорее всего мимо. Его относительная тормознутость контрится большим количеством воркеров, если мы говорим о классическом веб-сервере.

Можно мне

1. Нет, нельзя.
2. helm - это анекдот.

если бы в них добавили побольше ядер
предлагая простую модель совмещённых вычислений

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

Бэк ozon.ru

То есть и с третьей попытки не смог назвать ни одной программы?

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

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

Ну, на нет и суда нет. Как появится — пишите.

Ты, главное, жди.

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

Эту?

1 CPU

3 CPU Server

, но по итогу натурально в 20 раз медленнее гоши

Что?

А долго ждать как на расте что-то полезное напишут?

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

Что? Мы говорили о том, что питоновский клиент написан на плюсах преимущественно. Но всё равно тормозной.

В go сборщик мусора. Он раза в два медленнее языков без него. Rust просто говно.

Только С , ничего лишнего

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

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

Вэбщики не настоящие программисты и ничего не понимают.

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

апликативного программирования

Это как?

зачем вы, гады, всё это на**вертили?!

Вот, интересное наблюдение, я плохо въезжаю в большие объёма кода на Python сгенерированные нейронкой (в закрытом цикле, где нейронка пишет код, ревьит его и т. д., а человек только даёт ТЗ). А вот в большие объёмы кода на Rust сгенерированные нейронкой въезжаю нормально. Это, конечно, субъективно, но то ли Rust понятнее за счёт мощной типизации, то ли нейронки на нём чище пишут.

А в ваших языках с исключениями нету перезапусков. Сильно вы страдаете от их отсутствия? Вот, так же и с исключениями в Go. Просто нужно принять, что у Go есть определённый подход и не пытаться гладить его против шерсти.

Надо смотреть на языки, которые были популярны на момент появления Go. Там везде были исключения. Go забрал исключения, но не предложил удобный синтаксис для обработки ошибок в Go-style. Этот подход потом до ума довёл Rust (который тоже решил, что исключения не нужны) введя оператор вопроса.

Да и на С можно писать. Но зачем? Т.е. какие выгоды я получаю от использоания Rust для микросервисов?

Для Rust есть веб-фреймворки (самый популярный Axum, с 26к звёзд, 1.4к форков и 400+ контрибьюторов на GitHub) с батарейками. На C популярных веб фреймворков нет, будешь либо изобретать велосипед, либо использовать чей-то велосипед с сообществом из 3.5 анонимусов. Сам факт, что под Rust есть популярные веб-фреймворки показатель, что микросервисы на нём таки пишут. Меньше, чем на некоторых других языках (но Rust и моложе многих из них), но пишут и это уже не является чем-то маргинальным.

Ещё на Rust можно более-менее безопасно перекладывать JSON'ы. unsafe нужен в биндингах к нативным либам, каким-то сверхоптимизациям и т. п. В сервисе ты можешь обмазаться Arc и готовыми либами типа axum и sqlx. И в целом без особого напряга твой сервис не будет содержать фатальных ошибок типа переполнений буфера и т. п. На C накосячить гораздо проще и как-то не так сравнить строку, забыть освободить память и т. п.

На самом деле Rust в некотором смысле даже безопаснее Go, потому что в Go есть NPE (и его очень легко вызвать даже в идеоматическом коде), а в Rust нет (есть паникующий unwrap, но это явный opt-in в падению в случае отсутствия значения). При этом тот же Axum умеет ловить панику и ронять один обработчик вместо всего приложения (в отличии от NPE Go, который по сути SegFault убивающий весь процесс).

А долго ждать как на расте что-то полезное напишут?

А долго ждать, когда до тебя дойдёт, о чём разговор?

Это уже передёргивание. Чё там у вэбщиков? jQuery, переусложнённые фреймворки, там скруглил. Тут цвет у ссылок поменял, лендинги, каталог свадебных платьев, воронка продаж, каталог обуви, сайтик стоматолога, Wordpress, Joomla… тяп–ляп. Главное чтоб было красивенько. Программирование называется. Когда я в Word делаю красивенькие документы с несколькими строками VBScript я же не называю себя frontend engineer. На стороне сервера SELECT ALL FROM можно на чём угодно писать. Лично я продпочитаю Delphi.

Мы про питонячий клиент говорили. Он тоже «типа на плюсах» но по факту там чёт около 2.5к рпс на этом тесте

У питона нет проблем с производительностью
критические участки переписать на что-то компилируемое

Противоречия нету. Совсем.