или очнредь

т. е. TPE из java concurrent — тоже реактивщина?

суть что изменения распространяются автоматически

нет

или акка

Или как React или Elm

Kotlin/JS

а для ktor.io ?

возможно. тут я не очень компетентен

а для ktor.io ?

Kotlin/JVM

думаю react + reduce или что там сейчас вместо подходят под определение

Kotlin/JVM

Спасибо, а если хочу совместить ?

Реактивный и нереактивный подход отличается примерно тем чем игра в пинг понг отличается он перемещения кучи шариков с пункта А в пункт Б. Все взаимодействия двусторонние, и разбиты на отдельные мелкие составляющие.

вот как раз нет

реаетивность не равно запрос ответ

Спасибо, а если хочу совместить ?

для моделей можно создать проект на Kotlin/Common и зависить от него

Спасибо, а если хочу совместить ?

два разных модуля, фронт и бэк

ок

Спасибо, а если хочу совместить ?

еще есть мулти платформ, но еще не доделано

еще есть мулти платформ, но еще не доделано

Я знаю, но там не относится к вебу. Я про то что если возможно соединить реакт (или же сам kotlin js) в ktor.io

Я знаю, но там не относится к вебу. Я про то что если возможно соединить реакт (или же сам kotlin js) в ktor.io

Каким образом? ktor работает на JVM, рекат — на JS.

Каким образом? ktor работает на JVM, рекат — на JS.

то есть сайт придится писать только на реакте или только на кторе ?

то есть сайт придится писать только на реакте или только на кторе ?

или без изоморфного рендеринга

?

то есть сайт придится писать только на реакте или только на кторе ?

а как иначе? у них разные цели

одно – вебсервер, другое – гуи фреймворк

одно – вебсервер, другое – гуи фреймворк

разве сайт это не их воплощение ?, то есть сайт соединяет это...

Ну типо пишешь гуи на реакте и пишешь сервер на кторе, для того же сайта.

и в чем вопрос?

Какой тип проекта создать если собрался сделать такой сайт )

gradle

многомодульный

используй Gradle. один модуль для ктора, другой для реакта, и третий для моделей

используй Gradle. один модуль для ктора, другой для реакта, и третий для моделей

третий лучше апи, не только модели а й все общие

Ок, соглашусь. Но что тогда называть рекативным?

https://www.reactivemanifesto.org/

https://youtu.be/G_HZUEY0Qwo

https://www.reactivemanifesto.org/

Может ты еще знаешь почему RxJava не FRP?

http://arrow-kt.io/

немного изврата

Да да, в скала чатике по ней уже прошлись ?

Да да, в скала чатике по ней уже прошлись ?

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

Да так поужасались реализации hkt и хранению тайпклассов в глобальной хешмапе. (впрочем ничего нового, тоже самое было и про kategory)

Может ты еще знаешь почему RxJava не FRP?

Rx это просто стримы и планировщики. Да и как вообще можно ставить в одном предложении functional programming и Java?

Rx это просто стримы и планировщики. Да и как вообще можно ставить в одном предложении functional programming и Java?

Ну там же java8-лямды ? Благодаря которым можно писать “декларативный код, который обрабатывает поток событий”.

Да так поужасались реализации hkt и хранению тайпклассов в глобальной хешмапе. (впрочем ничего нового, тоже самое было и про kategory)

Так это же и есть kategory, просто объединились ещё с funktionale

KEEP-87 заглох

Привет! У меня простой вопрос по корутинам. Скажем, у меня есть функция loadFileSync(url:String) , и есть массив из url. И я хочу вызвать много loadFileSync() (параллельно) и, дождавшись завершения всех загрузок, продолжить делать дальнейшие дейсвтия: urls.map { loadFileSync(it) } Наверное, можно заключить эту лямбду в async, а потом для всего этого вызвать много await-ов: urls.map { arr += async {loadFileSync(it)} } arr.map{it.await()} //а может и не будет работать А как это сделать правильно?

urls.map { url -> async(CommonPool) { loadFileSync(url) } }.map { it.await() }

получается шедулим все загрузки на CommonPool, обратно получаем Deferred, и потом ожидаем завершения всех.

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

если хочется прям чтобы очень оптимально, то можно посмотреть работу с каналами тут: https://github.com/tsydd/jprof-ny2018

Немного оффтоп, но наше джава комьюнbити проводило новогодний контест, и там нужно было посчитать кол-во упоминаний слова "java" на сайте сообщества jprof.by. Так вот из семи вариантов - 2 на котлине, и первое место занял тоже котлин вариант (ссылка выше), а еще он быстрее самого быстрого джавового в 5 раз, хотя либа jsoup была у многих)

Хм, ну мне оно и нужно, в принципе. Я просто почему-то думал, что есть что-то еще более очевидное , чем async/await, с учетом того, что результат loadFileSync не важен. Спасибо, посмотрю ?

ну в любом случае если нужно дождаться - то нужно делать await

