то есть, если надо писать MPP IO например, нужно выкинуть java ByteBuffer и js ArrayBuffer/DataView и весь IO писать как-то с нуля что ли?
или что?

Антон как всегда не в курсе, но осуждает. Я думаю, что тут бесполезно тут с ним это обсуждать. Есть вещи, которые удобнее на котлине с нуля писать, но их не много. Я в Kmath принял следующую доктрину:
* Делаем АПИ
* Делаем не самую эффективную МПП реализацию, которая работает без внешних зависимостей
* Делаем обертки для вылизанных платформных реализаций в том же АПИ на случай, если есть необходимость иметь крутую реализацию.

ну вот я себе этот момент как раз не представляю. звучит как да - именно так

то есть, выкинуть все преимущества интеропа, и использовать kotlin как любой другой ЯП?
звучит как плохой план )

тогда объясни. вот есть жс либа для работы с amqp? там всюду нодовские апи типа require('net') и нодовские стримы. что дальше? есть какой-то волшебный кролик из платформенной шляпы который конвертирует это в некие универсальные апи?
аналогично с сишным grpc, там libuv работает с сетью. мпп libuv на айос портирует?

"волшебный кролик" - это разработчик, который напишет обёртки
например, как есть ktor-io/kotlinx-io/okio, который как раз и унифицирует IO на платформах в один интерфейс
или kotlinx-datetime - jvm - java.time, js - какая-то либа, native - самописная реализация - и всё, сразу можно использовать в mpp проекте в common коде
А чтобы всё работало одинаково на всех платформах - есть тесты, которые запускают один и тот же код, на разных платформах

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

> банально потому-что либы никто переписывать не будет
я же переписал rsocket для kotlin mpp - значит если это нужно - будут )

Я не могу говорить за всю Одессу, но на данный момент по моему мнению, основанному на опыте в моей сфере, МПП - это самое перспективное, что есть в мире разработки. Особенно когда появятся мосты из JVM в натив.

так обёртки не помогут. тебе нужно это скомпилять, а оно не скопиляется. жсная либа не найдет новодский стд моудль, сишная не соберёт платформозависмый эвент-луп, жабовая не найдёт свой ByteBuffer и какой-нибудь KeyStore API итд

а почему он не скомпилится?
почему это не найдёт ByteBuffer если он есть в jdk?

а jdk это жаба, а не котлин-натив

ну я вот только что делал для браузерного и нодовского жс 2 таргета, проблем нет вроде)

вы наверное не совсем представляете как работает мультиплатформ. жабу в жс никто не компилирует

В КММП есть специальные ключевые слова expect (common module) объявления и actual (target/platform module) реализация. Применяется для классов, функций и т.д

Common module - там чистый котлин без платформенных штук. Там ты описываешь апи.

Target module - это уже модуль с платформой и там у тебя есть доступ к платформеным функциям

я же как раз привёл пример:
kotlinx-datetime - jvm - java.time, js - какая-то либа, native - самописная реализация

понятное дело, что jdk вне jvm использовать нельзя
как и nodejs вне js

но можно использовать каждое из них на каждой платформе через expect/actual

никто ничего никуда не конвертирует. эта нодовская либа будет только на нодовском таргете и работать, а для жвм найти надо другую либу и на разных таргетах разные либы через expect / actual могут работать

Тобишь схема простая, на котлине делаем общий апи, и общий код, на платформеным уже специфический код на платформе. Посмотрите kotlinx-time, там для работы со временем как раз и используются платформенные либы

@ankorotkikh
вот хороший пример в доке:)
https://kotlinlang.org/docs/tutorials/mpp/multiplatform-library.html#platform-specific-implementations