Comments 36
Мне казалось модель асинхронности легче для понимания и дебага, чем многопоточности. Не поэтому ли евент луп кто то в го потащил?
Первая ссылка на руководство ведёт на мануал 2014 года. Не надо так.
На мой взгляд есть куда более важный аргумент: Go разработчикам больше платят. Вот статистика по 2021 году:
https://habr.com/ru/article/649423/#rec407700951 (Россия, +33%)
https://insights.stackoverflow.com/survey/2021#section-salary-salary-and-experience-by-language (мир, +25%)
Аргумент, конечно, манипулятивный: Go разработчики в целом больше знают и умеют ввиду большей сложности задач и большей нагрузки на продакшен (и собеседования заметно хардкорнее), и по некоторым исследованиями сравнимые кандидаты мало отличаются по оплате.
Тем не менее, это работает как мотивация выбрать Go для разработчика, и как мотивация не выбирать Go для компании.
Думаю, для Python-разработчика проще перейти на Julia (а она умеет ещё и Python код выполнять через биндинги). А если вы рубист - то Crystal.
А теперь по пунктам. Есть немного критики
Производительность: а чем это отличается от следующего пункта?
Скорость языка имеет значение: давайте разделять задачи. В рамках web (для которого Golang получил наибольшее распространение) - есть два основных узких места. Это - база данных (тут Golang ничего не сделает) и обработка JSON (и тут он медленный). Так, что "+/-" у этого аргумента. И как ни смешно, для микросервисов, которые часто работают с JSON прекрасным выбором является NodeJS. Не хуже Aio у Python. Прекрасно показыают себя Julia и Crystal. Ну а такие стеки как Erlang, Elixir, Java, Haskell, Racket... да масса на самом деле... работает с данными узкими местами не хуже. Если говорить об оптимизации на низком уровне - лучше Pure C я пока ничего не встречал. Даже Rust просто даёт не защищённый режим, где вы можете сделать "быстро". Но тут да, вопрос где именно надо сделать быстро. Вполне возможно, что Golang в этой задачи легко "сольёт".
Продуктивность разработчиков и ограничение креативности: Код, который вы показали - выглядит отвратительно, это ИМХО. Большая часть тех, кто работал на Python, думаю, так же скажут. Ранние выходы, куча странных нотаций, своеобразный и многословный синтаксис. Про ограничения... за ними скорее в Rust. Если нужна "золотая середина", то я сказал бы DLang. Ну а на Python настроенный линтер и аннотации типов в целом решают проблему без смены языка.
Параллелизм и каналы: ничего нового, на самом деле. "Новизна" - скорее маркетинг. Легкие потоки давно есть в Erlang, Racket, etc. Асинхронщина - Promise и разные его аналоги есть уже очень давно. В Python есть инструменты, чуть сложнее синтаксически (хотя не на много), слабый аргумент для смены "рабочей лошадки". Уж тогда смотреть в сторону Julia, которая по синтаксису ближе к Python, но умеет все перечисленное и много всего сверху.
Быстрая компиляция: сомнительный плюс, интересен больше в dev-режиме (на проде - не так принципиально, но бывают случаи). Скорее интереснее REPL и горячая замена кода. Erlang и Lisp тут никто не превзошёл. Разве что рядом Julia (которая по сути - DSL над Lisp).
Возможность собрать команду: смотря какого уровня нужна. У Golang часто та же проблема, что и у Python - средний по больнице уровень кандидатов достаточно низкий. Про API и возможности язка - Golang в целом не принёс ни одной новой идеи. Это хороший энтерпрайзный язык, который делался под конкретные цели и экосистемы. И там он хорош, но за рамками них...Мало чем лучше Python, если мы не говорим о синтетических тестах или очень узких кейсах.
Сильная экосистема: сильнее, чем на NodeJS я не видел экосистемы (без шуток). Если честно. И уж тем более на Golang менять ради экосистемы, отказываться от Python - это бред. Та же Julia выстреливает в том числе потому, что она совместима с экосистемой "ползучего". Golang... стандартно, где-то даже ощутимо хуже. Ощущение как от Dart - если Google хотели так применять, то всё в целом "ок". Если нет - то в лучшем случае никак. И в чём тут аргумент против Python?
Gofmt, принудительное форматирование кода: а в Python форматирование является частью синтаксиса. А ещё есть куча инструментов, которые делают это в других экосистемах. А ещё есть IDE, которые из коробки это умеют. В общем - ещё один недоаргумент, который ещё раз подтверждает - оснований переходить с Python на Golang просто нет.
gRPC и буферы протокола: вообще слабый аргумент. Ещё одна ниша, которая нужна конкретно Google и затачивалась под их конкретные задачи. Тем более - gRPC умеет куча экосистем и стеков. Шутка ли - даже в древний Common Lisp находил реализации. Python - уж тем более не исключение. Про "плюсы" и "минусы" самого gRPC можно спорить очень долго. Скажу лишь пару аргументов "против" - фронт и gRPC лучше не дружить (приходится проксировать через Gateway и делать что-то REST-подобное на фасаде), тотальный вендорлок гугла. Ну а автогенерённый код... он и в Африке автогенерённый. Хотя да, на Golang это всё наиболее прозрачно (кстати, в Dart было не хуже, пока Google не замкнули язык на Flutter). Но ниша слишком узкая. Да и на Python не на много хуже обстоят дела.
Итого: не убедили. Из 8 причин - ни одной существенной.
А вот недостатки... давайте отдельно, тоже.
Отсутствие фреймворков: вот тут то, что я писал. Если Golang интересен в этой нише Google - будет инструмент, нет - не будет. В Web ещё не так всё плохо (есть зайчатки), а вот в каком-нибудь вопросе ORM/ODM для разных СУБД будет примерно так же как в Raku - пишешь сам, поддерживаешь сам.
Обработка ошибок: да нет её толком. Это сложная и ресурсоёмкая тема. И как правило - она усложняет инструмент. Golang проектировался, чтобы быть простым. Поэтому... просто плодим if, улыбаемся и машем (и после этого кто-то сетует на JS с его Callback/Promise Hell).
Управление пакетами: А ведь это важно. Особенно для enterprise. А почему нет? Правильно, все интересные пакеты Google будут мейнтейниться Google. И будет всё хорошо. А остальной рынок мало интересен для создателей Golang.
Бонусом уж совсем понесло.
Сравнение Golang и Elixir: а почему именно Elixir? А не сравнить с изначально более выигрышной NodeJS, не сравнить с простой, быстрой и понятной Julia. Не сравнить с элегантным и не уступающим ни в чём Crystal. Вы бы ещё с LFE сравнили. Или со Scala. Да, они подходят под "асинхронщину" и "параллельщину". Но явно рассчитанные на уровень в среднем выше, чем у среднего python-разработчика (ему просто много из ФП не нужно).
Итого по статье - спасибо, было интересно. Но эффект обратный. Вы скорее доказали, что Golang не стоит внимания, а сообщество его сторонников - не может аргументировать выбор инструмента (мало чем подкрепленные аргументы).
По моему опыту (несколько десятков разработчиков) у Go самый низкий порог входа: новичкам в языке (но минимум мидлам бэкенда) выдаётся задача на Go, и они с первого дня выдают деливери на уровне мидлов. tour.golang.org — великая вещь, которой не хватает многим языкам, как и простой документации по языку или стандартной библиотеке.
В целом, сравнивать промышенные и эзотерические языки имеет мало практического смысла — последние мало где получится использовать.
По пунктам, судя по аргументу про пакеты, это либо очень старая статья, либо автор не в теме. В Go важны другие вещи.
Экосистема. Go — редкое место, где можно спокойно апгрейдить зависимости большого проекта, и почти всегда это не портит работу приложения. По опыту разработки и менеджмента разработки — не хватает разве что больших фреймворков и универсальных ORM, но они не go way. Нет прекрасных проблем в духе миллиона версий питона и ноды
Понятная IDE система типов, вызовов, зависимостей итп. Можно быть уверенным, что поиск по функции (не по текстовому названию, именно по функции) найдёт все её использования, без какой-либо магии, и клик по параметру/функции найдёт именно её. Невозможна ситуация, когда из-за отсутствия (пустого init.py) файла приложение падает в (казалось бы) случайном месте.
Крутой инструментарий: в 1 строчку делается профайлинг прода (по CPU, памяти, горутинам, итп), отлов data race в 1 параметр, просто работающий дебаг, максимально простая система тестов и бенчмарков, максимально простой вылов протекающей памяти или горутин. Вылов data race — штука практически уникальная. К этому добавляется простая возможность оптимизаций вплоть до asm, засчёт чего производительность Go редко является проблемой.
Нет проблем со сборками: нет вечно падающих gyp зависимостей и прочих psycopg — в Go принято делать зависимости на чистом Go, а редкие биндинги к C-библиотекам без проблем собираются даже под другую ОС.
Обработка ошибок. Засчёт того, что разработчика принуждают обрабатывать ошибки, куда чаще они действительно обработаны.
Линейный код. В отличие от промисов и лямбда-программирования, код на Go обычно беглым взглядом прочитывается правильно.
Переносимость опыта. Go разработчик с рынка работал в той же экосистеме, с похожим до неразличимости code style, и в похожей по структуре кодовой базе => существенно короче онбординг.
Универсальность сериализации. В Go никогда нет проблемы «залогировать класс», не нужно изобретать сериализаторы полей итп — оно работает просто и предсказуемо.
Стабильность. Для Go нормально оставить крупное приложение на год без какой-либо поддержки, например перезапуска от медленно текущей памяти или моргнувшей сети.
Установка. Системная утилита на Go переносится 1 бинарником, без каких-либо зависимостей и проблем.
Результат хорошо виден: подавляющее количество опенсорсных системных утилит и сервисов (все эти докеры, кубернейтисы, прометеи, графаны, весь стек хешикорп и прочие кокроачи) пишутся на Go прямо с релиза. Т.е. в условиях чистой конкуренции Go уже победил конкурентов.
Недостатки, впрочем, тоже есть:
if err != nil вместо эксепшенов. Это замусоривает код, а решение пока в глубоком драфте. Зато мотивирует не делать излишне длинные функции, и обрабатывать пойманные ошибки (см. п.5), а эксепшены (паники) исп
Generic'и. Их долго не было, сейчас они весьма ограничены и не всегда удобны. Без них не получается приносить привычные из других языков паттерны, и некоторые библиотечные штуки вроде кастомных сетевых протоколов делать неудобно. С другой стороны, см. п.2 и п.6.
Фреймворки с огромным инструментарием типа админок. Это больно, аналога Django в Go нет и не предвидится. Кажется что для задач Django лучше использовать Django.
ORM. Они есть в урезанном виде без явного лидера. Это проблема, пока не появляются задачи собрать полноценный DDD со всеми агрегатами и value object'ами, или оптимизировать SQL запросы на 5 джойнов и window функцию.
А можете подсказать хорошие примеры про связку mux / websocket? Как если бы я хотел бы сделать свой динамический роутинг и подписывать на него клиентов. observer/subscriber
Про продакшен код за пару дней изучения - не удивительно. Именно такую задачу и ставил Google. Вернее, чтобы "даже питонисты могли быстро влиться и начать писать производительный код". Это делает Golang хорошим инструментом, но не хорошим языком.
Далее - Scala, Rust, Julia иди Crystal не эзотерические. Вполне себе инструменты. NodeJS тем более. Но сравнивают почему-то с Elixir. Niff said.
Про экосистему. Я уже писал, что она хороша там где была интересна Google. Найдите ODM для той же ArangoDB или Couchdb. А это вполне промышленный СУБД. И нет никакого в этом go way (в случае с Golang - это просто агитка, чтобы не писали сложного, инструмент не заточен), есть интерес основного инвестора. И именно поэтому почти всегда не портит - есть пакеты не интересные корпорации, а остальные - на свой страх и риск.
Про IDE, извините. Я настраивал 7 лет назад Emacs под Dlang, Python и NodeJS. Потом накрутил еще модули для Julia. Вопрос инструмента и рук.
Про init.py - скорее особенность и условие. Тут не хорошо и не плохо. Функция main у K&R тоже условность.
Про инструментарий вообще не в кассу. Julia - похоже. На Nodejs еще раньше сделали, чем Golang. Древний Common Lisp умеет очень многое (сложно найти чего нельзя сделать через снапшот). Дебаг легких потоков - Erlang. А так из промышленного удобный инструментарий и IDE - идеи Smalltalk никто не отменял. Другое дело, что порог входа инструментов - низкий. Правда их функциональность соответствует порогу входа.
Проблемы со сборками... Давайте не сравнивать Python , а возьмем Dlang или Rust. У них их тоже нет. И C они редко дергают. Иными словами - мало удивительного. Плюсы компилируемого языка. И минусы. Так как на С давно уже это написано, зачем велосипедить? Ну а так - если честно, я встречал проблемы с зависимостям. В Python только под Wondows. И были проблемы с установкой каких-то пакетов под форточкамит и в Golang. Хотя может за 4 года, что я не прикасался - что-то поменялось.
Ага. Видел я в продакшене обработку. Примерно на уровне Python'новского try/catch+pass. Если ошибка - упасть, если не ошибка - делать. Другая крайность if-hell с диким уровнем вложений. Без нормальной типизации и единой точки обработки. Ничем не лучше callback hell, лапша.
Линейный код никто не запрещает писать на Python, Erlang, JS (asunc/await, generators) и кучи других языков. Собственно не линейный код свойственный языкам где кроме вызова callbacks нет ничего. А таких уже почти нет. Про лямбды - for тоже лямбда). Ничего, живут с ней все.
Пункт 7 можно применить к любому языку. Вообще любому. Главное, чтобы команда применяла best practice и работала с code style. Говнокодить можно на любом языке. Что чаще всего и делают. А сказки переносимости опыта - идеальная ситуация, которой не будет скорее всего.
Универсальность сериализации есть в любом языке, который проповедует "код есть данные". На Lisp 1 еще. В ФП не сложнее, как и в ООП. Чуть побольше пары строк, но не rocket science . Smalltalk, Julia, Ruby...примеров можно найти при желании много. Даже древний TCL позволял (своими руками такое делал). Но может не понял задачу какую имеете ввиду.
Стабильность - Erlang, CL, Racket, Clojure, Scala, Haskell...да даже Nodejs (мой сервис работал один несколько лет без передёргивания), ну в самом деле. Тут ничего нового. Erlang тот же в целом идеал на счет стабильности - что-то стало работать не так, пристрели и заспавни. Ну а GC вполне себе защищает от утечек (тут опять Go ничего не привнес). И тут можно вспомнить еще и тот же D (все было еще в нем + гора сверху). Или даже Rust с его подходом из современных.
Установка... А тут что нового? Тонны языков с бородатых лет. С современных тоже хватает. Тоже ничего нового. Либо я не так вас понял. Но, банально - даже на Racket я могу всю VM упаковать, со всеми либами. У мейнстримных языков это тоже давно есть.
А недостатки...
Да, согласен - исключений нормальных нет. Видимо и не будет. В XXI веке смотреть на это больно.
Дженериков таких лучше бы не было (судя по спеке). Ситуация напоминает лямбды в Python.
Про фреймворки - лозунги рекламы, они нужны. В том числе и "жирные". То, что их нет скорее показатель ниши и сложности сделать из на Go.
Про ORM/ODM - мир СУБД не ограничен PGSQL и еще парой реляционных баз. И язык запросов - не только SQL. СУБД много. И ORM хорошо подходят под микросервисы, позволяют работать с высоким уровнем абстракций. Там где нужно лопатить терабайты данных Go мало что может предложить (Julia, R и Fortran он не замени ), нет нужных инструментов тоже. Вот и получается - как все на Golang. Примитивные решения для небольших вещей.
Итог - Golang стал популярным благодаря маркетингу. У него нет приемуществ кроме предельно низкого порога входа (правда в D он не выше в тех же границах использования) и заточенности под определенные задачи (gRPC , частично network).
З. Ы.: писал как на Python, так и на Golang. И даже в пьяном угаре не стал бы советовать последний.
Далее - Scala, Rust, Julia иди Crystal не эзотерические. Вполне себе инструменты. NodeJS тем более. Но сравнивают почему-то с Elixir. Niff said.
У вас какая-то предвзятость к Elixir)
Конкретно для веб-разработки он всё-таки популярнее Rust и уж тем более популярнее Scala, Julia и Crystal. Посмотрите хотя бы на те же звёздочки на Github для самых популярных веб-фреймворков на этих языках. А по опросу StackOverflow Phoenix вообще 1-е место в списке most loved фреймворков занял в этом году. Да и сам Elixir занял 2-е место после Rust в списке most loved языков.
Ничего не имею против Elixir. Более того могу сказать, он мне нравится.
Я имел ввиду то, что берётся для сравнения в статье изначально более требовательный к погружению стек. Всё же вхождение в Erlang-окружение (а у Elixir много инструментов и подходов от "родителя") сложнее, чем JVM или NodeJS. Но да, Elixir не корректно "выбрасывать" из сравнения. Это язык, который на порядок лучше Golang и он вполне себе хорошая альтернатива для миграции с Ruby/Python.
Про Rust... это специфичный инструмент. Я не могу сказать, что он плохой. Он как раз требовательный, сложный и функциональный. Кстати, уж если заговорили про него - его экосистема ничуть не хуже Golang, а местами даже куда лучше. И если уж сравнивать компилируемые языки между собой - то оставить без внимания его было бы не верно. Как не верно и "забыть" сравнивать Golang с Dlang, который умеет всё то же самое, что и первый и ещё сверху много приятного (нормальные ошибки, дженерики, шаблоны, etc.). Последний, кстати, не на много сложнее изучить, чем Golang. В том числе за счёт достаточно простого и понятного синтаксиса.
За ссылку на рейтинг спасибо, как раз хотел посмотреть каков тренд и менялся ли).
А можете сказать что-то про Nim, а то его там выше рекомендуют.
Очень интенсивно недавно развивался, потом как-то затухло.
Мало с ним поработал. Так, для пары простых микросервисов заюзал. Не могу ничего плохого сказать - это один из череды "простых и производительных" языков, вроде Julia, Crystal, Elixir и им подобных. Чаще всего видел их позиционирование как "работа над ошибками Python/Ruby/$LanguageName". Но тут, думаю, проблемой стало позиционирование - Crystal и Elixir взяли такой хороший курс на Web, Julia пытается прижиться в наших ML и числодробилок...
А вот куда Nim приложить предлагают, я так и не смог понять. Были, на сколько помню, потуги его затащить в gamedev, но вроде как не взлетело (хотя могу ошибаться).
Как альтернатива Python... а зачем, если есть Julia? Последнее время она и в web стала хорошо уметь (прекрасный фреймворк Genie уже до 5 версии обновили), имеет свои notebooks (Pluto.jl) для датасаентистов и т.п. Плюс из неё можно делать вызовы Python-кода.
Любой язык, чтобы стать успешным, должен быть инструментом конкретной ниши, для конкретной ЦА. Надеюсь Nim найдёт своих пользователей. Язык то очень даже не плохой.
Виталик, привет!
Ждал тебя увидеть в треде. :) Как раз вспоминал твой доклад на Moscow Python Conf - https://www.youtube.com/watch?v=a8oEETIRpCk
Если говорить об оптимизации на низком уровне - лучше Pure C я пока ничего не встречал. Даже Rust просто даёт не защищённый режим, где вы можете сделать "быстро".
Тут ещё важный аспект, что либу на C или на Rust легко можно подключить почти к любому популярному ЯП через NIF или FFI. С Go такое не прокатит.
Сравнение Golang и Elixir: а почему именно Elixir?
Я, кстати, в 2015 году тоже именно такое сравнение устраивал. В моём сравнении победил Elixir, для веб-разработки он подходит гораздо лучше, чем Go. А за счёт применения возможностей OTP ещё и в скорости его обходит на большинстве практических задач. Веб-разработка она де-факто про ФП, и то что на неё под влиянием моды натянули ООП в стиле GUI-программ - это, пожалуй, один из самых больших косяков во всей этой отрасли. Пол Грэм ещё 20 лет назад всё объяснил, но большинство до сих пор отказывают себе в быстрой веб-разработке. Кстати, Elixir по сути своей является диалектом Lisp, и весь его синтаксис ничто иное, как DSL на этом лиспе написанный.
Насчёт Julia ничего не могу сказать. Не видел пока, чтобы её кто-то именно для веб-разработки использовал. А Crystal пока сыроват в плане конкурентности и параллелизма. Насколько мне известно, пока нет способа сделать так, чтобы программа на нём использовала, допустим, все 8 ядер процессора и нигде не сбоила.
Спасибо за содержательный комментарий!
Про Julia, кстати, был интересный доклад на нашей конференции: https://www.youtube.com/watch?v=REVmhiJ1Zi8
Есть также расшифровка на Хабре, если кому-то так удобней: https://habr.com/ru/company/oleg-bunin/blog/476114/
Производительность
Если вы упираетесь в производительность, то используют fasthttp и easyjson, но просто так не нужно их использовать.
Gofmt, принудительное форматирование кода
Тут возможно холиварная тема, но иногда приходится писать небольшие скрипты для питона, и если по какой-то причине я открываю питоновский файл в простом редакторе и копирую туда код, то приходится тратить время на отладку, в го я могу вставить код и если он криво скопируется, то я просто использую эту утилиту, но тут вопросы о вкусах.
Обработка ошибок:
Тоже холиварный момент, в целом вы можете сделать что-то типа исключений, но так стоит делать в редких случаях. В целом если вы углубитесь в этот вопрос, то узнаете, что в ряде языков, использование исключений довольно ограничено. В питоне они используются из-за того, что они легковесные и по сути это стандартный способ обработки ошибок. Например плюсовом коде чаще используется похожий способ для обработки ошибок, только там обычно проверяют nullptr. Но это опять же вещи
Быстрая компиляция:
Это не то чтобы плюс, больше приятный бонус, возможно вы не сталкивались с реально медленной компиляцией, поэтому для вас это кажется мелочью.
Параллелизм и каналы:
Тут скорее дело в том, что это реально просто использовать, есть готовые паттерны и куча их реализаций, также большой плюс в том, что есть еще утилита из коробки для обнаружения проблем.
P.S. Постоянно в комментах к таким статьям пишут про Julia, Crystal, Elixir, D, но проблема в том, что вакансий на эти языки почти нет или они идут в пунктах "хорошо если вы знакомы с ...", так что в каком-то плане они могут быть лучше, но в реальности на них слишком мало пишут.
Ох, в интернете опять кто-то не прав)
Вы сейчас серьезно написали о производительности??? Никоим образом не являюсь фанатом go, но он значительно (десятки раз) быстрее python в веб в том числе. И немного быстрее nodejs, сильно обгоняя последний по показателю memory footprint. При всех недостатках и болячках go, в своей нише он очень хорош.
Про json тоже непонятно… Вам мало скорости годного сериализатора? Используйте кастомные библиотеки, и будем вам ультраскорость (https://github.com/goccy/go-json)
Написанное выше основано на моём скромном опыте написания сервисов, прокачивающих терабайты json в месяц. Был вынужден мигрировать на go. Никакие извращения с fastapi и orjson не позволяют из питона выжать больше go и близко. Я уже молчу о том, что будет, если использовать так называемый быстрый fastapi as is, строго следуя документации.
Ещё раз повторюсь - не фанатик golang, и для меня python всё ещё очень приятный язык. Но и у него есть своя ниша и проблемы проектирования (самого языка), которые решают до сих пор.
По теме статьи, извините, но это не причины для перевода команды с го на питон, а весьма странные, кхм, рассуждения… Спорить с автором статьи лень. Извините, если кого-то обидел.
Python идет странным путем развития и не могу сказать что понимаю в чем смысл некоторых "нововедений".Если бегло то парадигма читаемости кода -- это ключевое, но от нее объективно уходят, (привет моржи). Go наверное интересен в первую очередь простотой сборки, надежностью запуска(независимые приложения не тянущие за собой тонны зависимостей, которые не всегда ведут себя адекватно), независимость запуска от С++, которая иногда вызывает проблемы поведения в питоне.
А вот с отрицательными вещами все тоже хорошо, дайте аналог numpy/scipy библиотек машинного обучения итп да и готовых бибилотек для развертывания сервера на коленке.
Но на мой взгляд Go идет верной дорогой, но для себя использовать пока не могу, хотя и очень бы хотел, сильно не туда повернул Python, простота не довела его до хорошего контингента.
Неплохая статья, хороший перевод. Хочется привести две причины, с точки зрения мало просвещённого читателя, разумеется, не переходить на Go. Но кому? Автор далеко, переводчик демонстративно лишь переводчик… Был бы раздел «от переводчика» - может и приводить ничего не пришлось бы.
Причина 1. Python удобно использовать вместо калькулятора.
Причина 2. Python позволяет, по крайней мере пока, обойти без использования виртуальной машины ограничения W^X политики на мобильных устройствах.
Зависит от задач. На Питоне писали довольно много инфраструктурной обвязки; теперь переписывают Go.
Или, как пример из моего хобби.
Раньше был игровой сервер на Питоне, сейчас переписываю на Go. Страдаю, правда :)
Ну уж для хобби-проекта переписали бы на Nim. К чему эти страдания с Go? :)
Освоить новый для себя ЯП; сэкономить на ресурсах - потому что текущая реализация больше 40 человек онлайна не держит. Ну и идея с корутинами тоже манит - у меня там есть, что в них закинуть. Плюсом - быстрая сборка в один бинарник без зависимостей. После определенного момента подготовка окружения для крупных Питон проектов стали раздражать проблемой с зависимостями, когда разные зависимости требуют одного пакета, но разных версий.
Вопрос был в том, почему не Nim? Он с вашими задачами тоже справился бы, но больше на Python похож и лишён многих недостатков Go.
Честно, я не рассматривал его на тот момент.
Откинул Java, C# (dotnet core), и в общем-то оказалось, что других относительно мейнстримовых языков для игрового сервера я и назвать не могу. Rust, C, C++ были откинуты по причине их относительной хардкорности.
При откидывании языков под JVM и .NET действительно остаётся не так много из относительно мейнстримовых (я определяю по наличию веб-фреймворка с кол-вом звёзд более 10k):
Elixir, Go, NodeJS - которые под вашу задачу подходят.
Ну и знаменитая троица PHP, Python, Ruby, которые для игрового сервера не особо подходят.
Golang как замена Pure C и C++ не взлетел.
Для использования вместо Pure C - надо выкидывать GC и как-то давать интерфейс работы с памятью. Это сложно и противоречит изначальной цели Go - быть простым.
Для использования вместо С++ - не гибокий, мало возможностей (в том числе работы с памятью) и слабая реализация элементов ООП.
Плюс конского размера бинари и невозможность использовать через какой-нибудь FFI.
А вот как альтернатива Python и подобным языкам для того, чтобы плодить web - вполне себе альтернатива, если нужна асинхронщина а в NodeJS не хочется, а в Erlang не можется.
Безусловно, экосистема Go ... с большим отрывом выигрывает у языков поновее, типа Rust или Elixir.
А какие-то доказательства будут или так просто вбросили?
Что Rust, что Elixir изначально имеют качественный тулинг и экосистема у них достаточно сфокусированная. А Go первые лет 10 страдал фигнёй, когда каждый изобретал свой велосипед для любой задачи, будь то управление зависимостями или работа с Redis. Хуже экосистемы я, честно говоря, не встречал. Потому что при поиске либы под любую популярную задачу у тебя будет минимум 5 примерно одинаковых вариантов, из которых хз как выбирать. И что бы ты ни выбрал, через 3-4 года это скорее всего будет deprecated.
"Go — быстрый. Очень быстрый! По скорости его можно сравнить с Java или C++. В нашем сценарии использования Go обычно в 40 раз быстрее Python. Вот небольшая игра-бенчмарк, в которой сравниваются " - это почти любой язык быстрее Питона начиная от школьного Паскаля и кончая всем. Если бы быстрота была в 100% случаев критична, Питон бы вообще не возник. Тем более хороший питонист умеет пользоваться библиотеками, которых вполне себе производительны.
Не могу быть объективен полностью, как человек который искренне любит Python, но также использую Go в проде, поэтому могу сравнить.
Надо сказать, что аргументы выше уже были разобраны подробнее, чем у меня.
Интересно, что уже первый пункт автора, Производительность, не имеет смысл без второго Скорость языка имеет значение, потому что производительность не требуется, если скорость не важна. А скорости Python вполне хватает даже для относительно нагруженных веб-приложений. Ещё есть PyPy, правда не очень применимо для веба.
Продуктивность разработчиков и ограничение креативности. Мне кажется, что простота сама по себе не является преимуществом. Сложно придумать что-то более простое, чем ассемблер (по крайней мере, основные команды), но на нём редко разрабатывают веб-приложения. Если посмотреть на Go, то это чуство меня не покидает. Обработка ошибок это одно из первых, что увидят новички. Лично меня это оттолкнуло. Дженерики появились в 1.18. Система типов есть, но везде и всюду будет interface{}. И в Python есть опциональные аннотации типов и mypy для их проверки
Параллелизм и каналы. В Python есть asyncio, который для типичных сценариев проще каналов.
Быстрая компиляция. А в Python компиляции как таковой нет вовсе, если сравнение с ним.
Сильная экосистема. Не все инструменты я видел, но мне экосистема Python кажется значительно более взрослой. Если сравнивать инструменты сходной популярности, то в Python будет больше функционала.
Gofmt, принудительное форматирование кода. Мне кажется довольно занятным, что проверку на длину строк gofmt не делает, поэтому в экосистеме есть golines, постформаттер для этого. Для Python форматтеров много, например, black.
gRPC и буферы протокола, это просто протокол. Каких-то значимых преимуществ у Go тут нет, но он может подходить лучше.
Мне также кажется, что причин выбирать один язык вместо другого не так уж и много. Вариант писать всё на Python, а часть на Golang вполне рабочий. И для большинства так будет лучше т.к. программистов на Python искать проще, а необходимости переписывания на Golang может и не появиться. А даже если и появится, то программист Python вполне способен разобраться в небольшом сервисе/микросервисе на Golang.
Java как эталон скорости - ну и ну
Написание этого же кода на Go заняло примерно 4 дня. Дополнительные оптимизации не потребовались. Хотя поначалу разработка на Python шла быстрее, с Go было гораздо меньше возни. Плюсом с Go мы получили более высокую скорость работы кода — в 40 раз быстрее, чем высокооптимизированный код на Python.
Ваша задача должна занимать хотя бы 36 минут времени чтобы как-нибудь оправдать Go вместо Python.
А учитывая что
на Go мы писали уже после того, как написали код на Python, поэтому я лучше понимал сценарий использования;
ясно что эта оценка сильно занижена.
эта статья - очередное подтверждение того что go сейчас это как php 15 лет назад
а rust - как питон :-D
комьюнити python сейчас в 2k22 тоже превратилось в мусорку, слишком много треша вокруг
по факту сравнивать голый python и go по скорости - дурацкая затея. Для питона это нормально взять си и наваять модуль. Ну или сейчас взять rust и наваять модуль. Для go тоже можно, но гошный рантайм делает это уже не таким простым и красивым, по факту проще оффлоадить логику в отдельный процесс и общаться с ним да хоть через шареную память.
что в go действительно круто - это то что он обрубает руки всем желатилям натворить "эдакое", но при этом изза этого в публичных библиотеках тут и там видно кривой косой и "когда-нибудь выстрелит" unsafe код. Не везде, но встречается.
любой ЯП это средство. Суперпро на python сделает приложение лучше-быстрее-стабильнее-выберисвоё чем только что вошедший в мир программирования студент на go.
сейчас в 2k22 действительно демоны писать на python идея плохая, go тут подходит лучше. Но причины совсем иные.
но всем советую покопаться в rust и не просто почитать а попробовать пописать чего-нибудь. Это действительно заставляет думать о проблемах, которые что python что go просто запихивают под ковёр. Если вы знаете как это работает - этим проще управлять.
9 причин перейти с Python на Go