В каких приложениях Go существенно эффективнее чем Node.js и PHP?

Question

[tushev]

Я заинтересовался освоением языка Golang. Мое первое впечатление было что Go должен показать намного большую производительность чем Node.js и PHP, по следующим причинам: Язык компилируемый, строгая типизация, весьма похож на C, а следовательно должно быть мало накладных расходов как у его коллег Node.js и PHP, встроенная легковесная многозадачность. В статьях постоянно пишут что Go идеален для написания всяких высокопроизводительных веб-сервисов. Однако, капнув чуть глубже, я нашел много статей с бенчмарками, в которых Go не показывает какого то супер превосходства по производительности по сравнению с тем же Node.js.
Про PHP тут понятно, что классический PHP работает по схеме запрос-перезапуск_скрипта-ответ-умер и это не супер эффективно, но есть ведь всякие ассинхронные решения на PHP, которые работают с практически как Node.js c event-loop.
С другой стороны, Go сложнее при написании небольших сервисов чем тот же Node.js и PHP, хотябы в силу своей жесткой типизации и непривычного большинству разработчикам специфического-ООП.
Но если Go не дает какого то колоссального преимущества, то почему сейчас такой большой спрос на разработчиков Go и одни из самых высоких зарплат на этом языке? Почему крупные компании пытаются переделать свои решения с PHP на Go? Вроде как намного проще использовать разработчиков на PHP и Node, которых полно на рынке, чем искать редких и дорогих Go-разработчиков.

Comments

[12rbah]

tushev, в mail.ru говорили, что раньше узкие места переписывали на C, что было для них довольно тяжело, сейчас используют для этого go, т.к. разработка на нем проще и он достаточно производительный.

Answer 1

[Евгений Мамонов]

Бенчмарки - это хорошо, но очень важно понимать что именно там меряли и почему результаты именно такие.

Несколько лет назад я тоже делал бенчмарки Python, PHP, Node, Go.
Для меня были важны две вещи:
1 - скорость ответа сервера/кол-во запросов в секунду
2 - объём сервиса в памяти, т.к. от этого зависит стоимость ресурсов

На тесте, где сервисы не делали запросы в базу - из всех четверых лучше всего отработал Go с приличным отрывом, цифры, к сожалению, уже не помню.

Но вся эта разница сошла на нет, как только добавился всего один простой SQL запрос в базу, в таблицу с 10 строками. И на этом фоне разница по скорости ответа была меньше 10%.

Иными словами если ваш сервис работает с базой - критической разницы по скорости работы между Go/Rust/PHP/Node/Java, особо не будет.

Другое дело если ваш сервис не будет делать запросы в базу, или будет кешировать результаты запросов, тогда вы почувствуете ощутимую разницу.

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

Один экземпляр Go занимал в памяти порядка 6мб RAM, при том, что Pytho+Django порядка 60мб.
Node уже не помню сколько, но что-то близкое к Python'у.

Вот тут уже, когда серверов у вас будет много - количество серверов с Go у вас будет в 10 раз меньше, соответственно расходы за эти сервера у вас будут в 10 раз меньше :)

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

Где-то читал статью, что у людей было API на порядка 40 серверов на Node, после переписывания на Go - серверов осталось два, из которых второй запасной :)

Comments

[tushev]

Но вся эта разница сошла на нет, как только добавился всего один простой SQL запрос в базу, в таблицу с 10 строками.

А ведь 99% всех веб-сервисов это именно работа с БД. Получается что выгода будет только при низкоуровненой реализации каких нибудь заумных алгоритмов для работы с большим объемом данных и вычислениями.

Один экземпляр Go занимал в памяти порядка 6мб RAM, при том, что Pytho+Django порядка 60мб.

Что 6МБ, что 60МБ - разница небольшая если инстанс один. Даже если инстансов сделать по числу ядер, тоже не много получится. Пустяки по нынешним временам. Дополнительный расход памяти будет только на создание временных переменных при обработке запросов, но эти расходы будут в любом из языков.

[Евгений Мамонов]

Go реально хорош там, где начинаются большие нагрузки, микросервисы, CLI утилиты.

[Евгений Самсонов]

