Size: a a a

2020 July 30

D

Dima in Kotlin JVM
Alexey Otts
а 3,4,5 таких вызовов?
будут добавлять функцию от n вызовов)
источник

AA

Anton Arhipov in Kotlin JVM
короч, хочу набор примеров сравнения корутин и rx 🙂
источник

AN

Alexander Nozik in Kotlin JVM
Я очень простой пример привел. Могу сейчас в коде покапаться. Если в функции несколько асинхронных операций, в рхе там начинается ад на синглах
источник

AO

Alexey Otts in Kotlin JVM
Dima
будут добавлять функцию от n вызовов)
:peka:
источник

D

Dima in Kotlin JVM
.zip(action1, action2, (r1, r2) -> {})
источник

AA

Anton Arhipov in Kotlin JVM
когда говорят "это проще" или "это читаемей" - пахнет субъективщеной и личными преференциями. для апологетов другого подхода это выглядит как фанбойство
источник

AN

Alexander Nozik in Kotlin JVM
Anton Arhipov
короч, хочу набор примеров сравнения корутин и rx 🙂
А я говорю на самом деле не про рх, а про то места, где рх кончается. Корутины существенно шире. Это позволяет их бесшовным образом стыковать с реактивными стримами. Если мы говорим строго о реактивных стримах, то они почти один в один. За одним исключением. В корутины можно в любой момент добавить оператор, не ломая совместимость.
источник

D

Dima in Kotlin JVM
Alexander Nozik
Далее, берем преобразование со сложной суспенд логикой типа
map{res->
 val a = res.a.await()
 val b = res.b.await()
 a + b
}

на рхе это будет ад
не особо вижу разницы с этим
источник

D

Dima in Kotlin JVM
тут смешанный подход
источник

AN

Alexander Nozik in Kotlin JVM
Dima
.zip(action1, action2, (r1, r2) -> {})
А если их восемь?
источник

AO

Alexey Otts in Kotlin JVM
Anton Arhipov
когда говорят "это проще" или "это читаемей" - пахнет субъективщеной и личными преференциями. для апологетов другого подхода это выглядит как фанбойство
Да вроде тут больше про то как мозгу удобнее

Императивный последовательный код читается проще чем fluent api, тем более с вложенными вызовами
источник

D

Dima in Kotlin JVM
Alexander Nozik
А если их восемь?
функция от n
источник

AA

Anton Arhipov in Kotlin JVM
Alexander Nozik
А я говорю на самом деле не про рх, а про то места, где рх кончается. Корутины существенно шире. Это позволяет их бесшовным образом стыковать с реактивными стримами. Если мы говорим строго о реактивных стримах, то они почти один в один. За одним исключением. В корутины можно в любой момент добавить оператор, не ломая совместимость.
мне кажется что корутины не шире, а покрывают другой набор, который с rx-ом где то пересекается, а где-то - неочень
источник

D

Dima in Kotlin JVM
так же как у тебя 8 локальных варов
источник

AN

Alexander Nozik in Kotlin JVM
Dima
функция от n
Восемь элементов подождать и сложить. Асинхронно
источник

AO

Alexey Otts in Kotlin JVM
Anton Arhipov
мне кажется что корутины не шире, а покрывают другой набор, который с rx-ом где то пересекается, а где-то - неочень
+
источник

D

Dima in Kotlin JVM
я не вижу разницы
источник

AA

Anton Arhipov in Kotlin JVM
Alexey Otts
Да вроде тут больше про то как мозгу удобнее

Императивный последовательный код читается проще чем fluent api, тем более с вложенными вызовами
ну вот я про это же - как мозгу удобнее. у всех мозг же разный
источник

AO

Alexey Otts in Kotlin JVM
Anton Arhipov
ну вот я про это же - как мозгу удобнее. у всех мозг же разный
Но развивается то примерно в одних условиях) Книги там, тетрадки
источник

ПФ

Паша Финкельштейн... in Kotlin JVM
Anton Arhipov
мне кажется что корутины не шире, а покрывают другой набор, который с rx-ом где то пересекается, а где-то - неочень
корутины — асинхрнность, а не реактивность
источник