опять же фреймворк vs тонкий роутер, как вы заметили выше )

Да, только сингл тред помойка такой и останется, а эликсир ты можешь натянуть на любой ксеон

там вроде какие-то работы по выключению гила провелись

Кемал тоже вроде однопоточная вещь. Многопоточность в crystal появилась позже Kemal

То есть не всё что быстрее по синтетике будет быстрее в реальном проде. И потом, как я написал выше, главное чтоб разработка велась плавно и ничего не грохнулось под Новый год.

Интересно. По composite score - phoenix сильно выше джаги и рельсов, чуть ниже express и symphony: https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=composite

Коллеги, он и должен быть выше джанги и рельсов. Разве не следует считать(хотя бы самообманом) что он должен быть где-то в районе джавового спринга и .NETных вариантов

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

С чего бы это динамиескому языку там быть? Он должен быть там в первых рядах когда у тебя +100К вебсокет соединений на одной машине, да, а не на простых http реквестах и json парсингу и запросах к базе.

а почему динамическому там не быть? и при чём здесь динамичность вообще? Байткод байткодом, виртуалка виртуалкой
справедливо ментально сравниваю его с языками, под которыми тоже виртуалка с байткодом

Что-то luminus я там в первых рядах не вижу, хотя в два раза лушче феникса да.

я думаю в случае JVM многи либы типа json парсинга безусловно быстрее работают.

а что если круды бахать на джаве, а эликсир оставить для эрлангистов, чтобы они при желании переписывали своё на него

Если речь касается маленьких программ, то C(и многие другие языки) быстрее Erlang/Elixir, это понятно, но когда дело доходит до больших масштабируемых систем Erlang/Elixir быстрее C. Так что вы про производительность не волнуйтесь.

Вот вам жизненный пример.
https://youtu.be/lm_6WzWazjU в этой серии видео сравнивается производительность nif xml parse и эликсировского saxy.
По результатам бенча большого xml - saxy всего в 1.3 раза медленнее nif. Зато памяти потребляет в 1900 раз больше.

Ну, у нас был абсолютно обычный бизнес-процесс, около-банковский, под кодовым названием «открывашка». Только это было не в наших привычных степях, а в одном там джава-финтехе.
Ну, мы повертели всякие бпмн-плееры в голове, поняли, что задница какая-то с ними, ну и написали на коленке стейт-машиной на голой яве. Результат первое время радовал, а потом (внезапно) выяснилось, что fsm плохо масштабируются, и пошло как обычно.
Артефактную модель я нашёл уже позже, и протащить уже не сумел, о чем жалею в общем, Былбасовка занятный эксперимент.

Небось через ООП всё делали?

Что значит "fsm плохо масштабируются"?

проектирование через ООП это какой-то неправильный путь?

Fsm как модель описания некого процесса в коде очень теряет читабельность по мере усложнения процесса.