можно последний map заменить на forEach

urls.map { url -> async(CommonPool) { loadFileSync(url) } }.forEach { try { it.await() } catch (e: Exception) { // handle } }

и добавить хоть какое-то логгирование, или убрать try/catch и падать в этом месте. но это уже от логики зависит

И не запускать I/O операции на CommonPool, а выделить пол это cachedThreadPool

Вопрос по ktor: при использовании NettyApplicationEngine можно как-то подкрутить SslContext (например, указать trust manager)?

я бы для файлов попробывал все таки https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.experimental.selects/select.html

предидущее решение как по мне ничем не отличается от блокируещего чтение в сингл тред пуле

я бы для файлов попробывал все таки https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.experimental.selects/select.html

Пример кода?

https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md#selecting-deferred-values

Это хороший способ обработать результат, но в задачке результат ведь не нужен.

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

await не блочит тред, но да - вычитка будет последовательная. но в задаче это не важно, т.к. там достаточно CompletableFuture.all(...promises)

И не запускать I/O операции на CommonPool, а выделить пол это cachedThreadPool

А откуда знание что cachedThreadPool это самое то для I/O?

Ну любой выделенный тред пул - лучшее место для io, чем CommonPool.

так вродь и комон пул забивать ио тож не по феншую?

В том примере - победителе кстати именно так: весь io выполняется на тред пуле okhttp, а обработка на CommonPool.

так вродь и комон пул забивать ио тож не по феншую?

Я могу с этим согласится, хотя если на CommonPool закидывать I/O через ManagedBlocker то разницы не будет ведь.

Другое дело что с корутинами так не получится сделать, наверно

Я могу с этим согласится, хотя если на CommonPool закидывать I/O через ManagedBlocker то разницы не будет ведь.

Как это?

https://stackoverflow.com/questions/37512662/is-there-anything-wrong-with-using-i-o-managedblocker-in-java8-parallelstream

А через netty можно было написать тут загрузку файлов? Он вроде бы вообще не блокирующий.

Можно, но не очень то полезно.

Прироста в скорости врядли добьемся, мне почему-то кажется, что даже будет хуже.

https://stackoverflow.com/questions/37512662/is-there-anything-wrong-with-using-i-o-managedblocker-in-java8-parallelstream

Вот тут конечно для стримов пример, и там как-то криво но чет лучше ничего не нашел

По сути ManagedBlocker говорит FJP когда выделить новый тред, потому что какой-то таск точно заблокирует тред в пуле

Ничоси.

Вот это фича. Не знал. Похоже это реально будет работать.

Сложно только и нифига не очевидно. Корутины и тред пулы все же понятнее.

А откуда знание что cachedThreadPool это самое то для I/O?

о ManagedBlocker не знал, ибо пришёл с андроида, а вообще логично же, что common pool можно заблокировать полностью, а cached pool -- нет, хотя много одновременных операций и будут очень неэффективны. я не спорю, что неблокирующий ввод/вывод -- наилучшее решение, но не везде его легко заиметь. потому имхо cached pool -- меньшее из зол.

о ManagedBlocker не знал, ибо пришёл с андроида, а вообще логично же, что common pool можно заблокировать полностью, а cached pool -- нет, хотя много одновременных операций и будут очень неэффективны. я не спорю, что неблокирующий ввод/вывод -- наилучшее решение, но не везде его легко заиметь. потому имхо cached pool -- меньшее из зол.

Вообще-то довольно просто: val IO = newFixedThreadPoolContext(10, "io")

fixed на 10 разве не забьётся 10ю блокирующимм операциями? Или я чего-то в этой жизни не понимаю?

Конечно. Но это ведь именно то, что нам и нужно.

я понимаю, что 640 КБ хватит всем, но наверное, зависит от конкретных кейсов.

Забьет. Вопрос в том что мы хотим, наплодить много тредов - что не ок, или сделать очередь + не так много тредов

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

А jdk.incubator.http.HttpClient работает через NIO?

Это же апи?

В смысле апи? Это из java9 Судя по сорцам jdk.incubator.http.HttpClientImpl$SelectorManager - кажется что через NIO

Тут еще в докладе Куксенко про него интересная информация, что несмотря на NIO, он все равно юзает cached-thread-executor для разных операций и на один запрос генерит до 12 тредов в нем. По этому лучше ему явно задавать Executors.newFixedThreadPool(2)

Вроде был какой-то оператор, как in только с обратным порядком, не?

А, всё, не так подошел к вопросу. Лист просто реверснутым делал.

downTo?

downTo?

ну это если по range гонять, а если а foreach style то да, вроде только список реверсить.

Тут еще в докладе Куксенко про него интересная информация, что несмотря на NIO, он все равно юзает cached-thread-executor для разных операций и на один запрос генерит до 12 тредов в нем. По этому лучше ему явно задавать Executors.newFixedThreadPool(2)

Где-то смотрел доклад как его оптимизировали. Это не тот случаем?

Да с jpoint