Ну если говорить про базы вообще, то у всех нормальных (носкл) есть асинк дрова и с ними работать одинаково - что из реактора, что из котлина, что из зиво

И лум не нужон

у него сейчас две проблемы:

нет фэйловера
нет кэша для кодеков

из-за этого сильно медленней

по фактам

А почему корутины зло?

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

От только внезапно выясняется что куча вещей в самой JVM блокирующие (привет класслоадинг и UUID) - одна из причин почему лум задерживается, кстати

потому что это one way road. Алсо, потому что императивный код для асинхронщины - это ложь (см Flow, к которому в итоге пришли)

что имеется ввиду под блокирующим UUID?

ага, спасибо

Ну с первым согласен и я думаю все понимают, что это так 😀 А вот со вторым не очень. Как же это может быть ложью, если уже сейчас работает 😀 Появление Stream API в Java не убило же обычные циклы. Так почему же Flow должен убить корутины и являться признанием их неудачным экспериментом, мне непонятно 😀

1. не совсем соглашусь что Stream API не уменьшило количество циклов
2. одно дело работа с коллекциями, а другое - асинхронный код. Жалко даже, что API для коллекций назвали Stream API - сильно сбивает с толку 🙂

золотая мечта, что когда-нибудь Stream API переведут на Flow

а оттуда мостик к reactivestreams

Не, стрим апи мертворожден

Проклято

Мой поинт вот какой. Когда мне нужно на запрос пользователя сбегать в парочку других сервисов, мне Flow особо не нужен, мне достаточно корутин и несколько саспенд функций 😀 А вот если у меня непрерывный поток данных, требующих обработки, то вот тут я обращусь к Flow (на самом деле к другой реализации реактивных стримов, но это не важно сейчас 😀) И да, я уже насмотрелся на кучу корявых попыток комбинировать Java фьючи (ну вот не даются они так просто людям🤷‍♂️), так что корутины прям как глоток свежего воздуха для меня и возможность спокойно прочитать код коллег и понять что он делает 😀

не надо позязя, пифоманс будет не оч