Пишем 2d-игру на Java

Это хороший подход, вот только Swing и AWT — это далеко не основы, а довольно большие фреймворки для разработки десктопного ПО.

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

Можете взять за основу PlayN фреймворк. Он больше подходит для вашей задачи. Он довольно простой и позволяет создавать десктопные, мобильные и веб приложения. И статей про этот фреймворк на Хабре не сильно много и в геймдеве он больше востребован, чем swing и awt (для поиска работы в геймдеве лучше).

Пишем 2d-игру на Java

Похвально, что вы изучаете технологию и пишите статью.
Но под заголовком 2d игра на Java ожидал увидеть еще одну разработку под Android, с одним из десятков интересных игровых движков. Или хотя бы на базе JOGL что-то. Но никак не swing + awt.
Все же swing — это не тот фреймворк, на котором стоило бы делать игры.

Node.js в PayPal

Согласен, это крайне плохой результат, но про систему ничего не известно.
Но это платежная система. Она должна обеспечивать высокий уровень безопасности пользователя, а для этого нужно собрать много метрик и сделать много проверок (девайс, браузер, куки, геолокация, время суток и еще черт знает что). И скорее всего, тот сервер, который они тестировали — лишь проксирует эти данные на другой сервер.

Node.js в PayPal

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

В статье нету никакой информации про то что приложение выполняет под капотом и какая там реализация. Допустим, если приложение делает 2 запроса на другие сервера (авторизация и получение данных), то при классическом подходе на Spring troughput будет ниже, чем на Node.js, банально из-за того, что все время проведет в ожидании io (но на Spring можно написать такой же асинхронный код, как и на node.js).

Node.js в PayPal

Спустя два месяца разработки на Java, два разработчика стали параллельно работать над Node.js приложением.

Построено в дважды быстрее с меньшим количеством людей

Немного не правильное утверждение, т.к. когда задача уже сделана и нужно сделать «точно так же», это всегда будет в 2+ раза быстрее, чем узнать все требования и написать с нуля.

Да и Java для рендеринга html никогда не была хорошим решением. На ней можно это сделать, но это больше в угоду единому стеку разработки, нежели производительности.
Для фронтенд-сервера, действительно, лучше использовать что-то типа Node.js, А для API сервера, особенно с тяжелой логикой и/или расчетами, лучше брать компилируемый и типизированный язык (Java, C#, Go).

ps: но все же к результатам теста в статье есть недоверие. Скорее всего тест был проведен на холодном старте, без прогрева JVM / Node.js, думаю, на прогретой JVM, разница была бы не столь велика.

JVM не такая тяжёлая

В очередном переводе автор пишет, что раньше никому в голову бы не пришло запускать 5 разных программ на java одновременно, а теперь легко. Это правда? Вы юзаете более 5 программ java на своем Пк одновременно?

С приходом микросервисов порою необходимо подымать и больше 5 серверов, а еще IDE в несколько окон и дополнительные тулы. Конечно для комфортной работы в этом случае нужно порядка 16 Gb RAM, но больше всего съедает IDE; на микросервисы хватает по 200 мб, как на пару вкладок браузера :-)

А раньше этого не делали потому, что раньше более востребованным был подход с аппликешен контейнерами, когда в один контейнер запихивали и десять серверов. И запускать несколько таких контейнеров было действительно странным решением. Нужно было только в случае настройки/отладки кластеризации на уровне контейнера (к примеру shared-session между несколькими Tomcat инстансами).

JVM не такая тяжёлая

Потребляет под нагрузкой 200мб, но можно выставить лимит хоть 20 мб и оно будет работать (но хуже, очевидно).

Справедливости ради, стоит отметить, что вы забываете про Meta Space. Он будет отъедать память, пока она есть в системе (по необходимости), даже если выставить -Xmx. Метаспейс нужно ограничивать отдельно, и это минимум +50 мб на x64.
И да, на x64 при -Xmx20M с SerialGC (как самой легкой) JVM даже не подымится. Compact3 profile возможно поможет, но с этим еще не игрался.

Вот так и выходим на минимум 200-300 Мб для работы приложения. Но взвесив все достоинства и недостатки, будет очевидно, что это небольшая плата за всю мощь, которую предоставляет JVM как платформа.

О функциональном программировании в фронтенде

А создание всех возможных состоянии изначально, дает возможность описать программу декларативно. Будет писаться, не как доидти до конкретного состояния, а просто потребовать воссоздать конечный результат.

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

О функциональном программировании в фронтенде

Еще одна статья, которая имеет лишь громкий заголовок, но при этом не показывает ни достоинства ФП, ни недостатков ООП. Зачем?

Каждая статья из серии «ФП лучше ООП», всегда выглядит одинаково:
— «вот есть неизменяемость!» (которая дает преимущество ТОЛЬКО в многопоточной среде, но при этом имеет огромный ряд недостатков; лепить его везде — глупо! этим инструментом нужно пользоваться осмысленно!),
— «вот есть чистые функции!» (это хорошо, но без побочных эффектов невозможно построить ни одно приложение),
— «а ООП — это вообще фу-фу-фу!»

На самом деле, чисто ООП — не самая лучшая парадигма, но и чисто ФП — тоже!
Идеал — золотая середина между ООП и ФП!

Nginx + PHP 7.1.1 FPM vs Node.js 7.7.1 в качестве бэкенда ч.2

Честно говоря, я не понимаю вашей цели.
В реальных проектах на php уже давно не пишут простыню кода. И уж тем более не делают смесь html + php + sql, как это будет у вас при вашем текущем подходе.

