Комментарии 99
Я бы сказал, c# необоснованно упал в рейтинге в прошлом году.
Но это теоретически. В России возможны другие расклады.
Самым большим проигравшим стал Go, который упал сразу на 16-е место.
Ну, а что вы хотите? Это как сорняк, быстро заполнивший пустошь после пожара, но оставивший множество специфических проблем. Теперь пора переходить на что-то более серьёзное.
У тиоби на сайте не работают графики. Если у кого-то видны - перезалейте сюда.
Однако лично наблюдаю как и на российском рынке, и на зарубежных рынках идет активная миграция на Go. Не только с PHP, Python и Ruby, а еще и с Java и C# в том числе. В общем-то не вижу ни одной причины начинать новый бекенд проект не на Go, а на каком-то другом языке, когда Go специально для бекендов и сделали.
Однако лично наблюдаю как и на российском рынке, и на зарубежных рынках идет активная миграция на Go. Не только с PHP, Python и Ruby, а еще и с Java и C# в том числе. В общем-то не вижу ни одной причины начинать новый бекенд проект не на Go, а на каком-то другом языке, когда Go специально для бекендов и сделали.
Бек разный бывает. Как только богатая доменная модель так го всё
Go хорош для:
- API gateway / прокси
- инфраструктурные сервисы
- высоконагруженный stateless
Плох для:
- сложный домен (DDD)
- много бизнес-правил
- глубокие иерархии сущностей
Миграция с Java/C# на Go для CRUD-микросервисов - ок. Для чего-то с реальной логикой - мазохизм.
Тот кто говорит "не вижу причин не на Go" либо делает простые сервисы, либо ещё не обжёгся на сложном домене.
Да почему, лично участвовал в процессе миграции Java финтех-монолита со сложной бизнес-логикой на несколько Go-сервисов. И DDD, и бизнес-правила, и сущности сложные - все это было. И ничего, нормально за пару лет мигрировали. Поверьте, в крупных российских маркетплейсах вроде Ozon и WB бизнес-логика наверняка еще более сложная чем у нас, и тем не менее они уже годами живут преимущественно на Go и развивают свои сервисы, вон даже банк на Go запилили.
Можно и ddd на го с монолитами - отчего ж нет. Были бы бюджеты, чтобы это все поддерживать. На мой взгляд это не тот инструмент, чтобы можно было как джавах или шарпах ооп подход реализовывать - обычно костыль на костыле выходит. По моему опыту и поддержка потом болезненная или дорогая выходит.
Насколько видно с моей башни в маркетплейсах сейчас гошников увольняют, а набирают шарпистов
Увольте архитектора
>Go специально для бекендов и сделали
то есть это всего-лишь какой-то DSL, как PHP?)0)
А DSL это что-то из прошлого века, когда любили запереть себя в одном направлении и там же тухнуть. Кстати, у go и синтаксис прошловековой - кто будет в здравом уме писать fun
Этот рейтинг на столько оторван от реальности, что даже язык реального первого места у них не в первой пятерке.
Насколько я помню, этот рейтинг основан на том, как часто в поисковой выдаче упоминается тот или иной язык программирования. В эпоху LLM этот рейтинг вероятнее всего станет еще более оторванным от реальности чем ранее, потому что все стали использовать ту или иную LLM вместо Гугла, а сайты с туториалами по программированию для новичков кажется совсем отжили свое. Если уж и смотреть на рейтинги, то лучше на JetBrains Developer Ecosystem или GitHub Octoverse.
более-менее адекватным выглядит https://redmonk.com/sogrady/2025/06/18/language-rankings-1-25/
Так, подождите, ну а как же, что в России шарпы неактуальны и никакой новый проект не пишется на шарпах: только на го, питонах и джаве 11 ?
MS как-то некрасиво ушла. Как и SAP и многое другое. Бизнес и госы обиделись / пересмотрели риски.
только на го, питонах и джаве 11
Rust тоже для энтерпрайза годится.
C# в принципе может жить уже и без Micrisoft
Может и без, но ms влияет достаточно сильно. Бэк на .net - это уже сформированный зрелый кейс, который вобрал вообще в себя лучшие практики и скорость реализации проекта заметно возрасла (и дело не в ef core) - альтернатив с таким сочетанием: производительность, богатый набор фич, которые реально помогают писать быстро и безопасно, - на рынке практически нет.
А вот мобильная и десктоп кросплатформа с maui пошла куда-то не туда. Хочется на все это махнуть и либо авалонию (если десктоп) брать, либо нативку на свифте, если ios - ну не тянут, столько лет, а все на одном месте топчутся.
Полагаю, что 90% финансирования разработки .net core идёт от MS. Пока Azure живёт...
авалонию (если десктоп)
А почему авалонию — только на десктоп? Авалония вроде как покрывает все виды фронта — от веба (через WASM), до обеих мобильных платформ.
Ну и собственно авалония — как раз таки показатель того, что c#/.net может и без MS обойтись в случае чего.
веб копал в авалонии полгода назад, - это еще не прод. те же самые js интеропы работают непредсказуемо, может что-то уже и пофиксилось. Мобильные платформы в авалонии скорее всего - да, чуть поживее, чем веб, но тоже есть нюансы. Андроид не копал, а вот ios - мало компонентов, много нужно писать нативки, ну и прохождение модерации в эпп стор - надо постараться.
Ради справедливости надо отметить, хочешь хороший desktop на маке или бодрое ios приложение: вооружаешься 6ым swift, concurrency, комбайном с их mvvm, докой эппла по ui - и получится. Остальное, имею ввиду другие кроссплатформенные решения (не только авалония), в большинстве коммерческих случаев, - полумеры.
Вряд ли. Кроме MS в дотнет никто денег не вкладывает. Для постоянного развития языка и CLR нужна команда разработчиков на зарплате. И если условную Java еще пытаются как-то допиливать в недрах Amazon или RedHat, то .NET целиком и полностью существует за счет MS.
https://dotnetfoundation.org/membership/corporate-sponsorship
Также не забываем что .NET с открытым исходным кодом, и любой желающий может помочь в разработке.
Так то, что от не от MS, тоже ушло из России, Rider например. В какой лицензионно чистой IDE например разрабатывать? VSCode? Так там тоже расширение для C# от MS и требует лицензии на VS большую.
Пакетный менеджер чей? MS? А если они завтра заблочат неугодную им страну?
При этом, я бы не сказал, что разработка на C# вообще прекратилась, но на условные госы, озадаченные сверху политическими соображениями, это достаточно сильно влияет.
Так там тоже расширение для C# от MS и требует лицензии на VS большую.
Не требует. Точнее, если покопаться в лицензии, то "можно до 5 одновременных пользователей", но это никто не проверяет. Впрочем, если ваша организация топит за лицензионную чистоту даже для софта от недружественных стран, это может быть проблемой.
Пакетный менеджер чей? MS?
Тоже самое про любой пакетный менеджер можно сказать. Питон, Го, раст и т.д. Всё это решается поднятием локального зеркала, а большинство пакетов, размещенных в NuGet, имеют исходный код на гитхабе, который можно скачать, скомпилировать и положить в собственный репозиторий.
Рантайм и сдк точно так же имеют исходники на гитхабе и при необходимости можно из этих исходников собрать.
Так я и говорю, что это больше вопрос для крупных бюрократических или около-гос контор. Вроде и можно решить, но есть внутренние нормативы (пришедшие понятно откуда извне), что софт не только лицензионно чистым должен быть, но и по возможности от российской компании, даже если она тупо сборкой занимается. Например у Java есть вариант сборки от российской компании, платный и дорогой само собой, хотя по сравнению с OpenJDK там ничего нового. Но таких компаний у нас немало, историческая особенность экономики.
nvim ещё можно освоить
Российский бигтех сейчас на Go переезжает массово. Java 11 - это нечто весьма старое. А питон - это язык для всех задач и на все времена.
Уже даже самые замшелые галеры на 17 переши
Я тут Go попробовал на праздниках (основной мой язык - это C# как раз). Давно уже хотел.
Сначала я решил написать простейший калькулятор, как в универе на паскале.
Началось все с того, что после билда консольного приложения, касперский мне выдал что в exe-шнике троян.
Далее у меня начал ломаться аналог Console.ReadLine, там внутри какие-то сайд эффекты, если ввести "абврылг" вместо 4.5. Я спросил чат гпт, что с этим делать и он предложил вариант, где я должен руками написать что-то вроде чтения из потока из stdin/out. Че серьезно?
Потом я решил закодить rest api.
Оказалось, что Microsoft как разработчик языка C# поддерживает и развивает довольно качественные и функциональные фреймворки, чем пожалуй задает некий стандарт наличия таких вещей в экосистеме - asp.net core для rest api, ADO.NET / EF / EF Core для доступа к данным и так далее.
В случае с Go - Google ничего такого не делает. Я там нашел пару фреймворков на гит хабе (gin-goinc и какой-то от Uber). Но создалось ощущение, что это какие-то собранные на коленке штуковины. И только с тем функционалом, который понадобился условном опен-сорусеру или тому же уберу. А все остальное будь добр пили руками сами.
Не, в экосистеме C# тоже есть nuget и сто тыщ питцот миллионов собранных на коленке библиотек различного качества. Но не глобальные же вещи типа rest api и orm?
Идем дальше - ООП в Go по сути нет, есть структуры, интерфейсы (без привязке к структуре), процедурщина в виде конструкторов / методов чуть ли не в глобальной области видимости (package aka namespace помогает чуть-чуть). Это если бы я на C# все писал с использованием extension methods.
DI / IoC тоже нет. В связи с этим я теперь начал угорать с вакансий на Go
Требования:
• Уверенно владеете git, docker, docker-compose
• Есть опыт работы с HTTP API, GRPC
• Понимаете Go-специфичные концепции: горутины, каналы, интерфейсы
• Есть опыт работы с PostgreSQL
• Понимаете ООП, паттерны, микросервисную архитектуру, SOLID, DRY
Как я теперь это читаю: http api какое-то обрезанное и собранное на коленке, ООП обрезанное, зачем его требовать? SOLID? как вы это сделаете без ООП и DI / IoC в том числе?
Насчет горутин и каналов - это короче аналог Task.Run + Channels в C#. Чат гпт можно попросить написать один и тот же код на Go и на C# и увидеть схожесть и разницу. Каналы я в C# не использовал. Это по сути очередь в памяти и она теряет данные при перезагрузке сервера.
И тут я вспомнил, как мой самый первый начальник на самой первой работе сказал, еще в 2007 году, что C# это очень абстрактный язык. Вот, он был прав.
На C# можно просто писать код, без сайд эффектов внутри. Вот как ты думаешь - так и пишешь. Что ты ждешь от него, то он тебе и выдает. Есть "промышленные" фреймворки, поддерживаемые самой корпорацией, кто изобрел язык. Microsoft и C# короче разбаловали меня.
Go - какое-то недоразумение, понавставлял кучу палок в колеса, и это я еще не пробовал писать ничего сложнее калькулятора. Хорошо что дженерики есть
Microsoft как разработчик языка C# поддерживает и развивает довольно качественные и функциональные фреймворки, чем пожалуй задает некий стандарт наличия таких вещей в экосистеме
Сейчас да. Код от MS и платные либы очень хороши. Бесплатные тоже лучше, они мечтают стать платными.
А вот рыться в легаси net framework приложений, которые нельзя обновить до .net core удовольствие то ещё. WCF, который гадит во всех слоях, так что домен теперь зависит от структуры БД... Надеюсь, больше такого не повторится
Насчет горутин и каналов - это короче аналог Task.Run + Channels в C#
Да. Но нет проблемы красно синих функций. И отладка легче: в Шарп отладка асинхроннонных функций создадёт определенные проблемы.
Про вакансию смешно, да
По сути вакансия говорит: "нам нужен человек который будет писать на Go но думать как на нормальном языке". "Кто будет отгребать всё говно от десятка сусликов-джунов". Типичный enterprise Go.
Как только обязанности больше чем у суслика требования на го программиста резко растут. Имеет смысл только если таких людей надо мало в % от всей команды
Go хорош когда:
- много простых сервисов
- высокая текучка/джуны
- нужна одинаковость кода
Но архитектор, техлид, тот кто проектирует границы сервисов - ему Go-мышление мешает. Поэтому парадокс: чем сложнее роль, тем меньше смысла в Go как в основном инструменте.
Сеньоры на Go часто переплачены за страдания или это люди с бэкграундом из "нормальных" языков которые вынуждены пасти стадо пишущих код на Go.
Отладка асинхронного апи уже много лет как хорошо себя ведёт. Первые годы после появления были сложности, но это уже лет 10 как назад было.
ему Go-мышление мешает
А в чем заключается это "Go-мышление" и как оно мешает сервисы проектировать?
Go-мышление это:
- всё плоско, пакеты вместо иерархий
- данные отдельно, функции отдельно (struct + методы ≠ полноценный ООП)
- ошибки как значения везде, нет исключений
- если сложно выразить - значит неправильно думаешь, упрости
Мешает тем что:
При проектировании границ сервисов думаешь в терминах домена, агрегатов, инвариантов. Go подталкивает к "а давай просто данные гонять". В итоге логика размазывается по сервисам вместо того чтобы быть в одном месте.
Человек с DDD-бэкграундом спроектирует нормально и напишет на Go через боль. Человек выросший только на Go часто не видит проблемы в анемичной модели и сервисном слое на 2000 строк.
Сеньоры на Go часто переплачены за страдания или это люди с бэкграундом из "нормальных" языков которые вынуждены пасти стадо пишущих код на Go.
Да, вот, тоже сложилось впечатление, что зп у сениоров гошников выше, чем у сениоров си-шарпников, потому что страдать приходится больше. Что обидно.
Только не надейтесь стать го сеньором: конкуренция огромная, требования высокие.
А чем отличаются требования на Го сеньора и требования на Java (или .NET) сеньора?
Лично видел людей, которые становились го сеньорами, которые до того писали много на джаве. Скорее важен общий опыт в бекенде, умение строить микросервисную архитектуру, опыт с kafka, базами, телеметрией итд итп. Язык тут в целом вторичен. Поэтому многие компании нанимают людей без привязки к конкретному языку.
И не понятно, почему эти требования считаются высокими. Как по мне, далеко не высокие, а вовсе обычные.
Думаю, тут написано какие подводные камни должен знать сеньор гофер.
Вкратце: стоит сеньор / сеньоры и выгребает говно, созданное всей командой из-за выбранного языка.
https://habr.com/ru/articles/676994
Длинное перечисление проблем одного проекта...
Тем не менее, Tailscale пользуется Go. Это ошибочное решение? Совсем не обязательно! Ведь их команда состоит из экспертов по Go. В чем можно убедиться, прочитав другую их статью, о линковщике Go.
Поскольку эти люди – эксперты по Go, они заранее знают, чего им будет стоить работа с Go, поэтому обладают необходимой компетенцией, чтобы обоснованно решить, стоит или нет прибегать к Go. Они глубоко разбираются в том, как работает Go (именно те аспекты, о которых маркетинг Go клянется и божится «да вам же этим никогда не придется заморачиваться, зачем же вы спрашиваете?), поэтому, столкнувшись с пограничными случаями, они смогут углубленно изучить каждый случай, исправить проблему и дождаться, пока их фикс будет передан наверх (если вообще будет передан).
Но весьма вероятно, что вы не из таких экспертов
Sunk cost + экспертиза У НИХ уже есть.
Переписать - дорого. А их специфические знания Go уже окупаются, для новой команды эти же знания надо накапливать заново в другом языке.
Плюс Go им подходит: сетевой код, concurrency, быстрая компиляция. Для их задачи (VPN, сетевой стек) - норм выбор.
Не значит что для вашей задачи и команды тоже подойдёт.
выгребает говно, созданное всей командой из-за выбранного языка
В любом языке полно неочевидных моментов и костылей. Полно таких же статей про Rust/Python/C#/C++ и другие языки. Го тут ничем не отличается. Все нюансы языка, которые в статье перечислили, иногда спрашивают у джунов и стажеров при трудоустройстве, это довольно известные недостатки языка, про которые везде написано и про которые все знают.
Каких-то супер специфичных знаний в гигантском объеме у гошников нет, этот язык кратно проще чем Rust или C++.
Есть просто люди, которым в целом нормально писать на Go, а есть те, которые по каким-то причинам яростно этому сопротивляются. Есть и люди, которые яростно сопротивляются Rust (и которые пишут на Go/C++/Java) и наоборот. Это просто психология такая. В реальном проде в целом все равно на язык, чем проще, тем лучше.
Поэтому при трудоустройстве в бигтех компании никто досконально не спрашивает тонкости java или с++ или python. Есть алгоритмические секции (которые все решают на питоне) и дизайн секции, где код писать почти никогда не нужно. И алго секция идет в режиме зачет/незачет, а вот грейд кандидата уже оценивается по дизайн секции. Можно всю кодинг секцию сдать на питоне, но прийти в команду писать на С++ или на Go или Java.
при трудоустройстве в бигтех компании никто досконально не спрашивает тонкости java или с++ или python
Не уверен, но неплохо бы.
Есть просто люди, которым в целом нормально писать на Go, а есть те, которые по каким-то причинам яростно этому сопротивляются
причина почему "некоторые сопротивляются" проста до невозможности: люди не хотят писать на этом императивном инвалиде с отсутствием банальнейших синтаксических конструкций и поддерживать получившиеся на выходе тонны бойлер-плейта
В реальном проде в целом все равно на язык, чем проще, тем лучше.
Если бы это было истиной, то 99% бэкэндов были бы написаны на Python (но нет)
Поэтому при трудоустройстве в бигтех компании никто досконально не спрашивает тонкости java или с++ или python
очень даже спрашивают: вдоль и поперек, именно знания (и понимание) профильного ЯП. По крайней мере в той бигтех компании, где я работаю и провожу интервью)
а вот грейд кандидата уже оценивается по дизайн секции
разрешите узнать, в какие конкретно компании рос бигтеха вы проходили интервью за последнее время?
с отсутствием банальнейших синтаксических конструкций
Каких именно?
Если бы это было истиной, то 99% бэкэндов были бы написаны на Python
На самом деле очень много проектов на рынке написано на питоне. Даже в энтерпрайзе лично видел большие монолитные финтех молотилки написанные целиком на питоне.
разрешите узнать, в какие конкретно компании рос бигтеха вы проходили интервью за последнее время
Яндекс и Авито. Май-июнь прошлого года. Приходил на собесы с опытом на джаве, получил офферы в команды, которые только на Го пишут. Но по итогу никуда отказался и никуда не пошел, так как требовали быть в РФ в офисе.
Каких именно?
Начнем с банального отсутствия "for each" / "for in" цикла
На самом деле очень много проектов на рынке написано на питоне.
я это знаю, я сам питонист. Но "много" != "все". Питон зачастую в принципе не "вывозит" нужные нагрузки, а тот же golang тоже имеет свои ограничения, как и свои явные минусы
Яндекс и Авито. Май-июнь прошлого года
спасибо за честный ответ. Но рос бигтех не ограничивается лишь Яндексом и Авито
О покрытие всего этого тестами я вообще молчу
я не знаю, как на этом писать код, у которого можно проверить гарантированную корректность работы
А в чем проблема? Тестовый пакет есть в стандартной либе. Тестконтейнеры тоже есть. Не вижу каких-либо отличий в том, как тестируют на Python/Java/C# и как это делают в Go.
Есть целая бесплатная опенсорсная книжка про то, как писать тесты для Go кстати. Очень хорошая, всем рекомендую. https://quii.gitbook.io/learn-go-with-tests
а вместо нормальных dto
Вполне используем DTO для джейсончиков и для походов в базу.
каждый новый микросервис уникален и не похож ни на что другое, виденное ранее
А в чем уникальность?
А в чем уникальность?
Насколько я могу судить - "энтепрайзные" языки предоставляют определенных подход как оформлять контроллеры, бизнес-слой и так далее. Это зашито в их фреймворках, интерфйсах, документации и книгах.
В случае c Go - видимо этого нет и все пишут как бог на душу положит. Программист, который начал с Go - даже не знает, что все это дефолтные вещи для других программистов из "энтепрайзных" языков.
Мне как-то на хабре попалась статья - там чел на Go написал руками все то, что в C# из коробки - контроллеры и все вот это вот. Еще подача такая была типа для него это в новинку. А я уже лет 10-15 так пишу на C#. И все так пишут. Приходишь в новый проект и там все в целом знакомо - знаешь что ждать от контроллеров, от бизнес слоя, от слоя данных и так далее. То есть в голове у толпы людей вырисовывается некая общепринятая иерархия и структура.
Может быть я что-то не понимаю, но я не знаю, как на этом писать код, у которого можно проверить гарантированную корректность работы, а так же который можно спокойно развивать силами команда
И я не знаю. Лол.
Найдется тут кто-то, кто сможет это объяснить?
Краткий ответ: никак. Го не для долгоживущего кода. Если не выкинули через полгода, то это матюги архитектора и сеньора. И жёсткие линтеры. Ну или код иногда падает/врёт - многим не критично на фоне нестабильной сети, например или просто не критичное приложение
В общем-то изначально Go делался как язык для инфраструктуры, а потом уже на нем попробовали писать бизнес-логику и пришли к мнению, что и ее можно на го делать.
Лично я тоже самое думаю про Rust. У него большой потенциал в энтерпрайз (богатая бизнес логика, ответственные приложения), то есть шире чем системное программирование
Что значит "обрезанный REST API"?
Ну вот я ткнул пальцем в небо - rate limit
Вот C# и asp.net core https://learn.microsoft.com/en-us/aspnet/core/performance/rate-limit?view=aspnetcore-10.0 - вызываешь AddRateLimiter, прописываешь опции, все из коробки
Вот Go и net/http https://pkg.go.dev/net/http#pkg-examples - поиском не находит rate limit
Вот Go и gin просто гугл поиск выдал https://pkg.go.dev/golang.org/x/time/rate - отдельная либа, уже лучше, но AddRateLimiter из коробки от Microsoft все же надежней
Мое мнение - либа написанная на коленке одиночкой, крупным опен-сорус сообществом или крупной коммерческой компанией (Uber) и корпорацией, которая создала и поддерживает сам язык программирования - это три разных уровня доверия и надежности. Одиночка, опен-сорус могут исчезнуть и проект останется без поддержки. Если исчезнет корпорация - придется учить новый язык программирования.
но как правило DI контейнер сами пишем с нуля
Собственно это и главная моя претензия в моем оригинальном комментарии, между строк. Походу много чего надо писать самому руками (это дополнительные ресурсы на поддержку) или использовать сторонние либы. Google не выдал готовый фреймворк уровня asp.net core.
DI контейнер в C# встроенный. И я тут посмотрел доку https://uber-go.github.io/fx/lifecycle.html в разделе lifecycle я не вижу singleton, scoped и transient - это я тоже должен написать руками? В C# проектах это активно используется - http context, orm context / sql connection - это scoped. Всякие фабрики - это singleton, ну а остальное можно transient.
Киллер-фича Go это компиляция в бинарь и быстрый запуск + легковесный рантайм
Не увидел разницы с asp.net core / kestrel для первых двух. docker образы по размеру не сранивал. exe файл у C# легче (150кб, вместо 28 Мб), но у C# еще куча подключенных либ - общий весь примерно такой же (30 Мб)
rate limit
А зачем он в стандартной библиотеке?
https://pkg.go.dev/golang.org/x/time/rate - вот эта либа как раз и написана разрабами из гугла и ими поддерживается. Просто решили не тащить его в стдлибу, вот и все.
Походу много чего надо писать самому руками
В целом нет. Вся необходимая обвязка пишется за пару часов руками или за 10-20 минут при помощи LLM, дальше разработка бинес-логики почти не отличается от того, как это на джаве/питоне/сишарпе происходит.
В целом если раньше это был аргумент, то в эпоху LLM, когда все типовое генерится за пару минут, уже не особо. Да и без LLM можно гошные сервисы вполне удобно генерить при помощи стандартной генерилки, главное шаблон настроить правильный.
А зачем он в стандартной библиотеке?
Да, знаете, привык наверное уже. Понадобилось что-нибудь - сначала посмотреть в system. Наверняка что-нибудь найдется, с готовым интерфейсом и настраиваемое. И гугл выдаст за секунду пример как это использовать.
Потом уже, когда проект живет некоторое время - можно наткнутся на ограничение, или найти что-нибудь получше / поинтересней. Но вот недавно товарищ, который писал automapper (либа для маппинга полей туда сюда) сделал ее платной. И все, приехали.
Тут трейдофф есть очевидный.
Можно в стандартную либу пихать много и всякого. Как в общем-то и делали на заре Java и .NET, где старались добавить абсолютно все, чего угодно разработчику, даже собственную GUI библиотеку (Swing/AWT, Winforms, WPF и прочее).
Либо делать стандартную либу максимально урезанной и без ничего (как например в чистом Си).
В первом случае получаем дорогостоящую поддержку именно стандартной либы. Потому что языки существуют долго и внезапно много чего может устареть, какие-то подходы оказаться неправильными и пересмотренными с годами, итд итп. Насчет GUI и всего что с ним связано я вообще молчу - это никогда нельзя тащить в стд либу.
Но в случае с минимальной либой как в чистом Си банально сложно писать код. Где нет ни map, ни list, ни нормальной работы со строками.
Имхо Go попытался попасть в середину так чтобы нигде никому не навредить и отчасти им это удалось. Но местами вышло явно неудачно, например отсутствие нормальных коллекций из коробки на старте языка и довольно причудливое API для взаимодействия с ними. Но что есть, то есть...
А понял, все же тут не совсем так.
Формально все эти вещи в C# - это тоже отдельные либы, это не стандартная (но namespace aka package обычно начинаются с System.*** или Microsoft.***). Их надо подключать. Просто IDE настолько дружелюбная, что когда пишешь в редакторе кода AddVersioning или AddRateLimiter - она услужливо автоматом предлагает подключить нужную либу. И создается ощущение единого фреймворка.
Попробовав Go, я задал себе вопрос: "Зачем мне писать велосипеды, если их уже написали за меня, C#, javascript, Python, Ruby и т.д."? В итоге, с Go получается, что код, который непосредственно выполняет бизнес-задачи, теряется в остальном коде, что требуется написать из-за необходимости (без него никак), а для других языков уже есть готовые фреймворки и библиотеки. И зачем все это? Какой смысл, выгода? Зачем на это тратить время, силы?
Concurrency в Go сделано на порядок лучше (имхо) чем в c#, js, python и ruby. Rust - гораздо более сложный и тяжелый для чтения язык. Фишка Go как раз в том, что код очень прозрачный, нет никакой магии рефлексии, AOP, прокси и всякого синтаксического сахара - можно в любой точке проекта поставить брейкпоинт и дебажить без боли. Нет невидимых действий под капотом, кроме разве что GC и шедулера горутин.
На питоне так вообще разрабатывать что-то больно. Если mypy с самого начала не завезли, то все, пиши пропало...
Фишка Go как раз в том, что код очень прозрачный, нет никакой магии рефлексии, AOP, прокси
Зато полно другой магии, гошной
А какой именно магии? Шедулер горутин и netpoller? Кроме GC это единственная магия, которая в Go есть. Все остальное крайне простое и топорное.
Согласен.
Просто го вылез в нужное время в нужном месте. Ну, легко пришёл легко уйдет.
Го для проектов с высокой текучкой - тысяча бывших таксистов пришла, потом тысяча ушла...
Кстати, магия это скорее ругательство
Не совсем понятно, куда переезжать с Go. А на Go много кто уже переехал и переезжает прямо сейчас.
По-хорошему в бекенде нужен язык как Java, но:
без наследования (но с интерфейсами)
с виртуальными тредами
с нормальными дженериками
с легковесным рантаймом
компилирующийся в бинарь со всеми зависимостями
с наличием GC
В целом, Go более-менее удовлетворяет всем этим требованиям. Если бы не личные шизоидные идеи Роба Пайка и его странный, местами, взгляд на то, каким должен быть язык программирования, то возможно мы бы получили более лучшую версию Go чем есть сейчас. Но что есть, то есть.
тысяча бывших таксистов пришла, потом тысяча ушла
Про таксистов конечно же wishful thinking, на Go вполне тяжелые проекты пишут, где вчерашние таксисты с курсов вряд-ли потянут... Да и вообще на Go обычно переходят с других языков, либо студентов из хороших универов на стажировки берут.
Без GC и рантайма это Rust: остальное всё есть в лучшем виде
на Go обычно переходят с других языков
С PHP? Лол
Виртуальных тредов в Rust из коробки нет. Надо использовать Tokio, что почти всегда сложнее чем горутины и каналы в Go. Без GC писать тоже кратно сложнее чем на языке с GC.
С PHP? Лол
Ну я пришел в Go после нескольких лет джавы. Проект рабочий сйчас мигрирую с джавы и питона на Go.
Видите, вот и питон... Не похоже на энтерпрайз
Это финтех. Гигантский монолит на джаве и несколько микросервисов вокруг него на питоне. Вся эта машинерия в сутки считает миллионы долларов. Довольно серьезный уровень, где нужно чтобы все работало 24/7. Вполне энтерпрайз, имхо...
Да и российские маркетплейсы, которые на Go написаны, вполне очень хардкорный уровень. Пусть и не энтерпрайз в классическом понимании.
Одно время считал Go лучшим с-подобным языком программирования. Писал один достаточно большой десктопный проект, и понял, что явная обработка ошибок это боль в Go: когда у тебя логика через строчку сопровождается обязательной проверкой err, это беда. В этом плане стандартная обработка исключений в C# делает большой код намного более читаемым.
С дженериками в го, кстати, не так все богато как в шарпах, но зато в go кодогенерация удобнее, на мой взгляд. Остальное вкусовщина и дело привычки. Для компактных быстрых микросервисов - гошка может приятно удивить. Памяти он есть действительно меньше и этого не отнять (ну если не АОТ сравниваем).
Для меня проблема с го следующая: его идеомы, когда пишешь на нем часто - привыкаешь, понимаешь где случайно не скопировать весь массив, где лишний раз не захватить переменную, и уже появляется чутье, как избежать рейс кондишенев. Но как только попадаешь в родные шарпы и там проводишь месяц другой в зоне комфорта (тот же ddd без костылей, прогнозируемые в поддержке монолиты) - переключаться на го сложно - опять надо привыкать. Кстати с шарпов на джаву и с джавы на шарпы такого эффекта не ловил, хотя давно на джаве уже не писал.
О, я тоже самое сделал. Правда я только до хвалёных горутин дошёл целеустремлённым галопом. Посмотреть на них, себя показать...
Раньше у меня был вопрос: "Что такого есть в Го, чего бы не было в Rust?", теперь вопрос стал: "Что такого есть в Го, что в Rust не было бы проще?". Вывод в консоль разве что... Я вообще не понял, в чём идея этого языка.
Что такого есть в Го, что в Rust не было бы проще?
Горутины и сетевой стек. Готовность к микросервисам.
Другое дело что не стоит переплачивать за такие плюсы.. ну, кому как
В Rust есть раскраска функций как минимум, в Go ее нет. Писать на Go проще, потому что везде вы работает с синхронными функциями. Это сильно проще чем асинхронщина, для которой в случае Rust придется еще и Tokio изучать.
В общем-то в джаве и пошли по пути зеленых потоков (они же virtual threads в java или goroutines в go), просто потому что это проще для разрабов, чем async/await.
Преувеличение
А преувеличение чего? Async/await однозначно делит мир на два отдельных мира - сихронный и асинхронный, между которыми приходится прокладывать довольно сложные и причудливые мосты. В Go все синхронное.
Добавить в язык async/await - однозначно и навсегда выполнить это разделение. Поэтому в джаве и не стали так делать, хотя в общем-то могли и обсуждали.
Ну в Tokio же есть и virtual threads. Но да, отмечать вручную async надо.
как-будто разделение на красно-синие функции - самая большая проблема при выборе модели конкурентности в реализации того или иного ЯП. В го принцип выталкивающей многозадачности (у которого, несомненно, есть ряд преимуществ), в пайтоне - чистая кооперативщина, в расте - микс того и другого (как собсно и в скале / котлине / e.t.c)
А в целом, подавляющее большинство языков с async/await, и программисты на этих языках как-то же существуют и пишут код
просто потому что это проще для разрабов, чем async/await
для каких именно разрабов? Мамкиных вайбкодеров, которые лишний раз не перенапрягутся, дабы хоть немного изучить, как работает модель конкурентности в ЯП, на котором они пишут?
Кстати, если рассматривать Go как процедурный паскаль на стероидах с нативной поддержкой http и асинхронности - пожалуй и ниче так. Но это сразу ограничивает применимость в моей голове и ожидание больших граблей.
Во всех новостях про этот рейтинг как-то опускается простой вопрос - что это вообще за рейтинг, как он считается и насколько вообще релевантен и актуален? Такое впечатление, что основной его смысл - генерация новостей для технических сайтов, могу ошибаться конечно.
как он считается
По количеству упоминаний того или иного языка в поисковой выдаче. Может быть немного по-другому, но основа рейтинга такая.
насколько вообще релевантен и актуален
Почти нисколько.
основной его смысл - генерация новостей для технических сайтов
Так и есть.
Реальные рейтинги можно у гитхаба посмотреть. Там явно лидируют очевидные лидеры - Typescript и Python.
Занятно: языком года назвали с#, а обсуждают в "событии" в основном go.
Удивляет, что при наличии благородного шарпа так широко юзают отсталый варварский го)
Да что уж там: передовой delphi наконец обогнал варварский go. Жизнь не стоит на месте.
Да просто когда то этот Го году в 2015 привезли с Запада в Россию какие-то тамошние менеджеры, а сейчас западники ушли так все и осталось неизменным
Ну, справедливости ради .NET и прочие технологии тоже с запада привезли, а не откуда-то еще. И Microsoft тоже с российского рынка нынче ушел, как и Гугл, и Оракл.
В моем универе так вообще Microsoft целые лекции организовывал в середине 00х годов, на которых рекламировали .NET. В целом дотнет был популярен в России какое-то время, но сейчас эти времена прошли окончательно, судя по рынку вакансий и на чем в больших ру компаниях пишут.
А шуму то было... "Ой у нас в стартапе все на го... Ой у нас бакенд на питоне... Ой у нас джава все сама делает, даже формы... А мы делаем фронтэнд на руби, а чатбот на ассемблерре, а репозитории открываем логарифмической линейкой. А платить майкрософту - фууу, старье дорогое"
А в конце концов все и пришло к самому быстрому и гибкому .Net. как он был самым быстрым и многоприменимым так и остался. Сейчас ещё десятка .Net Core вышла, 26-я студия. Любо дорого смотреть
Низкая популярность дотнета обусловлена тем, что где-то до середины 2010х годов его нельзя было запустить под линукс. То есть надо было держать windows server, чего почти никто делать не хотел.
Потом конечно когда стало понятно, что linux+контейнеры это будущее, а Сатья сменил Балмера, в MS таки сделали версию для линуха, но было уже чутка поздновато, так как все бигтехи к тому моменту уже плотно сидели на java, питоне, руби, пхп и прочих кроссплатформенных решениях. Собственно поэтому нигде в американском бигтехе кроме самого MS нет .NET.
А платить майкрософту - фууу, старье дорогое
Ну так и есть. А зачем платить майкрософту, когда есть бесплатные опенсорсные решения? Я вот никогда не возьму win server за деньги вместо бесплатного linux.
Собственно поэтому нигде в американском бигтехе кроме самого MS нет .NET.
Нигде - громкое слово. Есть дотнет, галеры типа EPAM находили такие проекты и поддерживали. Да, там часто до сих пор следы виндовых проектов - какой-нибудь IIS например, но и линукс сервера уже тоже можно встретить.
Это все было правдой до 2015-2016 года. А потом пришёл. Net Core. Вот за 10 лет у нас все и консолидируется. Пхп, умер, Гугл сворачивает Го в угоду оберток над джавой.
Не знаю, как в США, а в Британии почти все компании от малых до больших с середины десятых сидят на .Net. Есть те, кто сидит на Джаве, но это в основном легаси кодовые базы, на которые нанимают контрактников их переписать под .Net
C# стал языком 2025 года по версии TIOBE