Привет, Хабр!

В первой и второй частях мы разобрали Java Thread, thread pools, virtual threads, Kotlin coroutines, ZIO runtime и Clojure primitives. Теперь можно сравнивать модели без ощущения, что это просто разные названия для “запустить что-то параллельно” и ответить на вопрос “А нужны ли еще обыкновенные thread pools?”

В этой части:

1. Kotlin coroutines против ZIO runtime.

2. Clojure core.async и вопрос, есть ли там аналог корутин.

3. Есть ли в Clojure что-то похожее на ZIO runtime.

4. Аналоги ZIO в чистой Java и Kotlin.

5. Что стало с thread pools после Loom, coroutines и fibers.

8. Сравнение: Kotlin coroutines и ZIO runtime

Тут сходства больше, чем кажется. Kotlin coroutines и ZIO fibers лёгкие, не равны platform threads, умеют cancellation, дают structured concurrency и позволяют писать последовательный на вид код поверх ограниченного числа реальных потоков.

Но ZIO добавляет слой, которого нет в базовых Kotlin coroutines: типизированный канал ошибок E, типизированное окружение R, единый тип эффекта, resource safety, supervision и богатую композицию эффектов. Это не “ещё одна async-библиотека”, а способ описывать программу.

Kotlin прагматичнее. Есть suspend, CoroutineScope, Flow, Job. Ошибки чаще идут через exceptions, Result, Either из библиотек или sealed-классы. Зависимости обычно решаются DI-контейнером, а не типом эффекта.

suspend fun loadUser(userId: UserId): Either<DomainError, User> =
    either {
        val raw = userClient.load(userId).bind()
        raw.toDomain().bind()
    }

В ZIO это встроено в базовый тип. В Kotlin это обычно собирается из корутин, Arrow и дисциплины команды.

Если коротко:

Kotlin coroutines - runtime для suspend-вычислений.
ZIO runtime - runtime для типизированных effectful-программ.

9. Clojure: есть ли аналог корутин

Самый близкий стандартный ответ - core.async.

core.async приносит CSP-модель: channels, go blocks, <!, >!, alts!. Это мир “процессы общаются через каналы”, знакомый по Go и CSP, а не мир async/await как в Kotlin.

