MishaXXL

Выскажу свою личную точку зрения:
1. Изучаем, каким будет трафик сервиса на старте. Если это замена уже работающему высоконагруженному сервису, либо вы на 200% уверены, что нагрузка прямо сразу будет высокой и дальше на 200% точно уверены, что нагрузка будет расти, не выбирайте ни ноду ни Java. Берите, например, Go. Он гораздо быстрее ноды, там даже стандартная библиотека уже имеет готовые решения для всего нужного REST, и есть куча прекрасных сторонних библиотек и фреймворков.
2. А вот если ваш проект новый, вы не знаете, сколько у вас будет пользователей, какая будет нагрузка, то не надо даже думать: берите то решение, которым вы владеете, и с помощью которого вы сможете быстро и дёшево собрать первую версию. Если это даже PHP, то пусть он и будет. С огромной вероятностью ваш сервис будет всё равно переделан и переписан позже, поэтому, чем меньше вы потратите времени и денег в самом начале, тем быстрее выйдете на рынок, и тем больше сэкономите первоначальных инвестиций. А когда проект начнёт приносить прибыль, вот тогда при помощи уже этой прибыли будете решать проблемы производительности

для REST серверов лучше Node не найти

РЕСТ может быть выполнен на чем угодно, хоть на pure c. Вопрос скила и удобства. Node полюбили за то что фронтэндерам не надо вкатываться с нуля, но это не делает его лучшим.

что для REST серверов лучше Node не найти

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

Например стриминговый сервер или сервер для чата, он же относится к разряду типичных запрос/ответ

еще одна большая ошибка, вообще всё смешал в кучу, "стриминговый" это больше про максимальный pull c сервера, "чата" это про полноценный обмен в обе стороны, а "запрос/ответ" это про базовый http и он для этих обоих случаев, очень невыгодная стратегия, поэтому для них в http написаны свои частные протоколы, например, websocket для нормальной реализации чатов.

Многое зависит от ваших умений и знаний, а также от задачи, которую нужно решить..

Если вы владеете лучше нодой, то пишите на ноде. Другое дело, сможет ли нода решить задачу, которую вам нужно решить. На java написано куча библиотек, которые решают множество повседневных задач. Сам язык и его фреймворки используются в highload cистемах в энтерпрайз.

Я широко использую язык Java для повседневных задач, но также иногда предпочитаю использовать Go.

Если выбирать Java для веба, то в чем она лучшая там?

Примерно ни в чем.
Был вопрос насчет реализации многопоточности в Node, но и его вроде как решили.

Закидают меня тряпками, но Java будет лучше во всем, но все ещё недостаточно хороша. Для сервер сайд посмотрите на .net, go, rust. Если вам нужно примитивные рест апи сделать, то нода отлично сработает, есть и фреймворки неплохие. Но для чего-то серьёзного по ресурсам не стоит выбирать ноду, имхо

Если выбирать Java для веба, то в чем она лучшая там?

Примерно всем.
Был вопрос насчет времени запуска приложения, но и его вроде как решили.

Обычно в Node.js весь код на JavaScript выполняется в одном потоке. Для асинхронного выполнения задача помещается в очередь задач. Иными словами, при создании 1000+ сокет соединений, JS будет создавать очередь и тормозить. И это ограничение производительности распространяется буквально на всё, в том числе при работе с файлами, а не только на REST приложения.

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

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

Плюсы и минусы интерпретатора и компилятора

Кроме того, невзирая на все нарекания фронтов, гораздо проще и удобней использовать jQuery в сочетании с Ajax и Java сервером, когда речь идёт о web разработке.

А дело даже не в языке, скорее плясать надо от конкретных задач, окружения, потребностей заказчика.
"WhatsApp - это XMPP и работает он на ejabberd, опенсорсном XMPP-сервере. А ejabberd написан на эрланге, да."
Веб-сервера - это зачастую посредники, и не надо на них всё навешивать. В Node.js есть NPM-пакеты, которые при инсталле компилируются из Си и здесь производительность явно не хуже Java.
Если разрабатывать проект (front-, back-end) в одиночку, по мне, лучше на чем-то одном, а это, по определению, JS. Если проект большой и куча бабла, то да, можно и повыбирать что на чем делать, под него и спецов поискать.
Ну и кстати, сейчас всякие ИИ достаточно хорошо и быстро переписывают библиотеки и модули, с одного языка на другой.

Я не специалист в играх но обычно когда хотят гарантированное время выдачи ответа -
используют key-value dbms,. Они очень хорошо масштабируются и таблица с 10
записями и таблица с 10 миллиардами записей дают примерно одинаковый отклик.

Далее - искусство разработчика - уложить действия с инвентарем и действия с балансом золота
в 1 едиснственную операцию put/get или атомарную операцию с key-value системой.

Из недостатков. Никакие сортировки и группировки использовать нелзя. Если сильно хочется
- создается 1 запись типа JSON и там уже заранее лежат отсортированные дочерние записи.
И такая запись подготавливается в фоновом режиме обычно.

