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

(лева руля) мне был бы интересен, если это не слишком обременительно )

1. Всё в кучу. Single — это фьюча (CompletableFuture), Flowable — поток событий (канал), BehaviorSubject — проперти. Мне кажется, это разные концепции и их лучше не сваливать вместе. 2. Неудачные интерфейсы. Single != Observable, Completable != Single<Nihuya>. 3. Монолит. 10к методов, стопицот комбинаторов. Обычно из этого всего используется только map и flatMap. Давно пора нарезать на модули. 4. Плохо ложится на ОО язык. Операторы захардкожены в классах Observable/Single, свои не добавить. В Java нужно было использовать декораторы (new MappedObservable(new DebouncedObservable(getObservableSomewhere(), 500, MILLISECONDS), ::mapperFunction)), в Kotlin можно прокинуть создание декораторов через extension-функции (getObservableSomewhere().debounce(500, MILLISECONDS).map(::mapperFunction)). 5. Стрёмные subscribeOn/observeOn. Они возвращают такой же обзёрвабл. Непонятно, например, к чему приведёт obs.subscribeOn(io()).subscribeOn(mainThread()). subscribe/observe должны возвращать обзёрвабл другого типа, который уже нельзя подписать ни на какой шедулер.

(лева руля) мне был бы интересен, если это не слишком обременительно )

6. Нет read-only интерфейса для BehaviorSubject, нет возможности прочитать текущее значение из какого-нибудь subj.map { ... }.

Ну это всё минусы отдельной реализации и детали. А если нужна базовая асинхронщина, то какой бы прекрасной RxJava ни была, она не сильно много профита привнесёт.

круто, спасибо огромное )

Еще из минусов, что RxJava заточена под Java, а RxKotlin всего лишь сахарная-обертка, без учета специфики языка. К примеру на RX.NET (полностью написан на C#) вообще нет Completable/Single, потому что они не нужны в языках с async/await.

Еще из минусов, что RxJava заточена под Java, а RxKotlin всего лишь сахарная-обертка, без учета специфики языка. К примеру на RX.NET (полностью написан на C#) вообще нет Completable/Single, потому что они не нужны в языках с async/await.

RxJava при этом очень плохо ложится на Java.

Еще из минусов, что RxJava заточена под Java, а RxKotlin всего лишь сахарная-обертка, без учета специфики языка. К примеру на RX.NET (полностью написан на C#) вообще нет Completable/Single, потому что они не нужны в языках с async/await.

Котлин из коробки не содержит корутин.

Котлин из коробки не содержит корутин.

Содержит. :)

Содержит. :)

С каких пор?)

С каких пор?)

Корутины — это языковая фича. kotlinx.coroutines — библиотека, построенная поверх этой фичи.

Корутины — это языковая фича. kotlinx.coroutines — библиотека, построенная поверх этой фичи.

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

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

А как библиотека их использует? :)

Ну это ж уже не из коробки

А как библиотека их использует? :)

Я не знаю, но не припомню использование корутин без библиотеки.

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

Добавляешь к сигнатуре функций ключевое слово suspend и все ?

Добавляешь к сигнатуре функций ключевое слово suspend и все ?

В язык уже разве есть встроенные места, из коробки, где можно использовать суспенды? Мне казалось, что все лаунчи и пр. в библиотеке.

Добавляешь к сигнатуре функций ключевое слово suspend и все ?

И дальше студия пишет тебе что надо подключить карутины

И дальше студия пишет тебе что надо подключить карутины

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

В язык уже разве есть встроенные места, из коробки, где можно использовать суспенды? Мне казалось, что все лаунчи и пр. в библиотеке.

Вынесение всех вещей, которые можно реализовать в библиотеке, в библиотеку — это одна из основных фишек корутин. Которая, к примеру, помогает щас людям в удобном для них темпе корутины в K/N имплементить — на уровне компилятора они там давно уже есть, kotlinx.coroutines ещё в процессе портирования, а те, кто хотели, успели пощупать там корутины и без неё. Суспенды из коробки вполне можно использовать с buildSequence при необходимости. Ну и да, вообще странно возмущаться необходимостью подтягивать kotlinx.coroutines, таская за собой в явном виде stdlib ;)

