Комментарии 52
Go — быстрый. Очень и очень быстрый. Его производительность близка к Java или C++.
Вот прямо взоржал тут. Не видел ни одного быстрого продукта на Java. Да, на каких то очень синтетических тестах возможно жаба и быстрая, после вычета времени старта и "прогрева" JIT-костылей. Но реальные продукты - это, как правило, дико медленный запуск и выжирание всех ресурсов в процессе работы.
о Java говорят конечно не в контексте десктопных приложений, говоря о производительности.
Да я и на бэке видел замечательные примеры вроде "запуск занимает 10-15 минут, создается 100500 потоков, системные требования - 32 Гб RAM, какой-нибудь Xeon на 20 ядер", все, что система делает, - парсит XML/JSON/ISO8583, собирает похожее сообщение и пересылает дальше + кладет в базу данные по операции.
Не видел ни одного быстрого продукта на Java.
Тем временем Apache Kafka, без которой не обходится ни один высоконагруженный проект, системы типа Apache Flink, в реалтайме прожёвывающие поток данных Twitter'а, упомянутые в статье биржевые системы, обрабатывающие по два миллиона транзакций в секунду - это всё работает на JVM.
Но реальные продукты - это, как правило, дико медленный запуск и выжирание всех ресурсов в процессе работы.
Да я и на бэке видел замечательные примеры вроде "запуск занимает 10-15 минут, создается 100500 потоков, системные требования - 32 Гб RAM, какой-нибудь Xeon на 20 ядер", все, что система делает, - парсит XML/JSON/ISO8583, собирает похожее сообщение и пересылает дальше + кладет в базу данные по операции.
А я вижу замечательные примеры, как микросервис примерно 40 000 раз в секунду парсит JSON, кладёт в БД одни данные, забирает другие, собирает новый JSON, отправляет его и при этом потребляет 512 Mb оперативы.
Каждому java-"микросервису", поди, своя java-машина нужна?
А так, да, проблемы производительности java-приложений решаются покупкой железа, купив парочку датацентров можно и нагрузку Twitter обработать...
Думаю, что там везде применяются "анти-джавовские" паттерны, такие как имплемнтация реюзабельных (mutable) строк, работа без сборщика мусора и т.д.
Spring Reactor, Akka или Netty позволяют добиться очень высоких показателей без какого либо тюнинга сборки мусора или ухищрений со стороны кода. В LMAX своё детище Disruptor используют с отключенным сборщиком мусора, но и без этого он показывает очень хорошие результаты. В код Kafka каждый может заглянуть, вполне себе идиоматичная Scala без хаков.
Статья должна была закончиться
Короче - потому что модно
Go — быстрый. Очень и очень быстрый. Его производительность близка к Java [сегодня используется на финансовом рынке для высокочастотного трейдинга — торговли на большой скорости — прим. ред.]
Называть быстрым язык, работающий через виртуальную машину, можно, разве что, в сравнении с Python... Она же ресурсы жрёт жуть :) Java в производительности очень уступает C/C++/Rust.
Python позволяет импровизировать с кодом, который вы пишете. <...> Но написанный другими людьми код порой сложно понять
Верю, что автор статьи не просто так это пишет, но согласиться не могу. По дзену Python, явное лучше неявного и всегда нужно стараться использовать один общий подход для решения задач. Это как раз позволяет легко читать чужой код. Если в команде все "импровизируют", то это уже проблема в людях.
Лично для меня Go располагается где-то посередине между Rust и Python. Хороший, по идее, вариант, если нужно выбрать какой-то один язык для бэкенда. Но для себя решил не отказываться от Python, а плюсом изучить системный Rust.
PS: Решили в Go вопрос с дженериками? Нужны они, в итоге, или не нужны? :)
PS: Решили в Go вопрос с дженериками? Нужны они, в итоге, или не нужны? :)
Они теперь есть :) Нужны или нет - сами думайте :)
PS: Решили в Go вопрос с дженериками? Нужны они, в итоге, или не нужны? :)
Да, их сделали. Но чуть после этой статьи в другом техноблоге вышел материал, где автор предупреждает и показывает, как дженерики Go могут замедлить код. Так что, как всегда, верно "не плодить сущности без необходимости". Я это понимаю как вопрос удобства переезда с С++ — чисто психологический. Авторы решили "просто сделать это", чтобы закрыть вопрос и как-то конкурировать с плюсами.
В Go нет виртуальной машины.
Называть быстрым язык, работающий через виртуальную машину, можно, разве
что, в сравнении с Python... Она же ресурсы жрёт жуть :) Java в
производительности очень уступает C/C++/Rust.
Если что, C++ "работает" через такую же виртуальную машину. В любом современном компиляторе вначале порождается IR (при том и не один), а потом из него генерируется нативный код. Java отличается тем, что библиотеки и приложения распространяются не в виде нативных бинарников, а в виде этого самого сериализованного IR. И преобразование IR в нативный код просходит при запуске приложения. Да, это требует каких-то ресурсов, поэтому на старте приложение Java дико тормозит. Но есть и AOT-компиляторы Java, в том числе от самих Oracle появился официальный сравнительно недавно. А что касается GC, который обвиняют во всех бедах. Как раз в плане пропускной способности GC делает всяческие jemalloc, в чём он проигрывает, так это в предсказуемости пауз. Конечно, за счёт возможности ручного доступа к памяти и возможности вообще не пользоватся аллокаторами, в ряде задач, если у разработчика прямые руки, то на C/C++/Rust можно написать гораздо более производительный код. Но в среднем на типовых задачах Java примерно по производительности им соответствует.
Про AOT-компиляторы не в знал. Если смотреть тут, то в сравнении с C++ почти во всех тестах Java потребляет прям намного больше памяти. Тесты, конечно, синтетические, но всё же...
Тем временем Python 3.11 beta показывает увеличение производительности до 60%.
А я, а у меня.. у меня net7 в два раза быстрее go)
Это намек на то, что никто никогда не конкретизирует, в каком именно контексте появился импрув. Ну не может язык/фреймворк стать быстрее целиком. Всегда за подобным байтом кроется улучшение пары каких-то нишевых фич, но это не делает погоды всему сообществу.
Это просто результат работы описанный тут https://habr.com/ru/post/662087/
Python использовался для высоконагруженных API?
Instagram? Disqus? Достаточно высоконагружены?
если они используют питон, то мне их жаль
Вот у нас есть какой-то код, допустим, он получает некие данные и сериализует их в JSON. И у нас есть две имплементации - на Си и на чистом питоне. И, скажем, код на Си работает в 100 раз быстрее. Очевидно преимущество Си. Но это пока мы не начнем применять этот код на практике. Когда приложение 50 миллисекунд ковыряется в БД, потом сериализует ответ в JSON и отправляет на клиент, то вообще не важно займет сериализация 0.1 миллисекунду или целую миллисекунду, потому что узкое место - СУБД, и заменив питон на Си вы не получите 100-кратное увеличение производительности, вы получите только около 1,5%
Ну так давайте NGINX напишем на питоне, все равно же узкое место - БД. Но почему то он написан на С.
Кстати, БД тоже можно написать на питоне, раз уж такая пьянка )
этими 0,9 мс можно пренебречь если ваш код в день использует 3,5 землекопа, если их на порядки больше, то помимо графиков нагрузки в системах мониторинга эти "только около 1,5%" еще и на толщину вашего кошелька вполне себе повлияют.
Для "высоконагруженных API" надо использовать не Python, Go или Java, а правильную архитектуру с горизонтальным скалированием и балансировщиком нагрузки.
Go, как и любой язык, стремится к простоте.
Чтоо?? Если сравнить абсолютно любой язык язык версии 1.0 с текущей, то это быстрое движение в сторону сложности.
Да, вы правы, если сложностью считать количество синтаксических конструкций. Но любой язык со временем обрастает синтаксическим сахаром, призванным упрощать код. Поэтому в каком-то смысле сложность растёт, а в каком-то падает. И любой лингвист вам скажет, что языки упрощаются. Так ЭВМ превратилась в "комп".
Осуждаю ленивых переводчиков, которые вместо того, чтобы скопировать код из оригинальной статьи и выложить его текстом на Хабре, поддерживающем подсветку синтаксиса, попросту сделали скриншоты кода из оригинальной статьи, да ещё и маленькие.
Размер скринов мы поправили. Спасибо, что заметили.
Если вы присмотритесь к оригиналу, то увидите, что там тоже используются скрины (причём именно того размера, который был у нас до замены), то есть кода, который можно было бы скопировать, просто нет. Видимо, автор сделал скрины из-за приватности репозитория: ссылки на gist тоже не работают.
Мы заметили, что, по сравнению с другими языками программирования, гораздо проще собрать команду разработчиков на Go
Мне кажется здесь нужно делать обязательное дополнение, для российских работодателей, что в отличие от западной культуры, где программист языка x, в первую очередь программист, у нас он в первую очередь специалист на языке x. И я слышал совершенно противоположное мнение от рекрутеров - что программистов на го очень тяжело найти.
Ещё одна проблема — можно случайно забыть обработать ошибку
Это как еще? Чтобы проигнорировать ошибку нужно специально написать:
result, _ := func()
Где _ и будет обозначением игнорирования второго элемента (последним в го всегда возвращается ошибка).
Концепция го в плане ошибок как раз нацелена на то, чтобы ошибка была обработана сразу. А не оставлена на "потом где-то в другом месте исключение обработается"
менять местами True и False;
Что имелось в виду?
Что такое буферы протокола?
У go из плюсов перед питоном будет, разве что, типизация и скорость, а перед джавой - чуть менее многословный синтаксис.
Дженерики добавили - и на том спасибо.
Мы регулярно сталкивались с проблемами производительности, когда Cassandra получала данные за 1 мс, а следующие 10 мс Python тратил на превращение их в объекты.
Не люблю Python, но даже там можно было бы использовать простые хеши, не превращая их в объекты. Переходить на ЯП без объектов для этого было необязательно))
Почему мы перешли с Python на Go