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

Что вообще происходит с Go и каковы ващи прогнозы на ближайшие пару лет?

Похоже на коррекцию после хайпа. Язык стал скучным, зрелым, стабильным. Однако, количество пользователей вряд ли сократилось под влиянием этого фактора. Скорее наоборот. Прогнозирую медленный и стабильный подъём.

Если TIOBE и PYPL не отражают действительность, то какие другие индексы отражают её лучше?

https://go.dev/blog/survey2025

Однако если сейчас посмотреть на объявления о работе (живу не в России), то там какое-то засилие именно JS/TS, причём в основном это молодые компании и стартапы

Мне кажется, разрабов Go меньше и денег они просят больше. Но ничего, выжившим стартапам придётся переписывать на нормальный язык.

Язык стал скучным, зрелым, стабильным

Это он раньше таким был, лол. Но проблема в том что в зрелый и стабильный проект надо вносить только всякие мелкие фиксы - да к тому же ещё и сложные под капотом, потому что все простое там уже давно сделано.

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

Отсюда и результат.

Причём тут дженерики?

Ну теперь просто если производительности Node.js не хватает, то переписывают на раст, плюс бинарники на раст очень хорошо интегрируются в npm пакеты. Ну и большинство стартапов, это в принципе все на react максимально, и нормальный backend поскольку-постольку. Ну и сейчас с ИИ в принципе трудно продавать стартапы, если они не в хайпе самого ИИ. Да и в принципе и раньше деньги никто так просто не давал, если не считать тех везунчиков с кредитами около 0 процентов.

Производительности V8, на котором основан Node.js обычно вполне хватает. Речь именно о языке программирования. По каким причинам все эти компании выбирают богомерзский JS под Node.js с костылём в виде TS? Кстати, вайбкодинг на Go не менее эффективен, чем на JS/TS.

Шта? Каким боком го конкурирует с JavaScript/TypeScript? Он ближе к расту. Это вообще разные ниши. Низкое потребление памяти, компилируемый, хорошая произовдительность на ресурсоемких задачах. Да как ты вообще умудрился сравнить максимально разные ниши?

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

Эти языки в разных нишах и работают на разных нагрузках. Раст/го нужны там, где ресурсоемкие задачи, где нужно выжать производительность. На них не переписывают, на них делают отдельный модуль в «узком» месте. Для обычной не нагруженной массовой разработки (в основном в вебе) можно большинство задач решить на ts.

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

Посмотри для чего используют js в КДЕ, например. Отличный симбиоз производительного языка компилируемого и скриптового.

Каким боком го конкурирует с JavaScript/TypeScript?

Областью применения на бэкэнде.

Он ближе к расту.

Даже отдалённо Go с Rust не конкурирует. Rust - это язык системного программирования, а Go предназначен для апликативного программирования и микросервисов.

Да как ты вообще умудрился сравнить максимально разные ниши?

У меня к тебе точно такой же вопрос.

Например мне сборщик мусора нахрен не упился - я могу на раст сделать то же гораздо удобнее.

На Расте ты будешь постоянно воевать с borrow checking и тяжёлым синтаксисом. Порог входа в Rust гораздо выше и тебе будет гораздо сложнее найти адекватных разработчиков на нём.

Речь вообще не про веб и не про UI с хоткеями.

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

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

Раст/го нужны там, где ресурсоемкие задачи, где нужно выжать производительность.

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

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

Это как пытаться пихать си во все подряд, отрицая все остальные языки. Ведь можно и на си все написать, но нахрена? Ты же не скажешь, что си не нужен. Всему свое применение.

Ты сам ответил на свой вопрос, backend в стартапах мало кто умеет варить, большинство подделок это react где он и backend и frontend сразу. Под react естественно имеется в виду связка react/next.js, что условно стандарт и дефолт уже. Если, что я не react бой, тут вообще перешел на preact для личных проектов. Но в целом вакансии берутся из требований рынка. А рынок сейчас хочет мидла, по цене дорого джуна и чтобы все делалось через ИИ в основном.

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

В го есть более менее низкоуровневые переменные, более гибкая работа с памятью, когда ts js - максимально упрощенные абстракции обмазанные со всех сторон всяким.

Это как сравнивать крупноблочное строительство с постройкой дома из кирпичей.

Один из конкурентов Go - это JavaScript/TypeScript на платформе node.js.

Разве не иронично: Доступен язык программирования TypeScript 7.0 с компилятором, переписанным на Go?

Ты сам ответил на свой вопрос, backend в стартапах мало кто умеет варить, большинство подделок это react где он и backend и frontend сразу.

Не знаю как у вас, а у нас backend как раз почти все софтовые стартапы делают. Что касается react, то это именно frontend, в крайнем случае fullstack, но всё равно с упором на frontend.

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

