Реактивное программирование на Java: как, зачем и стоит ли? Часть I

[jugard]

Прочитал про электроны, движущиеся со скоростью света, пишу коммент перед закрытием статьи.
И зачем эти физики строят ускорители, может им научиться делать транзисторы?

[alklimenko]

В том предложении вообще всё прекрасно)

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

Получается, что частота процессоров растёт, потому, что электронам меньше нужно бегать)
Про световую скорость электронов уже упомянули. Реально она в проводниках порядка миллиметра в секунду

[sergey-gornostaev]

Из текста может сложиться ошибочное представление о том, что Node.js появился раньше Netty и до него асинхронность в Java не применялась, но это не так.

[grobitto]

> Сложно писать, сложно отлаживать, сложно тестировать.

Впервые вижу эти эпитеты в отношении синхронного/многопоточного кода при сравнении с асинхронным. Отлаживать его как раз одно удовольствие по сравнению с мешаниной коллбэков. Как только project Loom с его легковесными потоками (Fibers) выйдет в продакшн будет вообще прекрасно, простой понятный синхронный код без проблем с производительностью

[Kirillchug]

Асинхронный код удобно очень отлаживать. Мы в компании используем Project Reactor. Пишется как обычный Stream API и если надо, можно спокойно «провалиться» в одну из его стадий.
А в многопоточном минус в том, что можно не дождаться того результата, при котором у тебя упала ошибка, потому что потоки не предсказуемы. Они в целом выполняют задачу правильно, а вот на конкретном уровне они непонятно как могут работаться с данными.

[grobitto]

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

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

[sergey-gornostaev]

Асинхронный код точно так же работает в разных потоках

Не обязательно, цикл событий может работать в одном потоке.

Как только в java завезут файберы проблема производительности решится сама собой

Серебряной пули не существует. Почитайте например цикл статей "Do Looms Claims Stack Up".

[tonhead]

Только дочитав статью, я понял, что про реактивное программирование на java здесь ничего нет, а жаль

[olegRazgul]

Когда выйдет следующая часть?

[hedgehog_on_rainbow]

Ориентировочно статья выйдет в среду, 10 марта.

[zesetup]

Но в этой схеме нет ожидания. Сравним ее с традиционной моделью многопоточного сервера в Java.

Что за фокусы? Есть там ожидание. Там просто более простой способ вызвать обработчик при завершении(calback, promise). В Java это нужно сделать "вручную", то есть проверять статус потока и при получении его результата вызвать какой-то код.

[vvbob]

Какой-то бредовый пример со стиралкой.

И в первом случае и во втором есть параллельное выполнение, просто разговор о разных этапах, на первом - загрузка белья, на втором стирка. Мама с ребенком точно так-же после загрузки будут заниматься своими делами пока машина стирает, и парень справа точно так-же занимался загрузкой белья как и они. Пример, который не объясняет ничего, только запутывает.

В "обычном" программировании "просто" надо понимать что синхронизации потоков это процесс сложный и затратный, и по возможности стараться обходиться без него. Чем тогда это отличается от реактивщины?

[ikarushka]

Объясните, пожалуйста. ProcessData1 и ProcessData2 получили все данные из ReadData? И каждый процесс обработал весь объем данных. И потом этот весь объем обработанных данных объединил с самим собой. В чем смысл? Или ProcessData1 и ProcessData2 получают какие-то порции данных от асинхронного ReadData?

[wakarimasen]

Отличная статья, спасибо!