Работал ли с RxKotlin

А, ну да, работал, куда ж без этого. RxKotlin — это такая, понимаешь, обёртка над RxJava, только для котлинщиков, чтобы им слаще было. Добавляет там своих сахарных расширений, чтобы код не выглядел как древнее заклинание на джаве. Использовал, в основном, когда надо было асинхронщину какую-то запилить, или события от юзера обработать, или цепочку запросов на сервер выстроить — ну, стандартная история, в общем.

Вот, смотри, классический пример с Retrofit, чтобы не быть голословным:

apiService.getData()
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(
        { data -> updateUI(data) },
        { error -> showError(error) }
    )

Вроде ничего, да? Красиво, ёпта. Плюсы, конечно, на лицо: декларативность — пишешь, что должно произойти, а не как; обработка ошибок в одну строчку делается, не надо эти вечные try-catch плодить; и операторы — это просто песня, блядь. map, flatMap, debounce — с ними можно такие пасьянсы разложить, что сам потом офигеваешь.

Но, как водится, без ложки дёгтя никуда. Минусы тоже есть, и ещё какие. Во-первых, кривая обучения — это пиздец просто. Человек смотрит на этот функциональный стиль и первые недели две просто в ауте, ничего не понимает. Во-вторых, утечки памяти — если вовремя не вызвать dispose(), то подписка висит, как сонная муха, и приложение может накрыться медным тазом. Волнение ебать, пока все эти CompositeDisposable не отследишь.

Честно говоря, для новых проектов я уже давно перешёл на Kotlin Coroutines + Flow. Там как-то попривычнее, ближе к обычному коду, и с утечками головной боли меньше. Rx — это мощно, конечно, но как будто пушкой по воробьям стрелять, если задача простая.