Если сравнивать Go и PHP, то даже с запросами в БД Go будет быстрее, так как сможет принять больше запросов и лучше нагрузить базу данных. А PHP отправив запрос в БД будет простаивать, ожидая ответа. Go из коробки работает асинхронно. В PHP, конечно, тоже можно этого добиться, но нужно будет использовать EventLoop и асинхронную работу с вводом выводом

[Dimonchik]

Что 6МБ, что 60МБ - разница небольшая

:D :D :D

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

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

прол работу с БД вывод в корне не верен, Go эффективнее примерно в сто раз, если, конечно, структуры, пул и т.п. корректно использовать

[Евгений Мамонов]

Есть еще момент, который стоит учитывать - это размер самих данных.
В своё время для меня это был разрыв шаблонов :)

Например в питоне int занимает 24 байта, а казалось бы, что int64 должен занимать 8 байт :))

https://code.tutsplus.com/tutorials/understand-how...

Это получается из-за того, что в питоне всё класс, т.е. имеем доп. расходы на RAM.
Соответственно для хранения интов питону понадобится в три раза больше памяти, чем Go.
Это одна из причин появления Pandas, NumPy - экономия ресурсов + повышение быстродействия.

Ну и могу еще добавить, что на Node/PHP/Pyhon будет крайне не просто написать что-то типа Docker и т.д., а Go для этой задачи отлично подошел :)

[tushev]

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

[tushev]

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

[Евгений Мамонов]

Всё очень сильно зависит от задач, которые вам предстоит решать.
Если почти все задачи это CRUD + база, можно не заморачиваться.

Другое дело если вы создаёте встраиваемую базу, консольные утилиты, Docker, сетевые сервисы (демоны), прокси, авторесайзеры картинок и т.д., т.е. всё, что выходит за рамки CRUD - Go будет хороший выбор.

Если вы хотите расти как специалист - Go/Java/C# тоже будет хорошим выбором.

Для себя я выбрал Go и использую его во всех новых проектах потому, что:
- Go действительно работает ощутимо быстрее, чем скриптовые языки
- код получается чистый, понятный, у всех сотрудников +\- одинаковый (критически важно, когда идёт работа в команде)
- скорость разработки почти такая же как и на Python и д.р. скриптовых языках
- удобная многопоточность из коробки (простой и понятный код без колбэков)
- шикарное взаимодействие между горутинами через каналы
- на выходе бинарник, удобно деплоить, код не падает после того, когда кто-то импортировал библиотеку внутри функции и не указал её в requirements, т.е. вы запускаете сервис и совершенно не ожидаете, что через какое то время он неожиданно потому, что этой библиотеки нет.

[Евгений Мамонов]

В тему выигрыша в размере хранимых данных (RAM), тут еще такой момент есть...

Смотрите, вы делаете выборку из базы и результат этой выборки будет, скажем, 1мб данных.
Эти данные нужно перебросить из базы в скрипт, а поскольку в итоге размер данных будет в 3 раза больше, то и нагрузка на CPU будет больше, и тут вы уже сразу почувствуете разницу в производительности.

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

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

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

Где-то читал статью, что у людей было API на порядка 40 серверов на Node, после переписывания на Go - серверов осталось два, из которых второй запасной :)

[Dimonchik]

tushev,

которые вообще оказываеются в кеше

ну что за колхоз?
ну CS50 хотя бы несколько раз прослушайте

[Rouslan943]

Евгений Мамонов, скажите сам язык легкий? Для новичка,?

[Евгений Мамонов]

Rouslan943, я бы советовал начинать с Python потому, что:
- python простой и понятный язык с очень удачным синтаксисом
- много открытых вакансий с хорошей зарплатой
- огромные возможности, на нём можно делать все, что угодно: веб-сервисы, ботов, нейронные сети, сайты, консольные утилиты, приложения для компьютера, мобильные приложения и т.д.

[Евгений Мамонов]

Тут нужно считать нагрузку более предметно.

Например согласно https://www.liveinternet.ru/rating/ru/#geo=ru сервис Почта Mail.ru имеет нагрузку в день примерно 10млн запросов. Это большая нагрузка, тут с PHP/Python/Node - будет очень трудно работать. Но даже тут можно часть задач сделать на С/C++/Go/Rust, а часть (не нагруженную) на PHP/Python.