(require '[clojure.core.async :as async :refer [go <! >! chan]])

(def requests (chan))
(def responses (chan))

(go
  (let [request (<! requests)
        response (handle request)]
    (>! responses response)))

go block похож на корутину в одном конкретном смысле: код преобразуется в state machine и может парковаться на операциях с каналами, не удерживая обычный поток.

Но это не Kotlin coroutines:

• go block в первую очередь про parking на core.async channels;

• внутрь go нельзя спокойно класть произвольный blocking I/O;

• для blocking-операций используют async/thread, отдельный executor или обычные Java/Clojure concurrency primitives;

• нет языкового suspend, который распространяется через сигнатуры функций;

• structured concurrency в стиле coroutineScope не является базовой моделью core.async.

core.async - это lightweight concurrency вокруг каналов и обмена сообщениями, а не универсальная замена Kotlin coroutines для любого async-кода.

Если сказать грубо:

Kotlin coroutine - suspendable computation.
Clojure core.async go block - lightweight process around channel operations.
ZIO fiber - lightweight task executing a typed effect.
Virtual thread - lightweight JVM Thread for blocking-style code.

10. Clojure: есть ли аналог ZIO runtime

Прямого аналога ZIO в Clojure core нет.

И причина не только в том, что “не написали такую библиотеку”. Clojure - динамический Lisp. В нём нет Scala-типов вида ZIO[R, E, A], где зависимости, ошибка и результат зашиты в тип. Clojure обычно не пытается выразить всю effectful-программу через статический тип.

В Clojure есть сильные вещи, но они лежат в другой плоскости:

• immutable persistent data structures как дефолт;

• STM для координации нескольких mutable references;

• atoms/agents/promises/futures как маленькие, понятные building blocks;

• core.async для CSP и каналов;

• Java interop, позволяющий брать virtual threads, executors, CompletableFuture, Reactor, Netty и всё остальное JVM-хозяйство.

Если искать ZIO-like библиотеки по духу, можно смотреть на missionary, manifold, promesa, иногда на интеграции с Reactor. Но они не стали для Clojure тем же, чем ZIO стал для части Scala-мира.

missionary ближе всего к разговору про functional effects: задачи, потоки/flows, cancellation и композиция. manifold даёт deferred/streams для асинхронного JVM-Clojure. promesa даёт promise-like композицию, особенно полезную на ClojureScript/interop-границах. Но всё это не “Clojure ZIO” в строгом смысле.

Можно ли сказать, что в Clojure есть что-то сильнее корутин и ZIO runtime? Да, но не в той же категории.

STM и immutable-by-default модель могут быть сильнее корутин там, где главная проблема - shared mutable state. Корутины помогают организовать async-выполнение. ZIO помогает описывать effectful-программы. Clojure часто уменьшает саму площадь проблемы: меньше мутабельности, меньше гонок за состояние.

Но если вопрос именно про “runtime, который управляет миллионами lightweight tasks, typed errors, dependencies, scopes, resources и supervision”, то Clojure core такого не даёт. Там философия другая: маленькие ортогональные примитивы плюс иммутабельность плюс interop с JVM.

11. Аналоги ZIO runtime в чистой Java

Если под “чистой Java” понимать только JDK, то прямого аналога ZIO нет.

В JDK есть куски, из которых можно собрать многое: CompletableFuture, ExecutorService, virtual threads, structured concurrency, scoped values, Flow API. Но это не effect system.

CompletableFuture<Response> response =
    loadUserAsync(userId)
        .thenCombine(loadOrdersAsync(userId), this::render)
        .exceptionally(this::fallback);

CompletableFuture полезен, но у него другая природа: он eager, ошибка не типизирована как отдельный параметр, cancellation и structured lifecycle требуют аккуратности, зависимости не выражены в типе.

Если брать библиотеки и фреймворки Java, то ближайшие соседи:

• Project Reactor: Mono, Flux, schedulers, backpressure, Spring WebFlux;

• RxJava: Single, Observable, Flowable;

• Mutiny: Uni, Multi, Quarkus/Vert.x-мир;

• Vert.x: event loop runtime и async-модель;

• Vavr: функциональные типы (Either, Try, Future), но не полноценный runtime уровня ZIO.

Project Reactor ближе всего по популярности в Java backend, но это reactive streams runtime, а не ZIO.

Mono<Response> response =
    Mono.zip(loadUser(userId), loadOrders(userId))
        .map(tuple -> render(tuple.getT1(), tuple.getT2()));

В Reactor есть мощная async-композиция, backpressure в Flux, интеграция со Spring. Но typed environment R и typed error channel E там не становятся центральной моделью программы.

В чистой Java современная ставка выглядит иначе:

virtual threads + structured concurrency + scoped values

Не “ZIO для Java”, а попытка сделать обычный imperative/blocking стиль снова масштабируемым и более структурированным.

12. Аналоги ZIO в Kotlin: нужны ли они вообще?

В Kotlin ситуация интереснее, потому что сам язык уже дал то, ради чего в Java часто тянутся к библиотеке:

• suspend;

• корутины;

• structured concurrency;

• Flow;

• нормальные extension functions;

• sealed classes;

• удобные DSL.

Поэтому полноценный “ZIO для Kotlin” не стал очевидным центром экосистемы: роль основного runtime для конкурентности уже занял kotlinx.coroutines.

Вокруг этой модели в Kotlin обычно используют несколько инструментов:

• kotlinx.coroutines: основной runtime для suspend/coroutine/Flow;

• Arrow: функциональные типы, Either, Raise, typed errors, resource-style паттерны;

• Ktor + coroutines: практический backend-стек на suspend;

• Reactor interop: в Spring/Kotlin часто приходится жить на границе Mono/Flux и suspend;

• Result/Either-библиотеки: локальное решение typed errors без полного effect runtime.

Нужен ли Kotlin отдельный аналог ZIO runtime? Обычно нет, если речь про обычный backend. Coroutines уже закрывают runtime-часть: лёгкие задачи, cancellation, structured concurrency, dispatchers.

Но если хочется именно ZIO-подхода: программа как значение, typed environment, typed error, единая алгебра эффектов, то Kotlin из коробки этого не даёт. Можно приблизиться через Arrow и дисциплину, но получится не то же самое, что ZIO в Scala.

Короче:

Kotlin coroutines - уже стандартный runtime конкурентности.
Arrow - функциональные кирпичи поверх Kotlin.
ZIO-like единого центра в Kotlin-мире нет, потому что язык пошёл другим путём.

13. Что с thread pools после всего этого

Я бы не хоронил thread pools. Это слишком удобный и нужный инструмент.

Просто раньше pool часто отвечал за всё сразу:

• экономил потоки;

• ограничивал параллелизм;

• был очередью;

• защищал ресурс;

• отделял CPU от blocking I/O.

После Loom часть ответственности уходит. Экономить потоки для I/O-bound задач уже не так важно, если можно создать virtual thread на задачу. Но ограничивать ресурсы всё равно нужно.

Если БД держит 50 соединений, то 100 000 virtual threads не расширят БД магическим образом. Они просто дружно встанут в очередь к connection pool.

И это, кстати, нормальная граница применимости. Виртуальные потоки не отменяют физику.

Если вам близки темы разработки, рефакторинга, архитектуры и стартапов, буду рад видеть вас в моём Telegram-канале.

Вывод

Современная JVM-конкурентность не свелась к одному победителю. Java сделала дешевле привычный Thread. Kotlin вытащил приостановку в suspend и coroutine runtime. Scala/ZIO построила модель вокруг эффекта и fibers. Clojure зашёл с другой стороны: меньше изменяемого состояния, больше маленьких coordination primitives и свободный доступ ко всему JVM-хозяйству.

А thread pools никуда не исчезли, просто перестали быть единственным способом выжить под нагрузкой.