Во-первых, можем ли мы действительно измерить скорость языков программирования?

В теории

Очень сложно сказать, какой язык бэкенда самый быстрый или самый масштабируемый. Как мы могли это проверить? Вероятно, нам следует протестировать что-то реальное, например, сервис, работающий в производственной среде! Для этого возьмем тысячу компаний, посоветуем им написать две версии своей флагманской серверной службы на двух внутренних языках, а затем сравним скорость обеих версий.

Никто явно такие тесты не делает. Даже если бы некоторые компании сделали это, как бы они решали, когда данный проект готов к тестам скорости? Любая сложная программа всегда остается незавершенной, всегда есть что оптимизировать.

Другой вариант - перейти на другой конец спектра сложности. Мы могли бы протестировать подпрограмму двоичного поиска, написанную на двух языках, или простой http-сервер, который будет иметь единственную конечную точку hello world. Мы знаем (наверное) оптимальные решения таких проблем. Но тогда, дает ли нам тестирование таких программ какие-либо знания о реальном мире? Не обязательно.

Давайте посмотрим правде в глаза. Оценить скорость и масштабируемость языка программирования X непросто.

На самом деле все становится еще сложнее, когда мы понимаем это, говоря:

Язык программирования X работает быстро.

это как сказать, что:

Самая новая песня Джастина Бибера громкая.

Громкая не песня. Мы чувствуем громкость благодаря певцу, музыкальному оборудованию или обстановке. Другими словами, громкая реализация. Точно так же скорость данного языка программирования зависит от реализации. В наши дни, когда мы говорим:

Node.js работает быстро.

на практике это означает:

Самая популярная реализация javascript, которая может работать вне браузера, созданная Google V8, работает быстро.

Однако самой популярной реализацией Node.js в будущем может стать не V8. Возьмем, к примеру, Python. Имеет десятки внедрений.

На практике 1

Если вы возглавляете крошечный запуск, проблемы с масштабируемостью / скоростью - это последнее, о чем вам следует беспокоиться. Мой стартап www.tiengos.com полностью написан на javascript / Node.js. Тысячи пользователей используют приложение каждый месяц, и проблем с масштабируемостью / скоростью пока не наблюдается. И я не утверждаю, что Node.js (в его реализации V8) - это самый быстрый язык, который я мог выбрать. Я действительно утверждаю, что это лучший язык программирования для небольшой технологической компании, работающей в нескольких сферах разработки программного обеспечения (интерфейс, серверная часть, мобильные устройства, данные).

На практике 2

Хорошо, но что, если возникают проблемы с масштабируемостью / скоростью? Я видел их в компаниях, в которых работал. Ни одна из них не была вызвана самим Node.js, что не означает, что этого не может произойти с Node.js.

Упомянутые проблемы скорости / масштабируемости чаще всего были отражением работы всей организации. Всегда было большинство инженеров, которые не понимали проблемы. Инженеры по фронтенду были автоматически включены в эту группу, поскольку кодовая база проблемного проекта создавалась на другом языке программирования и, следовательно, в другой экосистеме.

Другая группа инженеров представляла собой меньшинство, специализирующееся на экосистеме. Они понимали проблему, но не могли решить ее самостоятельно за относительно короткий промежуток времени. Было два решения:

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

Теперь предположим, что бэкэнд был написан на Node.js и эта вышеупомянутая проблема масштабируемости бэкэнда возникла с Node.js. Это изменит две вещи:

  • Меньшинство инженеров, которые понимают проблему, было бы больше, возможно, даже составило бы группу большинства, благодаря разработчикам внешнего интерфейса, которые могут легко переключаться между внешним интерфейсом javascript и внутренними проектами Node.js. Возможно, это не решило проблему, но чем больше проектов сможет понять данный инженер, тем лучше.
  • Нанять старшего спасителя бэкэнд-инженера было бы по крайней мере так же просто (но во многих случаях намного проще), как нанять спасителя на любом другом бэкэнд-языке.

Заключение

Чаще всего возникающие стартапы сталкиваются с множеством различных проблем, с которыми могут помочь инженеры. Это может быть отсутствие поддержки, плохой пользовательский опыт, медленные релизы или найм. Надеюсь, вы не побоитесь использовать Node.js в качестве внутреннего языка. Это может помочь сосредоточиться на действительно важных проблемах. Если вы хотите узнать больше о преимуществах использования только стека Javascript / Node.js, загляните в другую мою статью.