> Тоже мне, аргумент. Сейчас такая задача тривально решается на Go или node.js. С Go не работал проф., комментировать не имею права.
Про Node...
У Вас недопонимание разницы между понимание асинхронной обработки с псевдо потоками и полноценной многопоточной архитектурой.
Вы пытаетесь мне доказать, что Node.js который по фактически не имеет нормальной многопоточности и инструментов работы с ней будет сопоставим с нормальной многопоточностью в Java при решении одинаковой задачи.
Про то, что в Node.js просто не способен реализовать ряд решений, Вы забываете ?
> Раньше - для этого был (и есть) erlang/OTP.
Знаете, Erlang - решение крайне нишевое, но почему Вы его в раньше поставили - ума не приложу. Он весьма активно используется в соот. кругах и теперь, более того - активность его использования растет, причем на глазах.
Erlang - это д-но шедевр для HL. К примеру RabbitMQ - это очень яркий пример.
А вот ставить его в один ряд с Node.js не стоило - это платформы разных уровней, т очень большое оскорбление для детища Ericsson
> Не говоря о том, что поднять пачку более-менее изолированных потоком или аналогичную пачку процессов по нагрузке почти одинаково, а по надёжности - процессы куда получше будут.
Мы не может реализовать нормальную многопоточность и потому будем искать аргументы почему она не нужна, позиция удобная аж жуть берет ...
Теперь про нагрузку - на ЦПУ относительно да. А вот по памяти ... извините, но fork и послед. события дают такой расход, что.
Даже такие фишки как copy on write не всегда кардинально меняют ситуацию, да и платформенно зависимые они.
Ед. здравый аргумент - многопроц. приложение и сделать проще и работать с процессами отдельными также проще, это факт.
> Очереди (которые *MQ), опять же, тоже не вчера придумали.
Ну вот, опять встраиваете костыли которые делают решение оригинальной задачи иным.
Технологически иным, при это добавляя сложность и т.д.
Забавно выходит ... сперва мы ставим некий Node, привязываем еще вагон внешних систем, которые компенсируют ублюдочность самой платформы приложений.
Давайте честными будем перед самим собой - на сегодня для большей части новых проектов ед. критерий - скорость разработки независимо от степени ублюдочности результат.
Но это не повод обзывать более корректно реализованные тех. решения ... каждому -свое.
> Но язык убогий, каковым, он, вобщем-то, и планировался.
Знаете если Java экосистему называть убогой, то как тогда называть JS и Node.js ?
