Ну бенчмарки прям радуют.
тут говорят, что корутины котлина дешевле по памяти, они сразу заставляют писать код правильно и четко из-за структурного канкаренси, да и вообще - реализация корутин на уровне котлин компайлера с разноцветным кодом - это благо, которое позволяет оптимизировать код, не то что VM реализация потоков. Выходит, лум и не нужен https://www.youtube.com/watch?v=zluKcazgkV4
Ну он нужен как минимум чтобы забыть про чудесный мир асинхронного IO и интегрироваться с существующим кодом без боли. А, и конечно же отладка без адской боли и плясок с бубном.
Спасибо, что Елизаров плотно продолжает держать в курсе, но разноцветный код говно, корутины ничего не могут предложить для блокирующего кода, кроме как выделенный пул
оооо питониста порвало
Питониста?
там на последней минуте про их стратегию про блокирующий код - воспользоваться проектом Loom внутри реализвации Dispatcher.Io
Да там старье, пересказал то, что давно и так обсуждалось.
Зачем в таком случае вообще корутины для бэка
Казалось бы, а зачем вообще Dispatchers.IO, если перечень операций, которые блокируют поток ОС на непредсказуемое время, сильно уменьшается
Роман говорил про интеграцию с легаси либами. ну и disk IO никуда не делось. Правда наверно никто базы данных на котлине не пишет
Ну если только "легаси либа" ходит в нативный мир. synchronized всё равно доделают. А с IO любого вида должна разбираться JVM. Вот на андроиде...
Ждём следующий эпизод с выходом JEP 428
в докладе кста есть упоминание про него. Роман говорит, что JEP не выйдет вместе с лумом, разработчики начнут писать код, как им вдумается, и наплодят кучу мусора. Интересно, конечно, почему в списке JEP для 21 версии структурной конкуретности нет даже в пропозалах https://openjdk.org/projects/jdk/21/
Потому что оно ещё в инкубаторе, и до релиза далековато. Я воспринимаю эту речь как "вот будет там structured concurrency из коробки - тогда и поговорим, а пока это тупо треды как в корутинах ранних версий". Что-то в этом есть, но не раскрыта тема того, что же будет в будущем, когда это таки доделают.
Ну т.е. в го не наплодили(немного нечестный пример, но все же), а мы наплодим. Роман, конечно, крутой, но такое чувство, что здесь он лукавит.
Сейчас как-то иначе?
https://openjdk.org/jeps/8306641
В го много лет обходились без этого, а сейчас прикрутили это сбоку. Роман пояснил, что такой подход неизбежно приводит к тому, что не все пишут код как надо, потому что это сложнее, чем просто сделать go myfunc() и всё. Тут вопросов нет, звучит убедительно, как по мне. Но вот про JEP как будто съехал с темы, пояснив только про гошку)
Без чего в go много лет обходились?
Структурной конкуретности
Сразу была из коробки
В го? Через какие конструкции?
Обсуждают сегодня