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

Вообще-то я о Еве.

Кто из крупных работодателей помимо Гугла его использовал?

Например Palo Alto.

Микросервисы же. Одна команда на игогошечке пишет, а другую стряхнули с фронта. Так вышло.

Кто в здравом уме будет городить такой зоопарк?

Комбинация ts/rust выглядит как мечта извращенца типолюба.

Наверняка причины те же, что и в комбинации питон/раст. Правда прирость в производительности поменьше.

большую помойку ещё поискать

Неужели NPM чище?

С учётом того, что для решения проблем с JS wtf пришлось создать TS и Dart, которые ещё и «взлетели», я бы не был так категоричен.

Например Palo Alto.

Из свежих новостей ­— руководитель назвал состояние «дарвиновским моментом», сказал, что 90% работников не знакомы с ИИ, поэтому кандидаты на увольнение.

Кто в здравом уме будет городить такой зоопарк?

Жизнь! Вашу компанию купила компания побольше. У вас всё на Go. У них все новые проекты на TS (и легаси-монолит на Яве, который все боятся и презирают, но он единственный приносит прибыль и держит вашу ораву дармоедов на плаву). И что вы предлагаете делать? Собрать совет синьоров, выбрать один язык и переписать всё на него? У вас зоопарк и вы теперь в нём живёте.

Ну вот не гони. У нас как раз вебняк. Работа с сетью и базами в питоне невероятно тормозная, что в тредах, что в asyncio. А gil делает жизнь только веселее

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

для решения проблем с JS wtf пришлось создать TS и Dart

Так и для питона с его wtf (  1    2    3   ) пришлось создавать nim  и mojo

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

Ох, зря в питон всяких .... моржовых потащили. А вот по работе интерпретатора хорошо!

А что имеется ввиду под «знаком с ИИ»?

• дал доступ агенту на всё, грохнул прод, просрал 90% бюджета токенов
• поговорил с чатом за жизнь
• собрал ферму видях, обучил модель

??????????????

Экосистема голанга это убогий go.mod и makefile, и зависимости с гитхаба? Не, спасибо, уж лучше мавен

Maven ещё более убог. Например он не позволяет вмешиваться в разрешение версий транзитивных зависимостей и его собственный алгоритма этого довольно примитивный. Кстати, именно поэтому в Gradle он другой. А в простом как портянка go.mod всё просто и понятно. Ну а Makefile вообще не из экосистемы Go. Его там используют как вспомогательный механизм, да и то далеко не все проекты.

Когда появился Go, он был ответом на то, что тогда по сути на рынке энтерпрайза был выбор между Java (тормозит, жрёт кучу памяти, состоит из фабрик фабрик фабрик) и C++ (выстрел в ногу каждую секунду, никто не знает до конца полный список UB). Может ещё Python, но он просто ОЧЕНЬ медленный. А тут выкатили язык со скоростью близкой к нативу, но при этом без UB и отстрела ног. А ещё с прорывной на то время идее с goroutines (в то время доминировал синхронный подход, где каждый запрос обрабатывает отдельный тред).

С тех пор появилось/развилось много других языков, а ещё компьютеры стали мощнее. Теперь если хочется производительность прям до последней капли выжать, то есть Rust (высокий порог входа компенсируется тем, что те кто на нём пишут реально любят на нём писать, в отличии от C++, который просто терпят ради производительности). А если устраивает средняя производительность, то есть Node с низким порогом входа и достаточно хорошей производительностью (V8 является эталоном производительности среди интерпретируемых языков).

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

Посмотри официальные презентации Go, его буквально противопоставляли C/C++ («теперь вы можете писать также производительно, но без отстрела ног», там буквально приводили примеры на двух языках и показывали, что Go удобнее) + рассказывали про инновационное управление задачами. В годы выхода Go это были реально уникальными преимуществами. В 2026 уже нет.

А что имеется ввиду под «знаком с ИИ»?

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

поговорил с чатом за жизнь

Может кто присоветует skill.md «Собутыльник»? Друг интересуется :D

P.S. На популярность Go плохо влияет постоянное if(error != nil) {...}

Из свежих новостей ­— руководитель назвал состояние «дарвиновским моментом», сказал, что 90% работников не знакомы с ИИ, поэтому кандидаты на увольнение.

Не знаю откуда ты это принёс, но основная причина увольнения «из-за ИИ» к навыкам работы с ним не имеет никакого отношения. Людей увольняют ради изыскания бабла на токены. А токены Palo Alto жреёт нещадно, включая и сам процесс найма. Мне кажется, большой бизнес должен переболеть ИИшкой, столкнуться с ещё большими расходами на токены и с лопанием всего ИИ пузыря. Будущее за локальными моделями. Дата центры - это тупиковый путь развития динозавров, которые вымерли.