1. Каждое открытие инвентаря это запрос к БД (т.е. при стоянии на месте и щелкая кнопку, мы будем нагружать БД запросами)?

Нет. Данные загружаются в оперативку при логине персонажа. Изменения также касаются оперативки. В базу скидывается при логауте. Ну еще периодически для синхронизации.

2. Каждое выпадение золота в мир это новая запись в общую таблицу мира, что в такой-то точке есть объект "золото"?

Да. есть объект "предмет". Есть структура "список предметов", скорее всего двухсторонний список. Он обновляется, в него добавляется, из него извлекается. Предметы в мире не записываются в базу вообще (если вы помните, при ребуте все что не в чьем-то инвентаре, пропадает. Не так уж много оперативки это занимает. Просто посчитайте.
Максимальный онлайн на шарде - 5000 игроков.
Объект - ну учитывая тип предмета, уникальный айди, разные параметры типа заточки, владельца, место, и так далее - 10-20 байт более чем достаточно. Ну давайте 50 байт возьмем, хотя на деле я уже не помню сколько там было, явно меньше.
50 байт * 5000 игроков и скажем 100 предметом у каждого - получим примерно 23 мегабайта.
Добавить клановые хроанилища. ну 30 мегабайт. Много это оперативки на сегодня? По-моему вообще разговор ни о чем.

3. Что происходит после того, когда золото было поднято, эта запись превращается в null?

Объект удаляется из списка.

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

Нет никаких проблем с тем, чтобы удалить объект и освободить память.
Для оптимизации, можно делать так, что объекты не удаляются из памяти, а "очищаются", то есть структура в памяти остается, просто ее удаляют из основного списка и добавляют в список "нулл объектов". Если их там слишком много, удаляют из памяти, при этом отдельно есть счетчик количества объектов, и если надо создать новый объект, то вместо выделения памяти просто берется уже готовая структура из соседнего списка, заполняется.

5. Для игр подходит любая БД (например Postgres) или есть определенный тип игровых БД?

Любая. В Lineage2 использовался MSSQL, в самописном народном java эмуляторе использовался mysql

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

Послушайте, если осилите.

1. Нет! Строки неизменяемые. Конкатенация строк - это операция по созданию нового объекта с новой ссылкой.

2. String это базовый тип для Java, а StringBuilder добавили только в 5-ю версию. Апгрейд существующего класса не стали делать по соображениям совместимости и чтобы не поломать String Pool, который для билдера не имеет смысла.

3. Потому что это разные типы!!! Хотите, чтобы String и StringBuilder сравнивались по содержимому? Делайте дочерние классы, в которых переопределяйте сравнение, а потом экземпляры своих классов присвойте переменным типов String и StringBuilder - магия, сравнение заработало!

Почему нужно было помимо класса String создавать дополнительные классы по типу StringBuilder?

Потому, что String - иммутабельный класс. Чтобы конструировать строки как раз добавлены StringBuffer (в версии 1.0) и StringBuilder (в 1.5).

В данном примере строка s спокойно изменяется путем конкатенации, что аналогично sb.append

В итоге у вас каждый раз создается новый объект. Не всегда это бывает уместно.

2. Почему все методы StringBuilderнельзя было поместить в класс String, чтобы не плодить классы строк?

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

3. Почему s.equals(sb) равно false, если мы сравниваем только значения, а не ссылки

Потому, что вы сравниваете разные объекты. StringBuilder - это не String.

В джаве есть четыре модфикатора доступа:
public
private
protected
и
"default", когда никакой не указан.
default - который, вы используете, когда убираете public, обладает свойствами "package private", т.е. видимость внутри пакета.

Пример:

package mypackage.second;

public class SomeClass {
    int a;
}

package mypackage.first;

import mypackage.second.SomeClass;

public class Main {
    public static void main(String[] args) {

        var someClass = new SomeClass();

        System.out.println(someClass.a); // a is not public in mypackage.second.SomeClass; cannot be accessed from outside package
    }
}

static - это вообще не о доступе.

Неправильно поняли. Модификатор static определяет к чему относится поле или метод - к классу или его экземпляру, доступ он не регулирует.

Это не ошибка, а предупреждение, что вы открыли файл, не принадлежащий проекту.

JS - однопоточный, то что Вы можете запустить несколько потоков (инстансов) не делает его многопоточным.
Следуя Вашей логике Бейсик тоже будем считать многопоточным.
P.S. это не отменяет возможности использования потоков в NodeJS. Впрочем на Бейсике тоже.

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

Вначале убедитесь, что лагает именно "всё", а не только одна мышка и интернет (через Wi-Fi). Возможно просто взаимные помехи мышки и wifi.
Второй причиной может быть сбой в работе SSD или жесткого диска. Соответственно проверьте их Cristall Disk Info, а до и во время тормозов - Cristall Disk Mark.
Так же проверьте заряд батареи и перегрев (нарушение вентиляции). В ноутбуках эти вещи могут сильно влиять на производительность.