Как стать автором
Обновить

Особенности сред исполнения различных систем эффектов в Scala

Уровень сложности Средний
Время на прочтение 16 мин
Количество просмотров 3.2K
Всего голосов 15: ↑15 и ↓0 +15
Комментарии 14

Комментарии 14

С project loom можно остановиться на начале статьи и использовать классическую модель с потоками. Вся фишка виртуальных потоков в том, что они по семантике практически не отличаются от обычных thread. Ну и кстати, они уже полноценно поддерживаются в последней java.

создатель зио считает, что зио и лум должны существовать, где лум дает платформу, а зио — удобное, безопастное API поверх — https://www.youtube.com/watch?v=9I2xoQVzrhs

Это не создатели Реактора же. Докука, насколько знаю, очень активный проповедник реактивщины, но к созданию Spring Reactor отношения не имеет.

Но не суть, на самом деле других вариантов у реактора и нету, т.к. он уже стал частью Spring и никто его в ближайшее время выпиливать оттуда не будет. А вот будут ли им пользоваться это вопрос.

Он член команды Реактора, активно в него контрибьютящий.

Пользоваться будут, у меня не малейших сомнений по этому поводу. Виртуальные потоки - это низкий уровень абстракции, на котором разумно работать только системным программистам, как раз разрабатывающим такое, как Reactor, ZIO, Akka и т.п.

Виртуальные потоки - это низкий уровень абстракции, на котором разумно работать только системным программистам, как раз разрабатывающим такое, как Reactor, ZIO, Akka и т.п.

Виртуальные потоки с точки зрения использования ничем не отличаются от обычных. А на обычных потоках сделано столько всего, что страшно даже представить. И вот теперь все, что уже было написано на thread-ах, очень легко может стать неблокирующим. Не без нюансов конечно, но все равно выглядит как очень привлекательная тема. Много людей идут в реактивщину только за неблокирующим api (собственно как и автор статьи), им не нужно backpressure и прочее. И вот такие люди могут получить что хотят привычными средствами.

Я со времён Java 1.4 очень редко вижу, чтобы кто-то использовал Thread в прикладном коде, если только в каких-то мелких задачах.

Так вовсе не обязательно явно использовать Thread. Есть вот старый добрый Spring MVC, который уже стал практически стандартном для бэка на Java, в нем теперь можно писать все тот же простой понятный синхронный код и не иметь проблем с блокирующим io. Более того, уже написанные приложения, могут легко стать неблокирующими. И все это без загонных абстракций и с нормальным дебагом.

Да, вы правы. Я только рад буду, если производительность начнёт даваться без усилий и станет легче нанимать разработчиков. Пока же считаю, что люди склонны переоценивать значимость Loom, видеть в виртуальных потоках серебряную пулю и игнорировать, что у них тоже есть свои нюансы, как и у любого инженерного решения. Впрочем, время покажет.

Что значит "в прикладном коде"? В смысле, я скажем когда писал под JavaEE, тоже про такое слово Thread особо и не слышал, потому что они прятались внутри контейнера. Ну то есть да, это довольно низкий уровень абстракции (даже с учетом java.util.concurrent, и множества появившихся там примитивов синхронизации, Executors и т.п.). Но в тоже время, прикладной код активно использует фреймворки, типа скажем Apache Camel, где внутри уже есть очереди, потоки и много чего еще. И это сами по себе скорее большие проекты, а не мелкие как раз. Apache Camel или скажем Spring — это прикладной код, или системный? Я бы пожалуй сказал, что это что-то среднее.

Разработка фреймворков, библиотек и инфраструктурных сервисов - это всё системное программирование. Spring, ZIO и Camel находятся примерно на одном уровне абстракции. Их разработчикам использовать потоки - нормально. Разработчикам же пишущим код с использование Spring, ZIO и Camel для решения конкретных задач конкретного бизнеса использовать потоки напрямую не стоит.

Ну, просто есть вполне устоявшийся термин middleware.

И? Термины ничего не меняют, если человек пишет CRUD на Spring или интеграционный компонент на Camel и в его коде появляется Thread, то скорее всего он что-то делает не так.

да не, я скорее про то, что все-таки Spring или там Camel это нечто среднее между системным и прикладным программированием. Системное в данном случае — это уж скорее сделать какие-то легковесные потоки для Java, в рамках JRE.


в его коде появляется Thread, то скорее всего он что-то делает не так.

Ну да, но это вы скорее про отличия прикладного программирования от того, что я бы называл middleware. Всеж какая-никакая, а разница есть между всеми тремя уровнями.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий