Node.js или Java: производительность, ресурсы, управление потоками, популярность и личный опыт

JDK проприетарен, поэтому Java развивается медленно.

Во-первых, JDK не проприетарна, она под Sun License (она считается открытой), и частично под GPL.

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

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

Статья полна сравнениями тёплого с мягким, сферическими бенчмарками в вакуме и просто дилентантскими утверждениями.

Лень перечислять всё, для примера "один из минусов Node.JS":

был случай, когда разработчик удалил свою библиотеку из NPM и множество приложений использующих ее перестали работать;

1) NPM и Node.JS это разные вещи. Как можно делать вывод о платформе на основании менеджера пакетов?
2) Вот уже много лет с этого случая как в NPM запрещено удаление пакетов.
3) Есть альтернативы NPM и в виде менеджера пакетов и в виде хранилища.
4) Есть решения в виде локальных кеширующих NPM серверов.
5) Самое главное — приложения не "перестали работать". Удаление библиотеки никак не повлияло на работу приложений. А вот собираться они перестали.

О качестве остальной статьи делайте выводы сами.

Количество вакансий я думаю не совсем верно — ведь node.js позволяет переиспользовать компетенции фронтов на не сильно сложном беке. То есть это по сути «новый fullstack»

Если взглянуть поглубже то окажется что современная джава или нода практически одинаковы по критериям скорости обработки сетевых запросов и скорости вычислений. Но об этом по порядку:

1) Скорость обработки сетевых запросов

В Java мы можем создать приложение и запустить в нем 8 потоков. За счет того, что происходит более тесное взаимодействие с ОС, можно распределить нагрузку.

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

А когда приходит запрос на node, цикл событий (event loop) будет обработан и отправлен обратно, затем придет следующий запрос. И за счет того, что мы не ждем результатов первого, он тоже будет подхвачен.

и в java можно делать то же самое (nio, nio2 и т.д)

Многие не понимают что модель работы с сетевыми (и другими io-) запросами зависит не от языка и даже не от движка а от того какой апи операционной системы проброшен в язык — можно обрабатывать сетевые запросы создавая поток на каждый запрос а можно через мультиплексирующие или асинхронные апи ос (например poll/select/epoll/signals в линуксе) — и на этом сравнение становится совершенно бессмысленным потому что в джаве что в ноде можно пробросить любой апи операционной системы и соотвественно эффективность обработки запросов тут целиком зависит от ос и никак не от языка или движка (если конечно не накосячить с пробросом). А то что в ноде принято запросы обрабатывать через цикл событий а в джаве через потоки (а например в php еще можно через процессы) то это просто потому что джава появилась раньше а раньше люди были глупее и так сложилось исторически и продолжает еще двигаться по инерции. Единственная техническая разница движка которая может повлиять на проектирование и производительность заключается в том что в движках джавы обращение к общей памяти чужого потока а также общение между потоками (атомарные операции, мютексы, спин-локи и т.д) доступно на уровне объектов (с кучей сахара) а в джаваскриптовский движок v8 лимитирован пока только отдельными запросами чтения-записи на уровне массива байт через SharedArrayBuffer (но с другой стороны ничто вам не мешает построить вокруг этого массива байт свою абстракцию объектов и структур данных)

2) Скорость вычислений. Тут говорить что мол джава хороша для вычислений, сложных алгоритмов или бизнес-логики, а нода менее хороша (или наоборот) — бессмысленно и это очевидно каждому кто понимает как работает jit и процессоры. Современные движки что в js (в частности v8 который стоит в ноде) что в java уже довольно давно стали компилировать код в машинные инструкции с различными компиляторными оптимизациями поэтому разница по производительности будет минимальной. Понятно что может быть так что у одного движка может не реализована какая-то одна оптимизация а у другого другая но если не писать микробенчмарков направленных на выявления конкретных оптимизаций то можно сказать что общий уровень производительности обоих языков и движков примерно одинаков. А тот факт что джава статически типизируемый язык а жс нет — хотя и может сэкономить движку джавы одну ассемблерную инструкцию (которая требуется v8 для спекулятивной проверки рантайм-типа) но практическую разницу в скорости вы даже не увидите так как в реальных приложениях практически всегда всплывут сначала проблемы неоптимальной локальности данных (для сравнения один кеш-промах или инструкция загрузки из памяти а не из кеша равен нескольким сотням других ассеблерных инструкций, так что разницу в одну ассеблерную инструкцию вы даже не увидите)

Непонятна претензия насчет Kotlin. В Java главное это байткод и даже в одном проекте можно свободно смешивать языки. Из последних проектов обычно 2-3 языка Java + Kotlin + Groovy (не считая кода библиотек). Также как и в node.js проекте часто используют Javascript + Typescript.

Судя по статье, у автора очень слабые компетенции всего, что касается Java…

Сейчас не видно потенциального конкурента, который смог бы заменить Java и node.js

Так их вроде много, смотря какие задачи. На вскидку из современных платформ и языков сразу на ум приходят .net core, go, rust, python, да php в конце-концов. Если подумать подольше то конкурентов много больше. Еще есть функциональные языки со своими экосистемами, на которых люди решают любые задачи.

Не согласен с автором, что придет NodeJS и всех зарулит. Тут наоборот, дело к закату идет,
для написания сервисов с высокой нагрузкой и малым временем отклика, предпологаю, чаще стали брать GoLang. Тут сказывается то, что сам JavaScript все-таки плохо подходит для больших приложений и то, что не было многопоточности. Не от хорошей жизни хотят
в NodeJS начать использовать TypeScript.

Подъем NodeJS произошел на двух вещах:
1) В эпоху взрывного роста Ajax и возрастающего объема программирования на JavaScript на клиенте можно было начать писать на JavaScript и на сервере.
2) Легкость организации асинхронного выполнения программы, этакой многопоточности с точки зрения программиста.

А Java по-прежнему "пыхтит" на предприятиях и даже ускорила свое развитее после перехода к быстрым релизам, сохранив и LTS-релизы.

Например, такой условный недостаток как однопоточность уже исправлен

Забавно, что одно из самых главных преимуществ автор обозвал недостатком.

Java изначально создавалась как легковесное решение заменяющее C++

— Java.
— Легковесное.
Выбрать одно.

Вообще забавная статья. Прям как комикс, где стоят слон, обезьяна и т.д. и экспериментатор говорит «мы вас поставили в равные условия в этом тесте… поэтому вам нужно залезть на дерево». Так и тут автор почему-то сравнивает node.js и java на задаче связанной с большими вычислениями/обработкой данных. Нода не про это.

Бред.
1) OpenJDK opensource, и Oracle JDK на 95% это OpenJDK.
2) Как раз с Java все и потырили парадигмы, как например C#. Java эволюционирует и не стоит на месте.
3) На счет тяжеловестности тоже бред, можно легко создавать через Spring Boot легковесные сервлеты. Для исполнения в NodeJS тоже нужен движок V8, как и для Java JRE (который не так и много весит)
4) В Java также можно обрабатывать запросы на основе цикла событий. Также через потоки паралелить. Как вообще их можно сравнивать. Также акторы реактивщина есть.
5) на счет дерева зависимостей в NPM смешно читать. В java уже давно существует мега стабильный maven и более молодой и перспективный gradle.
6) Ваши ощущения, что NodeJS обогнала Java, это лишь ваше субъективное ощущение, которое никак не связано с реальностью, есть статистика на HR ресурсах, со спросом на конкретных специалистов.