5916
Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез
Выше ответил, раньше навязывали конкретный стиль, теперь есть выбор.
Читать полностью…
Будет наверное и что? В других может быть холодным(какой-нибудь стрим показателей с датчиков), но как оно на api-то влияет, холодный или горячий конечно будет паблишер решать, но на api-то это не влияет
Читать полностью…
Замена/альтернатива - в контексте двух видов апи в Джава фреймворках
Читать полностью…
Я и не говорил, что моно горячий. А в описанных кейсах выше флакс будет горячим
Читать полностью…
Ты выше пишешь, что реактивность онли для горячих потоков, я не понимаю как разница какая будет семантика у твоего потока, на api это не влияет. mono/flux - оба по-дефолту холодные потоки
Читать полностью…
То, что реактивный стек был использован как удобная абстракция над асинхронщиной - не значит, что оно является альтернативой виртуальным потокам. Нельзя реактивное программирование сделать на виртуальных потока(как гошник скажу, что можно, конечно, но пользы от этого почти нет)
Читать полностью…
Отлично можно сделать бенч как пруф оф концепт и посмотреть
Читать полностью…
Я просто не уверен, что в практике оно так и есть, потому что на бумаге он литераллм обязан меньше жрать
Читать полностью…
Ну, кстати если правильно сделал реактор, то он все равно меньше будет жрать чем виртуальные
*в теории, на практике хз
Если тебе нужно неблокирующее апи и не спамить потоки, то теперь есть вирт треды, а реактив оставьте там, где он действительно нужен - горячие стримы.
Читать полностью…
Связь с вирт тредами очевидна в контексте обсуждения реактивного апи. В том же спринге у тебя по сути два вида апи для одного и того же, и реактивный вариант был внедрен в свое время как альтернатива блокирующему и и без привязки к конкретному треду. Такой вот костыль
Читать полностью…
Ну это да, если, конечно, нет больших запросов по производительности
Читать полностью…
Если у меня цель реактивное апи юзать - я и возьму реактор
Но если мне нужно неблокирующее апи - теперь мне не нужно давиться реактором, у меня есть альтернатива.
Здесь еще добавлю, никто не ставит цели делать реактивное программирование на вирт потоках. Людям просто нужно удобное неблокирующее апи и переиспользование платформенных тредов.
Читать полностью…
Виртуальные потоки не реализуют механизм пропагейшена сигналов и реакции этих сигналов на потоки по-дефолту
Читать полностью…
А мы говорим, что виртуальные потоки вполне себе альтернатива этой абстракции, учитывая Джава фреймворки
Читать полностью…
Треды из этого чата показываешь коллегам на работе, и они тебя сумасшедшим называют, потому что уже всё работает, чего еще надо
Читать полностью…
Но все выше заметки только про джаву. В котлине вы берете реактор, берете экстеншен функции для реактора и у вас везде код синхронный, очень удобно. Остаются нюансы только с MDC и с пропогацией контекста, но это уже решено.
Читать полностью…
Там где уместно - да, ради апи, fluent style для горячих потоков топ
А что касается производительности - надо всегда мерить конкретные сценарии. У меня был кейс, когда синхронный апач клиент с тредами виртуальными был быстрее асинк собрата
Типа теперь (после виртуальных тредов) реактивщина только ради апишки удобной, а не производительности?
Читать полностью…
А ведь можно просто не задаваться такими вопросами и жить спокойно, просто переписывая получше свои тесты
Читать полностью…
Какой bp и какая реакция должна быть, если у тебя Mono<List<T>>
Читать полностью…