Вряд ли вам удастся получить настолько большую нагрузку даже после роста.
Предположим у вас будет нагрузка 100,000 запросов за день с пиком 100-500 запросов (к примеру) в секунду - лучше брать тот язык, который хорошо знают ваши программисты.
Если они с Go раньше не работали, или не знакомы с микросервисной архитектурой - они будут очень долго делать проект и, не факт, что сделают как нужно.

Answer 2

[Александр Павлюк]

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

Comments

[tushev]

в го ты просто пишешь последовательный код, вместо колбэков, это легче

Сейчас в Node.js вроде тоже вовсю используются промизы и async/await. Выглядит как последовательный код без колбеков.

Строгая статическая типизация дает возможность вылавливать много проблем до релиза

В PHP тоже можно сейчас писать с жесткой типизацией. Это не обязательно, но при желании можно сделать все довольно жестко.

Разработчики на го не редкие и не дорогие, они довольно быстро воспитываются из разработчиков на других языках

Ну вот по последним обзорам зарплат в России все таки одни из наиболее дорогих.
Про перевоспитание, да, cогласен. Очень многие крупные работодатели общаясь с кандитатами на должность PHP-разраба, спрашивают, а готов ли он освоить Go/

[Александр Павлюк]

tushev, в ноде далеко не все библиотеки умеют в async/await, а в го это стандарт.

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

[tushev]

бегло почитал сейчас про эту систему типов в пхп, что-то она очень бедная и оторванная от железа

Ну не такая уж она сейчас бедная. Если принудить разрабов указывать типы в аргументах методов, и возвращаемых значениях и в свойствах класса, то вполне нормально. Всяко проще волевым решением обязать разрабов использовать типизацию, чем заставить разрабов перейти на другой язык.
Про "оторванная от железа", да... но часто ли вам нужно что то кроме int, double и string? Разве что когда надо заниматься сильной оптимизацией по памяти.

[Евгений Самсонов]

tushev, Когда пишу на PHP, даже используя типизацию, у меня есть опасения, что что-то вывалится в рантайме. А в Go если скомпилилось, то можно спать спокойно :)

[tushev]

Евгений Самсонов, Но ведь в Go тоже надо следить за корректной обработкой всех ошибок, опасаться nill pointer exception (или как там правильно он назвается), можно вылететь за диапазон слайса/массива. Вроде тоже куча возможностей рухнуть в рантайме.
Хотя если вы много писали на обоих языках, то вам виднее )) Теория это одно, а практический опыт может показать совсем иное ))

[mitya_k]

• Большинство либ переехала-переезжает на promise, включая core lib, а значит можно сразу использовать async/await
  
• TypeScript есть для типизации, причем она на порядок богаче, чем у Go
  
• Кластерный режим в Node js это 15 строк кода, или вообще можно использовать pm2, где просто указываешь кол-во instance
  
• Многопоточность в Node js тоже не сильно сложнее, а обычный event driven
  

[Александр Павлюк]

mitya_k, хмм, а как в ноде синхронизация потоков осуществляется? Допустим, когда к одной переменной имеет доступ несколько потоков?

[Александр Павлюк]

tushev, возможностей-то есть рухнуть в рантайме, но сильно меньше, чем в скриптовых языках. Все дело в вероятности

[Roman K]

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

[mitya_k]

Александр Павлюк SharedArrayBuffer и Atomics(для реализации семафоров)

[Alex]

mitya_k, а еще в добавок к этому не упомянули worker threads.

Answer 3

[mitya_k]

• Первая, причина, Go популярен за свою бедность синтаксиса, кому-то это нравится...
  Для больших компаний типа Google это плюс так, как можно посадить посадить 100500 программистов, которые вынуждены писать очень много однотипного болерплейта кода.
  
• Вторая причина, там где требовалось решать низкоуровневые задачи, без бизнес-логики(например, много работать с байтиками), плюс требовалась многопоточность для этого приходилось использовать СИ++. Теперь есть простая альтернатива в виде Go. Опять же это актуально для больших компаний, где есть подобные задачи. Например, писать какой-нибудь парсер террабайтных логов
  