У нас немало вакансий для синьоров именно на богомерзский JS/TS. Что касается ИИ, его сейчас оплачивают не за счёт более дешёвых джунов/мидлов, а за счёт общего сокращения программистов в компании. Оправдывают это тем, что если за счёт ИИ производительность (измеряемая в количествах строк кода) выросла, условно раз в десять, сокращение кожаных мешков всё равно оставит компанию в плюсе, то есть увеличение производительности будет не в десять раз, а допустим в семь или даже в пять. По крайней мере такова нынешняя локика эффективных менеджеров и прочих бездельников в руководстве.

То же что и обычно с технологиями происходит. Охлаждение траханья: сейчас все культисты тиобе и «любители свежести» свалят и Go можно будет пользоваться как инструментом :)

Опередил

Я правда хотел ТС написать, когда компилятор ГО напишут на JS, то можно продолжать тему.

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

А что это за файлы у питона на *.o

Отгадайте с 3х раз.

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

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

В го есть более менее низкоуровневые переменные, более гибкая работа с памятью, когда ts js - максимально упрощенные абстракции обмазанные со всех сторон всяким.

Не сильно-то они в Go низкоуровневые. Арифметики с указателями нет. Окажется ли переменная на стеке или в куче решает компилятор. Оптимизация работы с переменными обычно сводится к выравниванию полей в структурах и к учёту размера линий кеша, то есть опять же к выравниванию. Что касается JS/TS, тут я меньше разбираюсь. Но есть один бородатый специалист из ютуба, который проникся спецификацией и в частности выяснил, что var быстрее let и знает ещё много способов помочь V8 оптимизировать машинный код чуть ли не до уровня реалтайма. Хотя я вот прямо сейчас вайбкожу один плагин для VS Code на TS и обе умнейшие модели (Fable 5 Max, GPT 5.6 Ultra) везде пихают именно let.

А что это за файлы у питона на *.o

Объектные файлы, полученные после компиляции кода вовсе не на питоне.

Go перерос модные тренды и уже в производстве на каждый день. Я сходу могу вспомнить:

• syncthing
• prometheus
• terraform
• zrepl

Ну было бы неплохо если как ты говоришь, тогда я бы как раз смог найти работу, если все-таки придется, я наоборот люблю Node.js (ts не очень люблю, ибо все скатывается в any) и чувствую себя как рыба в воде в этой экосистеме. Но вот как ушел с работы, новую искать не хочется. Сам стартапы пилю в одного, и ресурсы и подушка уже горит. Но в целом я думаю, что будут искать только Full-stack мидлов с ИИ шиву с 6-ю роями агентов и желательно за миску риса. И сеньоры в этой ИИ эпохе не нужны. Из того, что вижу на гранты, куда подавался, там даже для Backend разрабов подразумевают, что ты будешь интегрировать в react и ревьювить что «индусы» и «пакестанцы» запилили во фронте через ИИ чтобы все не развалилось к чертям. Вообще думаю будущее за очень мелкими командами и одиночками, типо как сейчас один китаец на алишке продает на весь мир. Я спец по backend как раз, но все что угодно могу в принципе написать. Да я кстати думал как-то на Go уходить, но сейчас реально опять же смысла нет, можно модуль на расте написать и как npm либу упаковать, если где-то нужно что-то более производительное.

Разве не иронично: Доступен язык программирования TypeScript 7.0 с компилятором, переписанным на Go?

Ирония нивелируется сразу после того, как ты узнаёшь, что Go умеет компилировать в WebAssembly, но сам WebAssembly принципиально ограничивает доступ к DOM, к событиям браузера и к прочим вещам, доступ к которым есть исключительно у богомерзского JavaScript. Я бы снял все эти ограничения и позволил бы любому проекту выкинуть JavaScript на помойку даже во фронтэнде. Ибо нефиг тянуть за уши эту легаси херню из 90-х.

У тебя проблема финансирования, а не проблема выбора мидлы vs синьоры. За миску риса тебе будут лишь говнокодить и сваливать. Большая текучесть кадров, плюс недостаточный профессиональный уровень, плюсс AI Slop, плюс дальнейший неминуемый рост цен на токены и подписки обязательно убьют твой стартап. Не подумай, что я тебе всё это желаю, вовсе нет. Но практика уже показала чем всё это заканчивается.

Кстати, раз уж ты затронул ИИ, то самой ИИ программировать на Go достаточно просто, поскольку и сам язык простой.

На нем напили несколько софтин для управления контейнерами. Когда оказалось что авторы не заинтересованы в развитиии языка многие и свалили.

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

наигрались :)
кривую цены, тобежъ заинтересованность покупателей в бетховенах видел ??

