Комментарии 75
Go - всё!
И все? Это прям целая статья на хабре? Без анализа, без развернутого изложения, без за-против? Просто: «Все ОК, не парьтесь»?
Главный аргумент - одна баба сказала.
означает лишь то, что язык стал привычен, удобен
А Python, C и Java, получается, непривычные и неудобные?
Происходит это регулярно и в рейтинге за январь 2026 года Go оказался на 16 месте, хотя в ноябре 2024 он занял седьмую позицию.
На картинке - январь 2025, а не ноябрь 2024.
Сам язык Go мне вообще не нравится. Для меня он даже хуже какого-нибудь Pascal. Да что там, Malbolge - и тот приятнее. Очень ограниченный язык, который вообще не уважает твою способность мыслить (собственно он для этого и был создан - чтобы программист писал весьма и весьма ограниченный код). Очень трудно на нём выражаться, очень мало пространства для свободной мысли, куча boilerplate кода, концепций и абстракций для оперирования на пальцах можно посчитать. И на таком языке успешно пишут инфраструктурный код... да ядра программной виртуализации... поразительно конечно...
А вообще забавно, что те, кто этот язык часто использует так реагируют на понижение его рейтинга) Kotlin вообще на 20 месте, а в Android разработке сейчас без него практически никуда, а это один из самых развитых массовых рынков (мобильные приложения).
>концепций и абстракций для оперирования на пальцах можно посчитать
Так это же плюс.
Так это же плюс.
пока у вас проект пяток разработчиков пилят, а не 500
я вот бывал на проектах, на питоне, которые начинались с "нам не нужны абстракции и типизации" и потом заканчивались во впиливании сериалайзеров, контролем типов, внедрением интерфейсов и вообще всякого ООП...потому что крупный проект без этого всего ненужного, превращается в помойку
по голангу у меня схожие мысли, но в отличии от питона там прям "низя потому что вам ненужно так делать" вызывает разрастание кодовой базы и путаницу
там прям "низя потому что вам ненужно так делать" вызывает разрастание кодовой базы и путаницу
У меня есть смутные подозрения что это не ради показательного мизантропского унижения программеров сомнениями в их интеллектуальных способностях, а "чукча, покорми Белку и Стрелку, но больше ничего не трогай"(c). Т.е. возможно язык изначально создавался не для людей, а как специальный стенд/костыль для обучения LLM программированию - как раз для нее бойлерплейт не проблема, а лишние абстракции и степени свободы пока мешают.
В golang эта проблема возникает из-за отсутствия практик и общепринятых методик. В итоге каждый акын поет как видит. Плюс это же накладывается на понимание как использовать интерфейсы. Пока у вас маленькие сервисы это еще как-то обозримо.
проблема возникает из-за отсутствия практик и общепринятых методик.
но там же есть системный маразм какойто, типа неявных интерфейсов, тонны if err:= на любой пук, тут даже захочешь чтото логичное сделать - так нельзя, не то чтобы не принято, прям таки нельзя
типа неявных интерфейсов, тонны if err:= на любой пук, тут даже захочешь чтото логичное сделать - так нельзя, не то чтобы не принято, прям таки нельзя
Вы пытаетесь делать как в другом языке. Это нигде не работает. Если будете практики C# или java тащить в python такие же проблемы будут.
if err:=
Хотя бы заставляет обрабатывать ошибки а не кидать общий exception
Учитывая, что забыть написать if err:= очень легко и компилятор даже не всегда ругается на declared and not used — лучше бы уж общий exception кидали
Достаточно включить еще линтер. Он вам все необработанные ошибки припомнит :)
А общий эксцепшен можно кинуть, только это строго не рекомендуется. В целом все кто пишет на golang так или иначе обработку делает практически на автомате.
Во-первых, столь важные линтеры должны быть включены по умолчанию
Во-вторых, обработка ошибок в Rust всё равно лучше — в нём технически невозможно обратиться к возвращённому значению, предварительно не проверив отсутствие ошибки, так что даже без линтера особо накосячить не получится (хотя линтер всё же есть и включен по умолчанию), а в гошечке словить nil pointer dereference как нефиг делать
Во-первых, столь важные линтеры должны быть включены по умолчанию
У golang и так из коробки довольно строгие проверки. Ну а указанный линтер так или иначе применяют практически все програмисты на golang.
Во-вторых, обработка ошибок в Rust всё равно лучше
Пишите на rust кто вам мешает? Проблема rust в том что он сам по себе сложный язык. Я его открыл посмотрел понял что это очередной вариант C++ и решил не вкладываться в это дело. В Golang как раз таки из-за большей простоты заскочить и писать можно существенно быстрее.
а в гошечке словить nil pointer dereference как нефиг делать
А в C еще проще. И что?
А в C еще проще. И что?
А то, что не надо программировать на языках со столь серьёзными фундаментальными проблемами ¯\_(ツ)_/¯
Языки, в которых нужно помнить о проверках на nil, сложнее, чем языки, в которых помнить это не нужно
Ну т.е. и C не надо программировать? Ну и на javascript заодно. Более того я могу в любом языке найти фатальный недостаток
Языки, в которых нужно помнить о проверках на nil, сложнее, чем языки, в которых помнить это не нужно
Конечно же нет. Это мнимое упрощение. Это вот прям как сказать что в язык с автоматическим сборщиком мусора не надо отслеживать как ты память используешь.
Ну т.е. и C не надо программировать?
Да, C уже отслужил своё, в винду и линукс уже начали потихоньку завозить Rust
Ну и на javascript заодно.
Да, это язык со столь богатым списком родовых травм, что его популярность это какое-то недоразумение (и поэтому никто давно не использует javascript напрямую, все перекатились на хотя бы typescript, который позволяет не помнить о проверках на null)
в язык с автоматическим сборщиком мусора не надо отслеживать как ты память используешь
Со сборщиком мусора не надо помнить, где и когда вызывать деструкторы, так что со сборщиком проще чем без него (но он имеет свою цену в рантайме)
...зато со сборщиком мусора нужно помнить о закрытии внешних ресурсов вроде файловых дескрипторов, так что RAII из Rust и даже C++ может оказаться проще чем сборщик, и это дало мне повод вспомнить о ещё одной фундаментальной проблеме Go под названием defer (хотя есть и альтернативное мнение об этом)
Да, C уже отслужил своё, в винду и линукс уже начали потихоньку завозить Rust
Ага. Я помню в том числе критику Линуса в сторону rust. И да rust не от всех ошибок спасает особенно если люди unsafe используют.
Да, это язык со столь богатым списком родовых травм, что его популярность это какое-то недоразумение (и поэтому никто давно не использует javascript напрямую, все перекатились на хотя бы typescript, который позволяет не помнить о проверках на null)
Потому что он банально интегрирован в браузер. Более того если бы в браузер интегрировали вместо js все же lua всем было бы СИЛЬНО легче.
Ну а typescript затем благополучно транслируется в js БАДУМЦ.
сборщиком мусора не надо помнить, где и когда вызывать деструкторы, так что со сборщиком проще чем без него (но он имеет свою цену в рантайме)
Многие считают что не надо помнить про вообще память. Чем благополучно выстреливают себе в ногу.
Со сборщиком мусора не надо помнить, где и когда вызывать деструкторы
Не совсем. Деструкторы - это не только про память, иначе не было бы нужды в try-with-resources/AutoCloseable в Java и using/IDisposable в C#
Хотя бы заставляет обрабатывать ошибки а не кидать общий exception
их не всегда надо обрабатывать прям ВСЕ и обязательно
грубо говоря, нафиг не нужно обрабатывать ошибку обрушения БД на каждом запросе к базе...пускай оно общим исключением рухнет...всёравно всё плохо уже, а подробная детализация в такого рода ошибках не нужна
Вы пытаетесь делать как в другом языке.
конечно, но предложенный вариант выглядит как "наши ребята посчитали что это не нужно. по этому так делать нельзя"...а потом оказывается что комуто всётаки нужно...например когда проект становится огромным или разработчиков обчень много...но ничего с этим уже не сделать, это зашито в архитектуру
их не всегда надо обрабатывать прям ВСЕ и обязательно
Угу, А потом приложения валятся с exception. В своей практике я это видел часто.
грубо говоря, нафиг не нужно обрабатывать ошибку обрушения БД на каждом запросе к базе...пускай оно общим исключением рухнет...всёравно всё плохо уже, а подробная детализация в такого рода ошибках не нужна
Вы получили ошибку дальше решаете что с ней делать. К примеру можете ее не обработать. Но это будет явно. А не просто не обработали и оно где-то выше стрельнуло. Именно вот от такого да не надо ее обрабатывать и защищались. Да это муторно, но вполне полезно.
а потом оказывается что комуто всётаки нужно...например когда проект становится огромным или разработчиков обчень много...но ничего с этим уже не сделать, это зашито в архитектуру
Не пытайтесь применять практики характерные для другого языка. Это прям сильно вам мешать в итоге будет. Потому что усилия будут тратится на поддержание этого не характерного. К примеру в golang это выражается в попытках затащить туда DI и IoC аналогичные другим языкам. В итоге использование таких инструментов начинает сильно мешать разработчикам, так-как вместо написания кода они начинают тратить время на поддержание.
Угу, А потом приложения валятся с exception. В своей практике я это видел часто.
я тоже видел, а может им и нужно с ним валится? что вам даст err где ошибка недоступности какогото микросервиса? вы пользователю всёравно 500 отдадите (допустим мы вебсервисы делаем), и починить ничего не сможете
что вам надо в такой ошибке обрабатывать? да ничего. залогировать и рухнуть
Вы получили ошибку дальше решаете что с ней делать. К примеру можете ее не обработать. Но это будет явно.
ошибок может быть миллиард, вы каждую будете явно обрабатывать? допустим у вас будет ошибка о превышении уровня радиации на марсе..которую вам ответит Redis сервер..вы будете if err:="mars radiation on redis" писать?
И это в языке где неявные интерфейсы "да кому надо их явно указывать, фи лишний код"...непонимаю
так-как вместо написания кода они начинают тратить время на поддержание.
а вы пробовали поддерживать очень крупные проекты когда от первоначальной команды никого не осталось? я вот пробовал, проекты которые писались людьми довольно далекими от разработки, которые писали проект просто навалом..без ненужных абстракций...просто огромная куча кода с копипастом процедур и т.п.
я вот пробовал, написание проектов - это не просто "бац-бац и работает", а чтобы еще не охренеть с поддержкой через год
я тоже видел, а может им и нужно с ним валится? что вам даст err где ошибка недоступности какогото микросервиса? вы пользователю всёравно 500 отдадите (допустим мы вебсервисы делаем), и починить ничего не сможете
Да вот чаще всего это была необработанная кем-то ошибка.
ошибок может быть миллиард, вы каждую будете явно обрабатывать? допустим у вас будет ошибка о превышении уровня радиации на марсе..которую вам ответит Redis сервер..вы будете if err:="mars radiation on redis" писать?
Вы вообще писали на golang? У меня складывается ощущение на картинках видел и в код заглядывал. В 90% случаев у вас будет ошибка передается выше по цепочке. Или же банально пишется в лог если требуется. Количество ошибок и их обработка не меньше и не больше чем в других языках.
И это в языке где неявные интерфейсы "да кому надо их явно указывать, фи лишний код"...непонимаю
Судя по этому на картинках видели. У вас код не скомпилируется, если ваша реализация четко не соответствует интерфейсу. В каком виде это не явно? Там ругань будет даже кто кому не соответствует. И в IDE подсветит что не соберется.
а вы пробовали поддерживать очень крупные проекты когда от первоначальной команды никого не осталось? я вот пробовал, проекты которые писались людьми довольно далекими от разработки, которые писали проект просто навалом..без ненужных абстракций...просто огромная куча кода с копипастом процедур и т.п.
Регулярно. У меня одна из частых задач что-то починить или отрефакторить. И вот тут простота языка golang несколько играет в его пользу. На нем проще читать код. Ну за исключением когда люди внезапно в нем начинают заниматься ерундой и играться с горутинами и каналами не к месту.
Да вот чаще всего это была необработанная кем-то ошибка.
Это прям системная проблема которая требует нового языка?
подавляющая часть ошибок сервисов - это или инфраструктурные или ошибки аналитики и очень малый процент - непосредственно ошибки "мы забыли обработать исключение"
В 90% случаев у вас будет ошибка передается выше по цепочке.
ага, вот по этому я и придираюсь, что с этим проклятым err надо таскаться как с писаной торбой везде и всюду, чтобы случайно не потерять что там из глубин космоса передалось и где что надо обработать
Количество ошибок и их обработка не меньше и не больше чем в других языках.
только там где можно в других языках ничего не писать, тут надо писать, или код будет выглядеть неправильно и линтеры будут орать
У вас код не скомпилируется, если ваша реализация четко не соответствует интерфейсу.
А тут не в этом дело
interface MusicPlayer()
{
func start()
func stop()
}
interface Bomb()
{
func start()
func stop()
}
class NuclearBomb()
{
func start()
func stop()
}
class MusicPlayer()
{
func start()
func void stop()
}
func StartMediaOnBunker(object MusicPlayer)
{
object.start()
}
# а теперь магия, программист тупо ошибся в вызове
StartMediaOnBunker(NuclearBomb())
(я описал образно, язык тут не важен)
давайте, расскажите мне что "программист должен следить сам за вызовами, а не компилятор или в рантайме валидатор типов"
в условной яве такой фокус даже не скомпилируется
Ну за исключением когда люди внезапно в нем начинают заниматься ерундой и играться с горутинами и каналами не к месту.
про горутины у меня отдельная пачка матюгов, к тому что в документации и в рассказах о голанге они упоминаются как магия и что "не надо упарываться как в яве"...изза чего каждый второй косячит с синхронизацией и устраивает утечку горутин...потому что "умный голанг всё сам делает"
вы правильно упомянули, пока не начинают играться с горутинами...потому что блин ЯЗЫК позволяет, даже на уровне документации...и не предупреждает что для правильной асинхронщины надо хотябы книжку почитать чтобы понять как она работает
Это прям системная проблема которая требует нового языка?
Это одна из причин почему обработка ошибок в golang сделана так. Прям в мотивации писали
ага, вот по этому я и придираюсь, что с этим проклятым err надо таскаться как с писаной торбой везде и всюду, чтобы случайно не потерять что там из глубин космоса передалось и где что надо обработать
Да есть такое. Но к примеру дизайн когда где-то снизу кидают исключение, а на верхнем уровне его просто гасят чтобы приложение не падало не менее проклято. И да такой дизайн довольно часто делают.
только там где можно в других языках ничего не писать, тут надо писать, или код будет выглядеть неправильно и линтеры будут орать
И это потом приводит к необработанным ошибкам или к ловле ошибок где-то на верхнем уровне с плохой обработкой. Что тоже плохо.
в условной яве такой фокус даже не скомпилируется
Скомпилируется если у вас будут указаны одинаковые интерфейсы у классов. И да еще в golang нет перегрузки функций по этой же причине. Зато у вас не возможна ситуация когда у вас есть два разных интерфейса с одинаковыми сигнатурами. А вот это тоже плохо.
про горутины у меня отдельная пачка матюгов, к тому что в документации и в рассказах о голанге они упоминаются как магия и что "не надо упарываться как в яве"...изза чего каждый второй косячит с синхронизацией и устраивает утечку горутин...потому что "умный голанг всё сам делает"
На самом деле вот эта часть сделана лучше чем в других языках. В том числе и из-за наличия каналов. То что вот каждый косячит, ну это скорее вопросы к тем кто так доку пишет. У меня например там есть претензия к рассказам что горутины почти бесплатны. А потом начинающие фигачат их под тыщу и спрашивают а чего тормозит :D
Это одна из причин почему обработка ошибок в golang сделана так. Прям в мотивации писали
Это я знаю, и это дичь какаято чесслово
а на верхнем уровне его просто гасят чтобы приложение не падало не менее проклято. И да такой дизайн довольно часто делают.
да, у меня на питоне сейчас такой проект, вот это я угорел искать ошибку которая через пару десятков вызовов пробрасывается наверх и неявно гасится
ошибка кстати инфраструктурная..типа недоступность системного файла гдето...какбы напрямую её не надо обрабатывать, а ктото умный гдето общий обработчик повесил и тупо подавляет всё "лишнее"...а вы ищите потом почему ниче не работает, а ошибок нет нигде
но к слову, в голанге тоже самое можно устроить
Скомпилируется если у вас будут указаны одинаковые интерфейсы у классов
т.е. надо ДВА раза ошибиться, не просто перепутать вызов, а еще и у класса интерфейс указать неправильно (а тут отвалятся уже штатные места использования этого класса)...и всёравно ниче работать не будет
Зато у вас не возможна ситуация когда у вас есть два разных интерфейса с одинаковыми сигнатурами.
вот почему блин, зачем?
У меня например там есть претензия к рассказам что горутины почти бесплатны.
вот вот! моя претензия именно к тому что они тупо забили на описание технологии, которая еще и позволяет себе в ногу стрелять, из-за чего таких стреляющих толпы уже
но к слову, в голанге тоже самое можно устроить
Тут надо специально стараться. И проще ищется как не странно. Так-как ошибка явно везде передается.
т.е. надо ДВА раза ошибиться, не просто перепутать вызов, а еще и у класса интерфейс указать неправильно (а тут отвалятся уже штатные места использования этого класса)...и всёравно ниче работать не будет
Потому что это надуманная проблема. Нет такой проблемы в golang. Есть более общая проблема которая везде вылазит подсунули не ту реализацию. Но она и в java ловится легко.
вот почему блин, зачем?
А меньше рисков. Точнее интерфейс то завести вы можете но он будет идентичен.
вот вот! моя претензия именно к тому что они тупо забили на описание технологии, которая еще и позволяет себе в ногу стрелять, из-за чего таких стреляющих толпы уже
Это вопрос к литературе по факту. В базовом в целом написано нормально, но ожидается что люди все же имеют представление о многопоточном программировании. А так есть довольно неплохая книга Go: идиомы и паттерны проектирования она очень хорошо расписывает практически все. Там плохо описаны генерики, но это потому что на момент написания книги они еще не были частью языка.
(я описал образно, язык тут не важен)
давайте, расскажите мне что "программист должен следить сам за вызовами, а не компилятор или в рантайме валидатор типов"
В Го через утиную типизацию эмулируют полиморфизм... Такие вот принципы...
Для кого как. Лично для меня это огромный минус. Я на Go разрабатывал микросервисы в течении 1.5 года, попробовал его с разных сторон, но остался крайне недоволен его ограничениями. В особенности всегда бесило ограничение в форматировании, это просто нонсенс. Грубо говоря есть только один стиль написания кода под Go, и он официально принят (C/C++/JavaScript тут могут передать привет, потому что они почти с любым форматированием работают, а в C/C++ вообще можно создать свой собственный язык внутри этого языка на макросах). Всё остальное сопровождается предупреждениями компилятора или не компилируется.
Мой выбор это - C/C++, Kotlin, Rust, JavaScript / TypeScript, Python. С этими языками очень многое можно сделать. И они гораздо приятнее в использовании, чем Go (по моему личному ощущению). Впрочем, это больше дело вкуса. Мне нравится разбираться в глубинных темах программирования, а кому-то достаточно и поверхностных знаний да языка, наиболее подходящего под такой стиль программирования. Каждому своё.
... всегда бесило ограничение в форматировании ... Мой выбор это ... Python
Эммм. Настолько сомнительно, что даже странно.
В контексте форматирования он сам по себе не очень (с пробелами да табуляцией ещё нужно научиться дружить), а вот в целом по возможностям, он очень даже неплох. Помимо того, что там есть и библиотеки, сам язык оснащён богатыми инструкциями для выражения практически каких угодно высокоуровневых мыслей. Низкоуровневого там ничего конечно не напишешь, но связь с C++ ему позволяет спокойно работать и с WinAPI :)
На самом деле ограничения языка дают вызов. Но дизайн языка местами действительно не удачен
На самом деле ограничения языка дают вызов.
Только зачем его принимать, если есть более приятные альтернативы без всяких вызовов? Спокойно взял и написал сервис на Node.js, Nest.js, Django, Flask, Spring, Axum (и прочем) без всякой суеты. И вызовов языка принимать не нужно. Тем более, если говорить о Go, сам язык создавался именно с расчётом на то, что никакие вызовы программисту принимать не придётся. Пиши так, как все. Никаких фишек, никакой фантазии, никакого индивидуального вклада. Шаг влево / шаг вправо - не скомпилируется. Всё очень ограничено и сделано специально таким образом, чтобы программисты просто не смогли ошибиться при написании программ, вот и всё. Оттого они и выглядят очень однотипными (особенно REST API какие-нибудь). Для LLM какой-нибудь это не язык, а сказка. Хватит и гигабайт 30-50 наверное кода на Go, чтобы её обучить идеально на нём писать (а это, в контексте LLM, довольно мало).
Вызов это Brainfuck, Malbolge, или Assembler. Вот это вызов, а тут так... просто не удачный дизайн, принятый с целью избавить программистов от ошибок в рамках самого языка (или хотя бы их уменьшить).
Спокойно взял и написал сервис на Node.js, Nest.js, Django, Flask, Spring, Axum (и прочем) без всякой суеты.
У js еще больше ограничений :) Про python тоже все еще над ним витает GIL. В java тоже есть свои проблемы.
Тем более, если говорить о Go, сам язык создавался именно с расчётом на то, что никакие вызовы программисту принимать не придётся.
Ну тут классический выстрел в ногу. На golang никто не подразумевал что будут писать что-то сложное. А тут сложное начали писать и возникли проблемы.
Более менее просто бери и пиши с минимумом челленджа сейчас только java/spring там довольно много соломки подложено. В остальных все равно вы столкнетесь с проблемами. Проблемы golang ничуть не сложнее чем другие.
У js еще больше ограничений :)
Ну и каких же? :) В современных стандартах JavaScript возможностей полно. Конечно, браузерное API и серверные платформы по типу Node.js / Deno развиваются немного в разных направлениях, но всё же. В контексте серверной разработки у JavaScript возможностей для выражения тех или иных идей куда больше, чем в Go (ну или мне так показалось, потому что и с Go, и с JavaScript я довольно активно работал).
Про python тоже все еще над ним витает GIL
Советую взглянуть на новую версию Python. Там ввели очень революционную идею, которая помогает избежать GIL. Скоро его вообще уберут окончательно, и будет асинхронный и многопоточный код на Python летать :)
Проблемы golang ничуть не сложнее чем другие.
Согласен. Только для разработчиков самого языка программирования Go, а не программистов на нём :)
Там ввели очень революционную идею, которая помогает избежать GIL
Это которая сделала и без того медленный питон ещё на 5% медленнее в однопотоке? Ещё на всякий случай напомню, что asyncio фундаментально однопоточный
Убрать GIL в питоне сложная тема. Особенно если ты хочешь сохранить всю инфраструктуру и сделать еще threadsafe.
Это которая сделала и без того медленный питон ещё на 5% медленнее в однопотоке?
Вы где увидели, что Python стал медленнее на 5% в одном потоке? По ссылке я увидел только вот это, где говорится что с новым интерпретатором прирост в скорости 3-5% (для некоторых новых компиляторов):
A new type of interpreter has been added to CPython. It uses tail calls between small C functions that implement individual Python opcodes, rather than one large C
casestatement. For certain newer compilers, this interpreter provides significantly better performance. Preliminary benchmarks suggest a geometric mean of 3-5% faster on the standardpyperformancebenchmark suite, depending on platform and architecture. The baseline is Python 3.14 built with Clang 19, without this new interpreter.
Вот выжимка по этой же ссылке. Где тут торможение на 5% - непонятно.
Ещё на всякий случай напомню, что asyncio фундаментально однопоточный
И что? На всякий случай напомню, что асинхронное и параллельное программирование это фундаментально две разные вещи. Для выполнения асинхронных задач можно обойтись и одним потоком. Asyncio ранее вообще использовали генераторы, чтобы сделать свою модель асинхронного программирования. Они для этой цели считались наиболее подходящими. В каком-нибудь Arduino на Си тоже часто можно встретить подобную асинхронную модель, когда их нельзя использовать по тем или иным причинам.
Ну и каких же? :)
Самый простой пример это однопоточность js и реализация асихнронности в ней. await/async свежее изобретение. Писать без них та еще боль. Да и с ними там с особенностями. Тут даже больше боли чем ограничения в golang. Уж про общую неконсистентность js как языка я вообще молчу. К примеру то как в нем массивы организованы.
В контексте серверной разработки у JavaScript возможностей для выражения тех или иных идей куда больше, чем в Go
Очень громко смеялся. Особенно учитывая итоговую скорость и требования к ресурсам.
Советую взглянуть на новую версию Python. Там ввели очень революционную идею, которая помогает избежать GIL.
Еще громче засмеялся. Этой проблеме много лет но ее пока толком так и не решили.
Самый простой пример это однопоточность js и реализация асихнронности в ней. await/async свежее изобретение
Ну, это точно не "свежее изобретение". Конкретно async/await появились в JavaScript в 2017 году в стандарте ECMAScript 2017 (ES8), а до этого были промисы (Promises), которые и сейчас можно использовать для асинхронного кода без проблем.
То, что JavaScript однопоточен - не совсем правда. Однопоточна только среда, которая выполняет код на JavaScript, но не сам язык (Node.js, например). Если брать Node.js, то там вполне успешно можно создавать свои потоки через Worker Threads, а через браузерное API сделать тоже самое можно с помощью Web Workers. Т.е., возможность работы с потоками предоставляет платформа на которой JavaScript работает, но не сам язык.
Очень громко смеялся. Особенно учитывая итоговую скорость и требования к ресурсам.
Да-да, выполнение JavaScript в платформе Node.js реализовано не совсем оптимально и из-за этого есть проблемы со скоростью. Опять же, смотря какие библиотеки для создания приложений использовать. Но я и не предлагаю его каждый раз использовать для написания бэка (я сам для этой цели Rust использую), я говорю лишь о возможностях, которые JavaScript для этой задачи предоставляет. Попробуйте как-нибудь Nest.js, который очень похож местами на Spring, только в обёртке JavaScript.
А вообще, JavaScript вполне успешно используют для микросервисов многие IT-гиганты, и ничего - их сервисы не тормозят каждый раз, когда пользователь выполняет какое-то действие (тут мнения могут различаться).
Вы еще электрон вспомните, который к примеру основа того же vscode (кстати единственное приложение которое как-то адекватно на этой платформе работает).
В целом если уж смотреть на потребление ресурсов vs производительность java script такое. Какая-то популярность на backend ему обеспечивается исключительно большим числом кодеров.
Касательно потоков же в js ну это натуральное гамак и лыжи. В целом и можно но сильно не удобно.
Ну зато гораздо проще доверить работу нейронке, чем на других языках
Ох, я помню ребята из Wrike, когда сделали ставку не на победившую технологию, тоже начинали с таких статей. И пытались убедить всех, что нет, Dart тоже норм. Потом они начали делать целевой набор джунов, ибо с рынка найти не могли спецов, а потом все же перешлина TypeScript.
Вы главное потом не пугайтесь мысли, что если бы остались на PHP или Java - сэкономили бы кучу денег на ФОТе и разработке.
Ребята из Wrike смогли, и вы сможете.
Маркетологи Авито уже один раз перепутали Хабр с Инстаграмом, пришлось скрыть статью. Но жизнь ничему не учит.
PHP уже много лет хоронят, но он все еще жив и развивается. Теперь настала очередь Go?
Go - это не язык общего назначения. Это отличная базовая платформа для нагруженного сетевого сервиса и к ней язык для её сценариев. Целевое приложение работает так: получил запрос, валидировал, собрал данные с БД и других сервисов, скомпоновал, отдал, забыл. Независимо для сотен клиентов.
Чем дальше ваш проект отходит от этого шаблона, тем больше Go похож на попытку переодеть колготки, не снимая лыж.
И то, что Go в этом рейтинге опустился на девять позиций, означает лишь то, что язык стал привычен, удобен
Это значит в первую очередь то, что меньше людей стало его изучать.
Вместо того чтобы цитировать тиобе, лучше бы выкатили статку по количеству го-репозиториев внутри авито за последние пару лет. Вот это был бы реальный аргумент для обсуждения, а не гадание на кофейной гуще от техлида
Про смерть PHP шутили уже?
Golang прекрасен компиляцией в один бинарник сразу под нужную платформу. Для человека замученного npm i и pip -r все остальное уже неважно
А если завтра Go вообще пропадет из топов, эксперты скажут, что язык достиг нирваны и познал дзен?
Обычный корпоративный булшит, чтобы вакансии в блоге не выглядели протухшими
Go такой какой он и должен дать, написанный человеком который в отличие от авторов питона, js, и мен лих других поделок реально понимает что нужно в языке и что не нужно. Опять таки. Писался он под нужды Гугла, т.е. сетевая обработка/сервисы. То что ограничили ООП/Интерфецсы и Иде с ним это на баг а фича, народ нахватался черт знает чего и пишут сплошные dependency injections и invert of control, в итоге понять как работает промой сервис становится просто невозможным без прохождения по шагам в отладчике.
Про JS/node даже не смешно ….
Проблема в том что без DI и IOC вы не сможете писать и поддерживать большое приложение. А нормальных подходов в golang к этому не родили. Но постепенно язык начинает набирать зрелость. К примеру не так давно там даже банальная запись в лог представляла головную боль. Сейчас завезли slog стало прям сильно лучше.
А TypeScript, получается, - совсем всё?
И то, что Go в этом рейтинге опустился на девять позиций, означает лишь то, что язык стал привычен, удобен
Этот тезис требует доказательств
Почувствуйте себя пэхапэшником ))))
Golang — ВСЁ? Мнение эксперта