Что вообще имелось ввиду под "В язык уже разве есть встроенные места, из коробки"?

Вынесение всех вещей, которые можно реализовать в библиотеке, в библиотеку — это одна из основных фишек корутин. Которая, к примеру, помогает щас людям в удобном для них темпе корутины в K/N имплементить — на уровне компилятора они там давно уже есть, kotlinx.coroutines ещё в процессе портирования, а те, кто хотели, успели пощупать там корутины и без неё. Суспенды из коробки вполне можно использовать с buildSequence при необходимости. Ну и да, вообще странно возмущаться необходимостью подтягивать kotlinx.coroutines, таская за собой в явном виде stdlib ;)

О каком возмущении речь?

О каком возмущении речь?

Ну вы пишете, что "из коробки" корутины использовать нельзя, что их "нет" в языке.

Ну вы пишете, что "из коробки" корутины использовать нельзя, что их "нет" в языке.

Да. Возмущение тут причем? Не путай:)

Да. Возмущение тут причем? Не путай:)

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

Да. Возмущение тут причем? Не путай:)

Я кстати долго пользовался корутинами на android без kotlinx, просто написав пару оберток повер asynctask

Вероятно, в каких-то редких случаях может быть полезно не тянуть за собой весь stdlib и kotlinx.coroutines. От тех же плюсов оторвать stdlib намноооого сложнее.

Точнее от C сложнее, от C++ почти невозможно.

Я кстати долго пользовался корутинами на android без kotlinx, просто написав пару оберток повер asynctask

Я все равно не считаю, что это полноценный функционал из коробки, пока он эксперемениальный.

Хотя сейчас может там все не так страшно, не скажу

Вероятно, в каких-то редких случаях может быть полезно не тянуть за собой весь stdlib и kotlinx.coroutines. От тех же плюсов оторвать stdlib намноооого сложнее.

Пробовал отрывать stdlib от Kotlin?

Хороший ли курс как для быстрого вливания? https://videos.raywenderlich.com/courses/128-programming-in-kotlin/lessons/1

Пробовал отрывать stdlib от Kotlin?

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

Но да, заглядывал только по мере надобности.

Окей, Caused by: java.lang.ClassNotFoundException: kotlin.jvm.internal.Intrinsics. :)

Ну и kotlin.Unit нужен, и TypeIntrinsics, и много чего ещё

Я наивно думал, что core/builtins со своими стрингами и юнитами не относится к stdlib. Oh well.

String/List/MutableList и правда не существует. А Unit и Intrinsics — вполне.

Надо отдать должное, стандартная библиотека - крошечная. Хуже с рефлектами, но и там не фатально.

Ну в сравнении с раздутыми монолитами вроде RxJava — крошечная, да.

По сравнению с чем угодно крошечная, LogBack уже сравнимых размеров

По сравнению с чем угодно крошечная, LogBack уже сравнимых размеров

kotlinx.coroutines меньше Protobuf nano меньше Gson меньше Okio + OkHttp + Retrofit меньше

Протобуф у меня полный, он точно больше. Кстати спасибо за идею.

пока вот такая конструкция вроде работает val p = window.fetch("https://jsonplaceholder.typicode.com/posts/1") p.then { resp -> resp.text().then { text -> setState { post = JSON.parse(text) } } } 2 промиса смущают

можешь попробовать вкрутить https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/runtime_usage.md#dynamic-object-parser-js-only , если уж у тебя там сразу dynamic

Ok, попробую, спасибо за наводку)

Я все равно не считаю, что это полноценный функционал из коробки, пока он эксперемениальный.

странное заявление, язык должен иметь базовые вещи из которых ты делаешь большие, вот Си и С++, что они могуб без include ? Что может джс без своих фраемворков ? Корунтины вынесены в библиотеку что бы их можно было потом выпилить при случае, и не тащить как джава например, и имхо, корунтины не всегда нужны

странное заявление, язык должен иметь базовые вещи из которых ты делаешь большие, вот Си и С++, что они могуб без include ? Что может джс без своих фраемворков ? Корунтины вынесены в библиотеку что бы их можно было потом выпилить при случае, и не тащить как джава например, и имхо, корунтины не всегда нужны

Только что мы выяснили, что они встроенны в язык. Бадум.