Когда оказалось что авторы не заинтересованы в развитиии языка многие и свалили.

Когда конкретно это оказалось?

Подпишусь под каждым словом. Хотел что-то похожее написать. Никогда скриптовый язык не будет конкурентом компилируемому. Это ж надо было додуматься го с js сравнить, особенно с учётом размера node_modules последнего.

Ирония нивелируется сразу после того, как ты узнаёшь, что Go умеет компилировать в WebAssembly

При чём тут это?

У питона нет проблем с производительностью. В нём можно точно также критические участки переписать на что-то компилируемое (где-то даже самому писать не придётся) и летать будет вполне шустро.

У питона то нету? Мы об одном и том же питоне? Жрет как не в себя, зеленый, длинный, выжирает все ресурсы, какие найдет?

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

В таких случаях /dev/hands рекомендуют проверить. Точно сопоставим с js, в отдельных, синтетических тестах даже быстрее. Для веб задач уж точно хватает.

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

Ты видел его устройство? Устройство его переменных? Их размер? Количество абстракций над ними? Ну нельзя быть производительным с такой архитектурой. Ты уж выбирай, удобство или производительность. И то и то нельзя.

Портажи на питоне написаны. И это их почти единственный недостаток. Они люто тормозные. Безумно тормозные. Во всем остальном они прекрасны. И это как раз из за питона.

При том, что это тоже про конкуренцию между Go и JavaScript в определённых проектах.

Посмотри для чего используют js в КДЕ, например. Отличный симбиоз производительного языка компилируемого и скриптового.

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

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

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

Мой ответ надо смотреть в контексте. А там было, что js быстрый, а питон медленный. А это не так - они сопоставимы. Что до производительности, ну, я от руби был не в восторге, например.

Устройство переменных видел, правда давно это было, сейчас не актуально. Если же Вам устройство переменных надо, то это ближе к расту и го. Но это сравнение изначально некорректное ибо понятно, кто победит. Опять же, мой ответ про быстродействие был в контексте веб разработки, потому что там он в основном и применяется (как js).

У питона нет проблем с производительностью. В нём можно точно также критические участки переписать на что-то компилируемое (где-то даже самому писать не придётся) и летать будет вполне шустро.

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

А там было, что js быстрый, а питон медленный. А это не так - они сопоставимы.

В производительности они совершенно разные и несопоставимы.

Серьезно? Вот сейчас не поленился, провел тесты на питоне на разных задачах и node.js на таких же.

fibonacci:        JS ████████████████████████░░░░░░░░░░░░░░░░░░ 10.7x быстрее
json_parse:       JS ██████████████░░░░░░░░░░░░░░░░░░░░░░░░░░ 4.3x быстрее
matrix_multiply:  JS ████████████████████░░░░░░░░░░░░░░░░░░░░ 8.2x быстрее
object_traversal: JS ████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 2.7x быстрее

Js сейчас один из самых быстрых скриптовых языков, если не самый быстрый. Я просто не знаю кто там сейчас быстрее. Раньше был луа быстрее, но он уже вдвое и более обогнал даже луа. Питон же остается одним из самых томознутых. Вон смотри, на одних и тех же задачах питон в 3-11 раз медленее. Это разница практически как между скрпитовыми и компилируемыми языками.

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

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

Чтобы вместо одного недоязычка был целый выводок? С медленной компиляцией и гигантскими бинарями, всё как мы любим. Лучше уж легаси из 90-х.

В таких случаях говорят: код покажи. Как он Фибоначчи считает? Для жсона используй ujson или rjson, вон ещё какой-то orjson советуют. Для матриц numpy. Про обход деревьев не знаю, может и есть чего оптимизированное.

Мне особенно про матрицы понравилось. В курсе, что питон используют для МЛ-ных дел, где матрицы ворочать надо? Что ж они жс не используют, который чуть ли не в 10 раз быстрее? Да тут пахнет революцией!

Вон смотри, на одних и тех же задачах питон в 3-11 раз медленее

На реальных задачах надо тестировать. И выяснится, что эта скорость ни о чём, а всё упирается в БД (и неумение макакичей с ними эффективно работать). На клиенте же вообще event loop, там эти фибоначи тем более пофигу.

Тут еще Go активно использовался в крипте. А сейчас где-то видел, что в крипте стало на 98% меньше вакансий.

Плюс Rust зреет, чаще переписывают проекты на него и выталкивают Go.

БД это вообще отдельная тема. Иногда и чаще всего проще самому на файлах, но муторнее все продумать просто. А вот при чистой работе питон редкостный тормоз. А js один из самых быстрых скриптовых. Он нереально быстр.

Я недавно сравнивал с ассемблером, так тот не сильно то и быстрее, знаешь ли. Точнее не настолько быстрее, как мне раньше казалось.