На популярность Go плохо влияет постоянное if(error != nil) {...}

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

Я бы посмотрел, что вы сделали с питоном, если единственная его задача - дождаться ответа БД.

Угу. И они настолько популярны, что про них никто не слышал.

Ты бы синтаксис подучил, прежде чем осуждать.

И что сейчас в Go вместо if(error != nil) принято использовать?

Когда появился Go, он был ответом на то, что тогда по сути на рынке энтерпрайза был выбор между Java (тормозит, жрёт кучу памяти, состоит из фабрик фабрик фабрик) и C++ (выстрел в ногу каждую секунду, никто не знает до конца полный список UB). Может ещё Python, но он просто ОЧЕНЬ медленный. А тут выкатили язык со скоростью близкой к нативу, но при этом без UB и отстрела ног. А ещё с прорывной на то время идее с goroutines (в то время доминировал синхронный подход, где каждый запрос обрабатывает отдельный тред).

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

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

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

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

Ты тут наговорил массу чего-то сумбурного. В Go нет никакого отстрела ног, ни в виде типичных проблем с C/C++, ни в виде кровавых разборок с borrow checking, ни в виде борьбы с монструозными фреймворками вроде Spring Boot с его мерзской декларативщиной и прочей магией в стиле Борисова и Садогурского. async/await в JS - это даже близко не конкурент goroutins. JS принципиально однопоточен, в то время как Go использует модель M:N - гораздо более адекватную для бэкэнда, нежели этот богомерзский JS с ивентами. Что касается Java, она просто скатывается в УГ постоянно нахватывая очередной модно-молодёжной фигни. Фактически уже с Java 5, когда туда принесли анотации и обработчики анотаций Java начала отходить от своих изначальных принципов простого и предсказуемого языка. Современная Java - это какой-то жуткий салат. Взять к примеру абсолютно никому не нужные модули.

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

О какой невыразительности речь? По-хорошему язык программирования не должен «развиваться» и попсеть. Он должен быть как набор математических операций. Почему математики не изобретают новый язык математики каждые 10 лет? Потому что они заняты решением задач, а не митапами в стиле Жени и Баруха с группой поддержки из JetBrains (откуда Женю почему-то выгнали). Хватит тащить в язык программирования очередную порцию новомодного сахара и прочей фигни. Дайте программистам просто решать задачи. Именно этим и хорош Go.

Посмотри официальные презентации Go, его буквально противопоставляли C/C++

Примерно так же начиналась и Java. Но той простой Java давно нет.

Я не про обработку ошибок. В Go не нужно писать скобки после if. Переменную ошибки обычно называют короче - err. Так же есть возможность аккумулировать ошибки в одну (если не было ни одной, так же получишь nil).

Не знаю откуда ты это принёс

Первые 5 новостей в Гугле по запросу “Palo Alto Networks” :) Даты — 2-3 недели назад.

но основная причина увольнения «из-за ИИ» к навыкам работы с ним не имеет никакого отношения. Людей увольняют ради изыскания бабла на токены.

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

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

Будем надеяться.

Я не про обработку ошибок.

Тогда как автор первоначального комментария (да и я тоже) как раз про обработку ошибок.

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

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

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

как раз про обработку ошибок

Тебе больше нравятся исключения? Они устарели и в современные языки программирования их не берут.

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

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

Не верь презентациям, Go изначально гораздо древнее: https://www.youtube.com/watch?v=ql-uncsqoAU

Google просто взял это вмести с исходными разработчиками из Bell Labs и назвал первыми двумя буквами себя любимых.

Наверно, нет. GigaChat, например, ЗОЖ проповедует и рассказывает.

Тебе больше нравятся исключения?

Легковесные исключения для исключительных ситуаций (но ни в коем случае не checked exceptions), sum types и pattern matching для обычных ошибочных результатов (но не уверен на счет синтаксического сахара в виде ? из Rust или обязательного try из Swift).

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

Сейчас в программировании огромное количество «малолетних дебилов», которые даже Go или Java толком освоить не могут, поэтому да, от слишком больших и сложных «пушек» приходится держать подальше :(

Ну, я в питоне люблю ещё multiprocessing.pool.ThreadPool для скрапинга сделать.

Не верь презентациям

Т.е. мне не верить рассказам Пайка и Томпсона?

То, что ноги у Go растут из Limbo они сами и не скрывали.

PS. Видео не смотрел и не буду.

которые даже Go или Java толком освоить не могут

Java толком

- а вот если я уже устаревшую 1.4 с бешеным бойлерплейтом (когда hello world через определение класса, создание такого класса, потом создание его инстанса и вызов метода из инстанса, потом деструктор) так и не освоил (вернее, пожевал и выплюнул с отвращением) - вот то, что я не освоил - это в современной джаве толком или уже не нужно?

Почему вы говорите «большой и сложный» так, будто в этом есть что-то хорошее?

какая альтернатива лучше?

Да практически любая, даже, прости господи шарповая.

Что не так с дженериками

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

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

Почему вы говорите «большой и сложный» так, будто в этом есть что-то хорошее?

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

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

В Go не нужно писать скобки после if.

Уж простите старого плюсиста - привычка :)

