как будто проклятье?)

Насчёт abs таки интересно, производители систем естественно заявляют, что уменьшает но сравнений и результатов не припомню..

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

курс по книжке?

я книжку купил но все руки не доходят 🙂

нет, дополняет хорошо. Только не знаю курс книжку или наоборот ))

Я к тому, что это вопросы, на которые нет и никогда не будет однозначного ответа.
Слишком много факторов.
Например abs: чистота и ровность дорожного покрытия, скорость и масса авто, наличие боковой силы, характеристики покрышек, диаметр колёс, сила нажатия на педаль тормоза, в конце концов настройки самой АБС.
На одном наборе данных ты получишь один результат - увеличение тормозного пути на 10%, на другом - противоположный - уменьшение тормозного пути на 9.9%. И будет ещё 999998 наборов данных, на которых ты получишь промежуточные результаты.

Но самое главное в этом вопросе, это то, что он почти не имеет смысла. Т.к. цель ABS вовсе не в сокращении тормозного пути, а в сохранении управляемости (особенно в экстремальных условиях).

Также и в вопросе иммутабельных структур. Высокое быстродействие и небольшой расход памяти - не главная цель. Важнее сохранить управляемость всей системы (сохранить её естественную врождённую простоту и как следствие - не снизить надёжность). Как в общем, так и в аспекте параллельных вычислений в частности. Множество проблем просто перестаёт существовать.
Снижение быстродействия и увеличение расхода памяти вовсе не отрицается. Это лишь плата за сохранение управляемости. И кстати утверждается, что сделано всё для того, чтобы эта плата была не такая уж и большая.
Но конечно всё равно бывают ситуации, в которых даже такая небольшая плата оказывается недопустимо высокой.

(+ 4 10)

Есть выбор:
Вариант А: запилить систему на Java (Не! на C!). Всё будет очень оптимально по памяти и CPU. Правда разработка займёт N человеко-времени. Внедряешь и потом отлаживаешь и патчишь систему в течение N*N времени силами N инженеров уровня "программист на С". Всё это время система то тут, то там сбоит. Но зато когда не сбоит, то работает очень быстро и не сильно жрёт память.
Вариант Б: запилить систему на Clojure. Иммутабельность... Надо побольше CPU и RAM. Разработка займёт N/2 или может даже N/200 человековремени (правда злые человеки-кложуристы дороже будут просить раза в 2). Потом внедряешь систему и она работает. И почему-то не надо её перезагружать и патчить. А в следующем году поменял CPU, накинул памяти и система уже работает в два раза быстрее. А обслуживанием системы иногда занимается 1 инженер сопровождения.

Просто смахните пыль с экрана...

Ну про то что разработка займет N/2 это еще большой вопрос. Как говорится пруфы или не было.

Что-то мне подсказывает что на большой системе внезапно может и нивелироваться разница

На большой системе будет N/200. Но пруфов нет. Так что я вообще молчал и ничего не было.

код в meshке

Коллега рассказывает, друг на работе писал код на Джава и применял for-each, начальника сказал ничего не понятно переписывай с for)

а вот вопрос про конкуренцию, есть сервис типа кафки (apache pulsar), нужно сделать дооолгоживущий поток (тред), который будет из кафки почитывать. Что нонче модно применять? или просто Thread создавать?

с Thread будет не очень удобно интерфейс для такого читателя дизайнить. можно сразу на core.async смотреть

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

ок, но этот тред будет блокироваться пока не завершит обработку одного сообщения (или батча, тут зависит от того как читаешь)