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

No video

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

Рет қаралды 14,471

Күн бұрын

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

Пікірлер: 30

@Alex-gx2sz Жыл бұрын

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

@averv Жыл бұрын

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

@RexerNotes Жыл бұрын

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

@user-uc1yt7fu8j Жыл бұрын

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

@maksmephi Жыл бұрын

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

@dmarsentev Жыл бұрын

Спасибо!

@klerg321 Жыл бұрын

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

@oleksandrvasylchenko316 8 ай бұрын

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

@conandoyle1859 23 күн бұрын

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

@xotamxudoyberganov5847 Жыл бұрын

epoll na windows net tolko na linux

@bananasba Жыл бұрын

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

@luckyshaqqq 11 ай бұрын

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

@ivanshka1759 10 ай бұрын

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

@saturnuzz Жыл бұрын

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

@qoqok Жыл бұрын

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

@bananasba Жыл бұрын

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

@zeroanyway Жыл бұрын

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

@user-md2fk3jj1e 6 ай бұрын

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

@alexgorodecky1661 6 ай бұрын

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

@bananasba 6 ай бұрын

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

@user-md2fk3jj1e 6 ай бұрын

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

@maksim.zheravin Жыл бұрын

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

@ZhekaKozlov Жыл бұрын

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

@user-md2fk3jj1e 6 ай бұрын

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

@MegaAnufriev Жыл бұрын

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

@user-md2fk3jj1e 6 ай бұрын

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