Измерять скорость работы в попугаях в двух задачах, которые даже близко не лежали с реальными — зачем? Ради холивара? — ок, вам это получилось. Ради правды? — так вы не узнаете ничего.

И снова таки: если вам нужна производительность системы — возьмите платформу, которая даст производительность из коробки — компилируемые языки такие как C#, Java, Scala, Go.

ps: а задачи php и node.js в целом не схожи между собою: php нацелен на CPU-bound обработку, node.js — на IO-bound. В нормальной системе было бы хорошо даже совмещать их, нежели пихать невпихуемую логику в конкретную из платформ.

Nginx + PHP 7.1.1 FPM vs Node.js 7.7.1 в качестве бэкенда ч.2

если вы так стремитесь за производительностью, то почему вы взялись сравнивать две не самые то и быстрые технологии? почему не взяли более быстрые: C#, Java, Scala? зачем именно этот холивар между php и node.js?

Nginx + PHP 7.1.1 FPM vs Node.js 7.7.1 в качестве бэкенда ч.2

Идею я понимаю, но не поддерживаю:
1. если не преследуется цель написать DAL, чтобы потом можно было менять имплементацию коннектора, то смысла в этом нету.
2. в версии ПХП этого теста, даже функций нету — сплошное полотно.

Если была цель сделать как в реальной системе — были бы модули, подключался хотя бы PDO, а не функция mysqli, которая еще с php4 тянется в коре.
А так, это похоже на попытку написать код так, чтобы он просто работал хуже.

Nginx + PHP 7.1.1 FPM vs Node.js 7.7.1 в качестве бэкенда ч.2

С пулом коннектов еще лучше.
Я не node.js дев, потому лишь указал на явный косяк в коде.

Nginx + PHP 7.1.1 FPM vs Node.js 7.7.1 в качестве бэкенда ч.2

https://github.com/mazabenchmarks/NodeVsPHP/blob/master/rest_api.js

function mysqlQuery(query, cb) {
    connection.query(query, function (err, results, fields) {
        cb({err, results, fields});
    });
}

function generatePage(res) {
    const time = process.hrtime();
    mysqlQuery("SELECT * FROM `users`", ({err, results, fields}) => {
        let response = JSON.stringify(results);
        const diff = process.hrtime(time);
        const generationTime = diff[1] / 1000000;
        response += `<div><b>Страница сгенерирована за: ${generationTime}ms</b></div>`;
        res.end(response);
    });
}

а зачем вы столь извращенно завернули обращение к базе в «свой апи»?
вы же этим кодом вставляет палки в колеса JIT'у.

почему нельзя было сделать так?:

function generatePage(res) {
    const time = process.hrtime();
    connection.query("SELECT * FROM `users`", function (err, results, fields) {
        let response = JSON.stringify(results);
        const diff = process.hrtime(time);
        const generationTime = diff[1] / 1000000;
        response += `<div><b>Страница сгенерирована за: ${generationTime}ms</b></div>`;
        res.end(response);
    });
}

Новый GC Epsilon. У джавы может не быть сборки мусора. Шок. Сенсация

Во-первых, хотелось бы узнать откуда вы взяли «insufficientmemory»? В java, на сколько я знаю, такого нету. Если из .NET, то insufficient memory exception — это наследник ООМ.

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

jvm позволяет перехватывать ООМ и «спасать» от падения, вопрос — стоит ли это усилий? Если да — без проблем: перехватывай, спасай от смерти! :)

вот только если не хватает памяти, то тут скорее всего утечка памяти, и спасать по большей части нету смысла — все равно упадет, а потом снова и снова и снова, будет жить в конвульсиях: и сделать ничего не сделает и не упадет / не перезапустится.
По этому никто и не перехватывает ООМ.

Новый GC Epsilon. У джавы может не быть сборки мусора. Шок. Сенсация

В этом случае память ещё не занята, но выделить память для обработки у вас уже не получится

Это присутствует, но вы не сказали самого важного: перед тем как бросить OOM будет произведен FullGC 2-3 раза, и если после этого не будет свободной памяти — вылетит OOM (но это еще не конец жизни jvm).

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

Новый GC Epsilon. У джавы может не быть сборки мусора. Шок. Сенсация

Практическая полезность была бы кстати, если бы JVM умела бы делать быстрый hot-restart: прибиваются все треды, освобождаются все системные ресурсы, но при этом оставлялся бы PermGen с классами, сгенеренной статистикой выполнения и предкомпилированным кодом.

Дык, AOT в Java9 будет, и в некоторых кейсах пермгены и все прочее можно будет выкинуть.

AOT + GC Epsilon + не плодить мусор = хардкор для эмбеддед.

Новый GC Epsilon. У джавы может не быть сборки мусора. Шок. Сенсация

Спасибо за уточнение! Но я лишь напомнил, что это все же платный тул и если не знаешь лицензии — лучше не рисковать использовать его.

Новый GC Epsilon. У джавы может не быть сборки мусора. Шок. Сенсация

Только вот он дофига платный, хоть и идет с OracleJDK сразу.

Новый GC Epsilon. У джавы может не быть сборки мусора. Шок. Сенсация

Забыли про HFT, который тоже некоторые ребята делают на Java (DevExperts с Романом Елизаровым, если не ошибаюсь). В этой сфере GC — это злейший враг. А приложение не обязано жить больше нескольких часов.

А так же непосредственно для разработки библиотек, которые не мусорят — будет проще находить точки генерации мусора.

Но самое главное — это для того, чтобы бенчмарки гонять xD