• И последняя, можно сгенерить бинарь без зависимостей, что нравится работающим в DevOps, а для скриптования "богатый язык" особо не нужен. Опять же актуально для больших компаний, где есть большие отделы DevOps

Из всех 3 пунктов вытекает зарплата и популярность в больших компаниях.

Answer 4

[index0h]

В каких приложениях Go существенно эффективнее чем Node.js и PHP?

Go > PHP:

1. Приложения, в которых на инициализацию тратиться очень много времени и это критично. Грубо говоря, когда умирающая модель выполнения не подходит.
2. Приложения, в которых нужно много памяти для обработки.
3. Приложения, в которых необходима мультипоточность и реализация задержек во времени.

PHP > Go:

1. Приложения, в которых важна скорость разработки, а производительность на втором плане.
2. Приложения, в которых важна легкость горизонтального масштабирования. Грубо говоря там, где умирающая модель оптимальна.

Comments

[Александр Филиппенко]

Насчёт горизонтального масштабирования, не соглашусь, на Го вполне можно писать stateless сервера, и запускать любое количество инстансов.
Насчёт скорости разработки, на РНР обычно быстрее, особенно когда можно взять готовый пакет, и он на 100% подходит, но бывает и наоборот.

[index0h]

Александр Филиппенко

Насчёт горизонтального масштабирования, не соглашусь, на Го вполне можно писать stateless сервера, и запускать любое количество инстансов.

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

Насчёт скорости разработки, на РНР обычно быстрее, особенно когда можно взять готовый пакет, и он на 100% подходит, но бывает и наоборот.

Далеко не обязательно на 100%. Экосистема php в разы больше, чем у go. Соответственно как возможностей выбора, так и специалистовы больше + они дешевле, как правило.

Alexander Lamdan

Что то я не до конца понял, если мне щас развивать какой то проект скажем который возможно будет нужен компании с большими объемами данных, с крупной обработкой данных с нуля, то язык PHP плох?

Вопрос не правильный. Проект определяет инструменты для его создания.

А по ответам ниже Go не советуют использовать, и как тут быть?

У go - довольно специфическая ниша - это сетевые сервисы. Сайтики на нем писать будет накладно.
Тут по сути тот же ответ. Проект определяет инструменты.

[Александр Филиппенко]

Alexander Lamdan,
Инструменты выбираются под конкретную задачу, если часть проекта оптимально будет писать на Go, часть на Node, часть на PHP, пусть так и будет. То же самое касается баз данных, брокеров очередей и т. д.
При выборе инструмента всегда есть trade off, то есть выбор. Что вам важнее? Меньше платить за хостинг, или меньше платить программистам? Меньше багов или быстрее доставлять фичи пользователям?

Answer 5

[Uno]

Есть ещё некий момент следования за трендами.

В своё время, как нам всем известно, крупнейшие веб-проекты работали на PHP, и в проблеме возможности оптимизации киты решили изобретать велосипеды, что-то в духе своих диалектов, как фб или вк, кто-то переписывал ядра на более производительные языки, с++ итд итп.

Го же лично для меня представляется чем-то вроде золотой середины в описанной мной ситуации.
Он раз - компилируемый, два - эффективнее (>php,js), три - надёжнее (>php,js), четыре - проще (>c++). А значит удовлетворяет запросу выше.
И при том я бы ни в коем случае не разрабатывал (читай - не переписывал) на нём проект, пока под проект не выделен целый ЦОД, а не полка на стойке, пока обо мне не говорит весь мир.

С другой стороны - не обрёл он ещё той силы в виде поддержки, коммьюнити и возраста (как критерия надёжности), чтоб я предпочёл его крестам.

Comments

[Uno]

Alexander Lamdan, на то есть бизнес аналитика, маркетологи и фокус-группы, дабы избегать элемента внезапности. Трудно - это категория лени и отсутствия должной мотивации. Я сутки переписывал без сна в подобной ситуации проект (благо он не большой был) и ничего, жив, здоров, доволен.

Нет смысла разрабатывать стартапы и проекты с нуля которые на языке Go, потому что нету еще такой сильной нагрузки и хорошее имя?

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