Иван Углянский - Thread Wars: проект Loom наносит ответный удар

Ближайшая конференция - JPoint 2025, 3-4 апреля (Москва + трансляция).
Подробности и билеты: jrg.su/T2zfbS
- -
На фоне приближающегося к релизу проекта Loom в Java-мире только и разговоров, что о корутинах да о легковесной многопоточности!
Но ведь Java на этом поле далеко не первая, скорее наоборот: это один из последних современных языков, где добавляют корутины. Так что же, мы просто получаем в точности то, что уже есть у соседей? Отличаются ли чем-нибудь корутины в Java от корутин в Kotlin? А от горутин в Go? Наши корутины будут лучше или хуже? И почему их так долго делают, раз в других языках все уже давно есть?
В этом докладе осознаем место наших корутин в мире, для чего разберемся в истории вопроса. Обсудим, как решение о реализации одной фичи может повлиять на облик всего языка программирования, сравним реализации корутин в разных языках и, конечно, закопаемся в кишочки проекта Loom.
Скачать презентацию: squidex.jugru....

[@Alex-gx2sz]

Лучший доклад по луму

[@RexerNotes]

Я человек простой: вижу Углянского выступление - ставлю лайк.

[@averv]

Отличный доклад, спасибо!

[@НикитаЗамалютдинов]

Мощный доклад

[@klerg321]

Reactor красивее чем Future, ахахаха. Особенно круто, что большие цепочки map сказываются на перформансе. Синки это бомба! А еще круто с пустыми Mono. Очень интуитивно, что не происходит ничего, и вообще к сложно отлавлавлемым багам не приводит. switchIfEmty для throe ошибок в случае тоже огонь Ну и невозможность нормально залогировать тела запрос/ответов тоже бомба!

[@oleksandrvasylchenko316]

Классный доклад!

[@maksmephi]

Большое спасибо за отличный доклад! Очень просто и понятно)

[@dmarsentev]

Спасибо!

[@luckyshaqqq]

кто понял какая цена ошибки если ЦПУ интенсив задачу поручить виртуальному потоку и можно ли сделать ковеер, чтоб незаконченные задачи витруал автоматом делегировались в не-виртуал. спасибо

[@ivanshka1759]

Цена ошибки -- производительность. ЦПУ интенсив таска надолго забирает себе один из воркеров, и тогда получается, что оставшиеся таски будут выполняться другими воркерами. Пример из жизни: это почти тоже самое, что и выполнение большой задачи-ебошки, на которую изначально отправили 4 человек, но потом одного отправили хер пойми куда делать че т другое. И вот остались 3 грустных чела с почти тем же объемом работы.

[@saturnuzz]

Вопрос - зачем cpu intensive code пытается пытаться параллелить? Какая цель?

[@qoqok]

Можно ошибочно допускать такой код к исполнению на виртуальных потоках. В идеале хочется, чтобы рантайм помог в такой ситуации и сам снял поток с исполнения. Технически такая приостановка виртуального потока мало чем отличается от приостановки для сборки мусора и ее сделать должно быть просто. Но, видимо, есть места, например, в недрах рантайма, где вытесняться совсем не хочется, а определить такие места достаточно трудно.

[@xotamxudoyberganov5847]

epoll na windows net tolko na linux

[@conandoyle1859]

gc - garbage collector, КЦ - из фильма кин дза дза

[@bananasba]

Прям так сильно отличается от сишарпа )

[@maksim.zheravin]

Интересно, виртуальные потоки можно привязать к конкретному физическому потоку? или loom-овский планировщик раскидывает их как захочет и повлиять на это в настоящей реализации никак нельзя?

[@ZhekaKozlov]

Нет, привязать никак нельзя. Более того, вы даже не можете узнать, на каком потоке-носителе запущен текущий виртуальный поток: The identity of the carrier is unavailable to the virtual thread (JEP 444). Виртуальные потоки и потоки-носители логически независимы.

[@yuryburkouski]

@@ZhekaKozlov ((VirtualThread) Thread.currentThread()).carrierThread ?

[@MegaAnufriev]

Отличный доклад. В rust async-await читается намного короче.

[@yuryburkouski]

чем короче? тут вы лишней буквы не пишете, кроме кода создания пула, который может быть вообще внутри потрохов фреймворка, типа спринга. В go короче, но в java не любят добавлять новые ключевые слова ну и хочется все же как-то случай ошибки обработать

[@bananasba]

По-хорошему, надо было делать async/await и выкинуть постепенно все легаси, но переписывать килотонны энтерепрайза слишком дорого, поэтому мы обложимся теперь костылями, будет что спрашивать на собесах!

[@zeroanyway]

Че хорошего в async/await?

[@yuryburkouski]

вам же первую часть доклада рассказывали почему async/await плохая идея, собственно я прочувствовал это на себе, когда сел писать на ts. сидишь и правшь код по стеку вызова. и тогда надо дублировать методы стандартной библиотеки и старый код не получит никаких преимуществ новой jvm. Костыли, которые дорого и красиво продали, раз вы тут не первый с таким странным предложением…

[@alexgorodecky1661]

Async/await это и есть костыль. В Java все правильно сделали

[@bananasba]

Я писал и на джаве и на сишарпе и на тайпскрипте, никаких особо проблем с асинком нет, он явный и понятный, работает предсказуемо. Переводил проект на асинки и это была рутина, минимум проблем и что важно, это можно делать постепенно, не надо переключать рантаймв какой-то режим и переписывать все сразу. Будь джава новым языком я бы согласился и с новым подходом. Существующие приложения не смогут получить никаких плюсов, их все равно придется переписывать и это нереально по затратам и сложности, понадобится еще поддержка в серверах, фреймворках, либах, драйверах баз - ждите вечность. И то и другое в случае джавы костыли, которые навсегда останутся в джвм. Отдельно скажу про именование классов и методов - в джаве это делают максимально неинтуитивно, че стоит только калька с линкью.

[@yuryburkouski]

​@@bananasbaв спринге вы одной пропертей включаете обработку запросов через виртуальные потоки, о каком переключении режимов рантайма вы говорите? о какой долгой миграции? существующие приложения получают плюсы, вам это показали и объяснили, вы или ничего не делаете и сетапите проперти, или на самом верху в коде инициализации потока меняете код. а не правите пол проекта async-await раком. я вот писал на ts и мне async await именно по этой причине не понравился совсем и не знаю кому это может нравиться. и чтобы не сломать существующий код надо на каждый старый блокирующий метод завести рядом новый - асинхронный. В общем это в сумме полностью бредовая идея, которая не имеет ни одного плюса по сравнению с loom, кроме того, что вам лично удобно из-за привычки ;) драйвера вам перепишут, не волнуйтесь, заменить synchronized задача для джуна. отдельно скажу, что понятия не имею о каком правильном именовании классов и методов вы говорите.

[@Alexander-mj3jk]

а если как в расте?