давайте так, є два види завдань:
- CPU bound - різні алгоритми, математика, кодування / декодування / шифрування. словом все що навантажує процесор.
- I / O bound - власне коли у нас йде безліч операцій з введенням / висновком, десь 90% завдань пов'язаних з WEB і серверної розробкою.
Для CPU bound варто використовувати мови на кшталт Сі, Rust, Dlang, Go і т.д. Словом язики які компілюються в ефективний машинний код.
Для I / O bound - Go, NodeJS, Erlang, Java. да в принципі не важливо яка мова, головне що б використовувалися Неблокована виклики і були відсутні блокування.
Ще є черги завдань, горизонтальне масштабування і т.д. Архітектура і алгоритми використовуються в системі впливає часто набагато сильніше ніж мови програмування.
Які мови краще використовувати для цього? Які не використовувати?
Ніяких обмежень, тільки здоровий глузд. Тобто навряд чи ми будемо писати складну математику на node.js, але завдань пов'язаних з цим набагато менше. Так само ніхто не говорить про те що систему потрібно писати строго на одній мові. Нині модно використовувати мікросервіси, кожен з яких може бути реалізований на своїй мові і зі своєю базою даних, що ідеально підходять для конкретного завдання.
Ще не варто забувати про алгоритмах. Вони теж повинні бути оптимальні. Наприклад взяти просту задачу - кластеризація міток на мапі. Уявіть що у вас в базі мільйон об'єктів, які ми повинні виводити на карті. Оскільки робити подібне на клієнті буде проблематично - ми повинні робити це на сервері і повертати на клієнт рівно стільки даних скільки йому потрібно.
І на таких обсягах навіть якби ми взяв Сі, якщо наш алгоритм має складність O (N ^ 2) то як би нічого тут особливо не поробиш. І так і так повільно буде. А ось якщо ми візьмемо будь-які алгоритми мають складність O (NLogN) то вже можливо що алгоритм цей можна хоч на php / python / ruby імплементіть. Так наприклад у мене цей алгоритм реалізований на Java і не найефективнішим чином. Справляється.
Ще впливає швидкість розробки (всякі ruby / python / node в цьому плані хороші), вартість підтримки (Сі підтримувати сильно дорожче ніж Go наприклад, хоча завжди можна написати все настільки погано що простіше викинути ніж підтримувати), вартість розробників. Скажімо знайти дешевих сильних розробників на Go або Rust буде вельми проблематично.
Так само не варто забувати що сервера нині коштують не так дорого. Іноді бізнесу простіше доплатити за ще десяток серверів ніж писати все на плюсах.
Власне головне правило високонавантажених систем - тестування навантаження а потім вже оптимізації
> Бінарна сериализация не дасть виграшу, якщо це не нативний формат даних в пам'яті v8 або іншого движка.
Я щось підозрюю що все ж накладні витрати на це все добро не менше звичайного парсинга JSON. Але потрібні бенчмарки. В цілому ідея цікава і я як-небудь спробую.