Pull to refresh

Comments 11

Прикольно рекомендовать доклад, который еще не вышел))

Прикольно мешать реактивность с многопоточностью. По критериям автора старая добрая Java даже без всяких легковесных потоков реактивна на 146%.

Пардон, Loom к нам только осенью в Java 19 приедет, да и то в виде превью фичи. А доклад состоится уже на днях и в готовом к употреблению виде. Ну как его не порекомендовать?

Всё верно, о докладе Олега Докуки и Андрея Родионова у меня ничего не сказано, и зря. Добавлю к своим ссылкам доклад Андрея Мычки на последнем JPoint: блестящий по содержанию (там всё по делу), хотя и непрофессиональный по форме подачи.

Тезисы доклада Андрея:

  1. реактивные стримы не имеют отношения к реактивному программированию;

  2. на бэкэнде не бывает реактивного программирования;

  3. Loom сдвигает точку Нетфликса очень сильно вправо;

  4. принятие Loom не затронет [реактивные] стримы.

Считаю, что тезисы Андрея аргументированы и весомы, его точка зрения имеет право на существование.

Мычка ссылается на доклад Олега Докуки и Андрея Родионова, хотя тот имеет небольшое отношение к Loom (согласен с Андреем).

Кроме того, Мычка ссылается другие интересные материалы:

Брайан Гётс "Loom убьёт реактивное программирование"

Эрик Мейер "Что значит быть реактивным?"
Мейер - фантастический докладчик. Рассматривает реактивное программирование в аспекте сайдэффектов. Хотя напрямую к Loom его доклад отношения не имеет, идеи там высказаны глубокие. Интересно будет взглянуть на проект Loom, используя подход Мейера.

По моему единственное что даёт loom это забыть о cachedThreadPool. Все остальные проблемы всё равно надо решать (синхронизации, эксклюзивный доступ к ресурсам, лимиты). Надо конечно сказать, что замена cachedThreadPool на фиберы в моем (конкреном) случае дало 10% прироста производительности.

Много почти бесплатных потоков это очень классно для серверов и фреймворков. Spring, Jetty и все подобное станут быстрее и при этом не потеряют простоту.

Типовая джавовая бизнеслогика от этого не выиграет почти ничего. Весь выигрыш будет внутри ее зависимостей.

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

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

Клиентский код вообще должен остаться как есть. Возможно будет даже медленней, поскольку добавляется еще один слой шедулеров на фибрах, а вырежут ли под это самописные шедулеры из асинка, вопрос совсем не однозначный.

Это что-то вроде async/await или о чем вообще речь?

И да, и нет. "Да", потому что добавляется возможность перехода на легковесные программные потоки. То есть работать будет (семантика) похоже на async / await. "Нет", потому что язык расширять (менять синтаксис) не будут. Обойдутся изменениями библиотечных функций. Старые-добрые Джава экзекуторы, форки и джойны без асинков и эвэйтов.

Sign up to leave a comment.

Articles