Мое имхо иногда удобнее бросить исключение чем прокидывать ошибку наверх через 100500 вызовов функций. Также вот CPS интересен :)

вот то, что я не освоил - это в современной джаве толком или уже не нужно?

ХЗ, я к Java уже лет 15 не притрагивался.

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

Конкретнее, что ты имеешь в виду? Что-то типа RuntimeException в джаве? Что их делает тегковесными? И ты наверное удивишься, но в Go можно бросать и ловить панику.

sum types

Разве Go это запрещает?

pattern matching для обычных ошибочных результатов

match value {
    Ok(x) => println!("{x}"),
    Err(e) => println!("{e}"),
}

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

Сейчас в программировании огромное количество «малолетних дебилов», которые даже Go или Java толком освоить не могут, поэтому да, от слишком больших и сложных «пушек» приходится держать подальше :(

Ты просто никогда не работал в проектах с умниками, наваявшими пятиуровневую систему абстракций. На сколько я знаю в корпоративных правилах многих корпораций количество этих уровней строго ограничивают. И таки композиция лучше наследования, вне зависимости от интеллектуального уровня программиста. Ну а исключения - это зло. Кто-то бросил, кто-то словил. Обработчик сразу на несколько источников этих исключений. Спагетти код без goto, кушайте не подавитесь.

1. Было бы это так, всеб выкинули давно Java и C++, бо у лиспа и исключения, и объектная система богаче по своим возможностям. Этого, однако, не происходит.

2. Ещё не придумали способа пробрасывать исключения между микросервисами.

3. Почему бы не оставить большие и сложные инструменты большим и сложным задачам? Я даже не буду касаться вопроса «является ли задача сложной сама по себе или стала сложной, после того как её стали решать на Java». Просто очень значительный кусок индустрии состоит из простых задач. Вот, для них и нужен простой инструмент.

Видео не смотрел и не буду

Тогда зачем говоришь?

Уж простите старого плюсиста - привычка :)

Как if (7 == n)? Я эти ваши привычки ещё с джавы встречал.

Мое имхо иногда удобнее бросить исключение чем прокидывать ошибку наверх через 100500 вызовов функций. Также вот CPS интересен :)

Можно бросить панику и перехватить в другом месте.

Go предназначен для апликативного программирования и микросервисов.

не только

Go is a high-level, general-purpose programming language that is statically typed and compiled. https://en.wikipedia.org/wiki/Go_(programming_language)

примерный список проектов https://github.com/avelino/awesome-go

Конкретнее, что ты имеешь в виду?

Когда исключение – это не класс, который от чего-то наследуется и предоставляет какие-то виртуальные методы для того, чтобы извлечь из экземпляра исключения описание, стек-трейс или еще какую-то лабуду. А какой-то простой объект, вроде std::error_code из C++.

Что-то типа RuntimeException в джаве?

Нет.

И ты наверное удивишься, но в Go можно бросать и ловить панику.

Нет, не удивлюсь. Основы Go я изучил еще 15 лет назад.

Разве Go это запрещает?

А поощряет? Является ли это обыденной практикой? Вот в Rust используется Result и это, как по мне, не просто OK, а сильно лучше Go-шных err-ов.

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

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

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

Я сам из этих умников.

Ну а исключения - это зло.

Аминь.

Тогда зачем говоришь?

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

Для hello world в Java никогда не нужно было создавать инстанс. Функция main статична и работает не через инстанс, а прямо через класс. А современная Java совсем опопсела:

$ cat test.java 
void main() {
	System.out.println("Hello world");
}
$ java test.java
Hello world

А тут выкатили язык со скоростью близкой к нативу, но при этом без UB и отстрела ног.

к тому времени уже был dlang

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

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

высокий порог входа

поэтому с вакансиями будет всегда туго

презентации Go, его буквально противопоставляли C/C++

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

Было бы это так, всеб выкинули давно Java и C++, бо у лиспа и исключения, и объектная система богаче по своим возможностям. Этого, однако, не происходит.

Это ваше личное заблуждение. Lisp не был всепоглащающим мейнстримом даже в 1970-е и 1980-е, не говоря уже про последующие годы.

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

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

Почему бы не оставить большие и сложные инструменты большим и сложным задачам?

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

Спасибо, такая попса мне по нраву!