Comments 3
А можете чуть подробнее расписать про Zio - какую проблему он решает по сравнению с Kotlin + Virtual Threads (без coroutines)?
Основная проблема классических потоков (и в этом необходимость асинхронных примитивов) была в переключении контекста приложения. Виртуальные потоки это убрали, а потому и проблема ушла.
Собственно, теперь можно обрабатывать многопоточный код в классическом виде - это и работает быстрее, и читается легче, плюс стек вызовов стандартный, а потому дальнейшая диагностика улучшается.
С одной стороны да, виртуальные потоки решают похожую проблему как и ZIO fibers.
Но ZIO идёт сильно дальше. оно описывает всю effectful-программу через тип ZIO[R, E, A], где видно зависимости R, возможную ошибку E и результат A.
То есть за счёт того, что программа( вообще вся программа, все действия ) описана как набор значений ZIO[R, E, A], runtime может управлять её выполнением: планировать fibers, отменять их, делать retry/timeout, следить за ресурсами и сохранять структуру параллельных задач.
судя по вашему описанию это очередная попытка сделать Erlang/OTP, но проблема в том, что на jvm это нормально не реализовать из-за дизайна jvm. В Erlang у каждого актора свой gc - получаем очень маленькую лейтенси (то что часто надо для канкаренси), актор не может повлиять на соседей (а у нас их очень много), общая память где значения иммутабельные, а не "как бы иммутабельные" (не можем сломать систему). Т.е. я не очень понимаю зачем это, попытка сделать апи, для jvm которая не предназначена для таких задач. собственно и go тоже с примерно похожим дизайном не предназначен и дискорду пришлось переписывать соотв часть кода на elixir
Сравнение моделей конкурентности JVM языков: Нужен ли еще ThreadPool после coroutines, ZIO и Virtual Threads?