Programming Offtop Правило только одно, не спамить https://t.me/pofftop

Есть у кого на примете опен соурс проекты на ktor и/или exposed?

Есть у кого на примете опен соурс проекты на ktor и/или exposed?

https://github.com/JavaneseOnline/ ktor + kwery

Многие не любят jvm за то, что она много оперативы ест. Если в кторе появится поддержка kotlin native, прога, написанная на ktor с использованием натива будет есть меньше памяти и будет ли она шустрее?

Многие не любят jvm за то, что она много оперативы ест. Если в кторе появится поддержка kotlin native, прога, написанная на ktor с использованием натива будет есть меньше памяти и будет ли она шустрее?

Странное понятие "шустрее"

Там ток подсчет ссылок пока

Многие не любят jvm за то, что она много оперативы ест. Если в кторе появится поддержка kotlin native, прога, написанная на ktor с использованием натива будет есть меньше памяти и будет ли она шустрее?

Джвм для сервера не много ест

Лол

Лол

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

Любопытно

ERROR: S client not available

lol

Лол

Рантаймовые оптимизации JVM на однотипных операциях, таких как обработка серверных запросов потенциально мощнее, чем опимизация нативного кода. Натив побеждает на короткоживущих маленьких програмках, но для сервера ситуация обратная. Про память боее сложно, JVM ее не экономит и в среднем будет использовать в полтора-два раза больше, чем нативное приложение. Но когда мы говорим о нативе, мы говорим о Rust, а не о С++, потому что в последнем случае, написать человеческое управление памятью в большом проекте так, чтобы оно было эффективнее, чем JVM-GC очень и очень сложно.

Очень-очень ждем. Ходят слухи, что есть внеутренний секретный мост между KN и KJVM. Только недокументирвоанный. Очень нужная фича. К сожалению, от С++ не спасет, но хоть будут обертки для голого С без SWIG.

С чего бы там быть gc? Там вроде как подсчет ссылок

Я пока не видел, чтобы кто-то говорил о GC.

Ну как бэ можно скомпилить на целевой машине, так вобщем то и делают обычно

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

А как по вашему тогда это делает JIT?

А как по вашему тогда это делает JIT?

Только то что умеет. Если бы он умел все, тогда ты парням не пришлось писать jit под Эльбрус

Я это к тому, что JIT настолько же не умён как компиляторы, которые оптимизируют код под железо

JIT может делать спекулятивные оптимизации

Я это к тому, что JIT настолько же не умён как компиляторы, которые оптимизируют код под железо

Тут прикол в том, что на том же Эльбрусе vliw и там ему нужно быть достаточно умным. Чтоб генерировать нативный код иначе код будет малопроизводительный.

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

У gcc, llvm куча ключей оптимизации под разные архитектуры и платформы

да и сам llvm по сути тоже jit

У gcc, llvm куча ключей оптимизации под разные архитектуры и платформы

Не знаю, на сколько все это работает. Сам никогда не пробовал и с нативным софтом стараюсь связываться по-минимуму. У меня друг этим занимался и он уверял, что одних ключей не хватает, должны быть директивы компилятора внутри кода.

да и сам llvm по сути тоже jit

Ни разу. LLVM не может оптимизировать ничего на основе рантаймовой информации.

а зачем тогда он, чем он лучше gcc?

Не знаю, на сколько все это работает. Сам никогда не пробовал и с нативным софтом стараюсь связываться по-минимуму. У меня друг этим занимался и он уверял, что одних ключей не хватает, должны быть директивы компилятора внутри кода.

Ну есть условия при которых компилятор заинлайнит код (:

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

Ну есть условия при которых компилятор заинлайнит код (:

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

IR?

Intermediate representation

биткод

а, теперь понял в чём соль

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

Ну просто модификатор inline не всегда работает, поскольку компилятору лучше знать. Но его можно мотивировать это сделать

Вроде есть JIT на основе LLVM, Julia даже на нем работает, но годится ли он для чего-то кроме Julia, я не знаю.

Не знаю, на сколько все это работает. Сам никогда не пробовал и с нативным софтом стараюсь связываться по-минимуму. У меня друг этим занимался и он уверял, что одних ключей не хватает, должны быть директивы компилятора внутри кода.

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