само собой столкновения с внешним миров не избежать но там это можно обходить например с помощью railway oriented development

Опять же через либу :)

? я думал в ядре будет

? я думал в ядре будет

Ну там компилятор + либы от JB

? я думал в ядре будет

думаю, в ядре — поддержка новых ключевых слов и операторов, а с помощью либ — реализации этого с помощью CompletableFeature и т. п.

ну CompletableFuture это отдельные потоки

а тут как раз таки все в одном потоке должно выполнятся со стейт машиной, не?

не

В скале я видел репу, https://github.com/scala/async Там поддержка корутин слабее чем в Котлин, например там только Future, а в котлине - любой тип)

а тут как раз таки все в одном потоке должно выполнятся со стейт машиной, не?

если я всё правильно понял, поток доходит до suspension point, задача передаётся другому потоку, а по завершении результат передаётся в continuation

и, соответственно, есть три части — "до", "параллельно" и "после"

ну так корутины ж как раз таки нужны чтобы не плодить потоки

а тут выходит что они поверх потоков работают, бред

если я всё правильно понял, поток доходит до suspension point, задача передаётся другому потоку, а по завершении результат передаётся в continuation

Там как создатель конкретной либы решит, так и будет. Можно кинуть потом в тредпул, можно поток создавать

а тут выходит что они поверх потоков работают, бред

ээ, нельзя загружать картинку пока рендерятся кадры

а тут выходит что они поверх потоков работают, бред

Все на джаве поверх потоков, вопрос в том как их использовать. Акка бежит поверх тредпула

в чем тогда отличие будет корутин от потоков?

Корутины — не потоки, а синтаксический механизм взаимодействия с ними.

Дошёл до момента, когда нужно загрузить картинку. Отдал задачу в пул, свернул future, побежал дальше в event loop. Отрендерил сотни кадров. Картинка пришла, продолжил future. Только весь этот зоопарк пишется, как синхронный код.

одно дело когда идут переключения контекстов между потоками, а другое дело когда программа сама контролирует стейты внутри потока и перебрасывает куда нужно. но спорить не буду, я не компетентен в этом)

одно дело когда идут переключения контекстов между потоками, а другое дело когда программа сама контролирует стейты внутри потока и перебрасывает куда нужно. но спорить не буду, я не компетентен в этом)

Создание потоков - дорого, переключение потоков на процессоре - дорого. Тред пул + очередь эффективно решает эти моменты

Собственно, переключение контекста не происходит, пока нет горы исполняемых потоков, конкурирующих за меньшее количество ядер

Создание потоков - дорого, переключение потоков на процессоре - дорого. Тред пул + очередь эффективно решает эти моменты

Всегда было интересно. Насколько дорого?

ну пока нет конкуренции на ядро то да

а если у тебя всего 4 ядра, или даже 2?

Ну, бывает. И всё равно, какие есть варианты, кроме как запустить отдельный поток для UI и отдельный для IO?

зависит от того как будет юзаться ядро при этом

В скале я видел репу, https://github.com/scala/async Там поддержка корутин слабее чем в Котлин, например там только Future, а в котлине - любой тип)

future и есть "любой тип" это обертка, которая явно показывает, что вон та штука будет когда-то доступна

для UI оно ж активно юзается на перерисовку

а IO наоборот не очень

Всегда было интересно. Насколько дорого?

http://ithare.com/infographics-operation-costs-in-cpu-clock-cycles/

future и есть "любой тип" это обертка, которая явно показывает, что вон та штука будет когда-то доступна

У нас много есть оберток которые Future

Я могу написать async\await для своей любимой

несколько фьючеров? Оо зачем?

Я могу написать async\await для своей любимой

O_o

это как джавовские mapToInt, тьфу-тьфу-тьфу?

Трололо)

Ты точно на скале пишешь? Твиттер стек юзал?

Напомни какая там future)

http://ithare.com/infographics-operation-costs-in-cpu-clock-cycles/

Например, function call гораздо быстрее RAM или L3. Предполагается, что код закеширован?

Ты точно на скале пишешь? Твиттер стек юзал?

не юзал их фьючура старше скаловской, с неё как бы и слизали

ещё есть, например, таски из скалаз, но это маргинальщина

плюс они туда-сюда конвертируются

Раз заговорили о микровещах. invokevirtual и invokeinterface на JVM различаются по скорости?

Ну или вот, Future, CompletableFuture, Deffered, ListanbleFuture

Небольшой списочек)

плюс они туда-сюда конвертируются

Я понял, напишем имплисит конверсию)

>Deffered deferred вроде

>Deffered deferred вроде

Да

>Future это спринговое которое, которое появилось раньше чем джавовое CompletableFuture?

В котлине можно сделать go) типо: for (x in y) go { foo(x) }

На основе корутин

>Future это спринговое которое, которое появилось раньше чем джавовое CompletableFuture?

Future - это джава утил

>Future это спринговое которое, которое появилось раньше чем джавовое CompletableFuture?

https://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Future.html

В скале вроде scala...Future

В котлине можно сделать go) типо: for (x in y) go { foo(x) }

пф, https://github.com/rssh/scala-gopher

На тему колличества оберток

Ну или вот, Future, CompletableFuture, Deffered, ListanbleFuture

и чем они отличаются? ты их все всегда используешь?

пф, https://github.com/rssh/scala-gopher

Так это на корутинах которые завезут в 1.1) Не нужны акторы для этого

и чем они отличаются? ты их все всегда используешь?

мне кажется их даже друг в друга нельзя сконвертить

У них один интерфейс

Но реализация очень сильно отличается

CompletableFuture собтсвенно и есть самая правильная футура

CompletableFuture еще и имплиментит CompletionStage

CompletableFuture собтсвенно и есть самая правильная футура

Таки да

ERROR: S client not available

Так это на корутинах которые завезут в 1.1) Не нужны акторы для этого

это одна из реализаций CSP, можно и на акторах, и на корутирах, и на чем угодно

Но много API дает Future

Тот же AWS SDK

CompletableFuture еще и имплиментит CompletionStage

Да, и вообще правильно говорить не CompletableFuture а CompletionStage.... но фиг с ним

И вот тут становятся очевидным плюсы реализации корутин в котлине)

И вот тут становятся очевидным плюсы реализации корутин в котлине)

можно подробнее?

И вот тут становятся очевидным плюсы реализации корутин в котлине)

че то нет

Ты пишешь await для любой футуры

Ты пишешь await для любой футуры

а как же flatMap?

используя оптимальную реализацию

у футур нет flatMap

В джаве)

используя оптимальную реализацию

что такое "оптимальная реализация", оптимальная для кого?

Ты пишешь await для любой футуры

совместимость со старым -- не плюс, а необходимость

что такое "оптимальная реализация", оптимальная для кого?

оптимальная для перформанса и с точки зрения использования

> совместимость со старым — не плюс, а необходимость в мемориз

оптимальная для перформанса и с точки зрения использования

я не маркетолог, дай технические детали -- что, как, куда

я не маркетолог, дай технические детали -- что, как, куда

https://github.com/Kotlin/kotlin-coroutines

Вот сюда

Да, Бреслава толк лучше посмотреть

а есть паперы какие или толки? код, да ещё и на котлине, читать не всегда хочется

Там прямо ссылка на толк в ридми

Правда уже устарело

С JVMLS

Сильно устарело?

я не следил

Ну с выходом M02 переделали)

так было не оптимально изначально, получается?

трололо)

судя по опросу только 251 человек из 875 понимают что такое scala и kotlin

так было не оптимально изначально, получается?

Аргументы закончились, пошли глупые набросы? ооок