Они интеропятся из коробки лучше некуда. Пока не понятно, что вы хотите.

Почитай ссылку выше. При использовании либы на Котлине это будет торчать как kotlin.Collection или kotlin.MutableCollection. При использовании абсолютно того же кода на Джаве это будет выглядеть как java.util.Collection. Что именно не подходит в этой схеме? :)

Это про ситуацию когда из котлин кода возвращается котлиновская коллекция. У меня наоборот, в котлиновский код передаётся джавовая коллекция.

Вы же в курсе, что котлиновских коллекций не существует за пределами кода на котлине и в рантайме?

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

Я был не в курсе. Меня спутало то, что я посмотрел в исходники stdlib и нигде в иерархии наследования котлиновского ArrayList не увидел джавогого Collection.

Каким образом в компиляторе или стандартной библиотеке определён маппинг между kotlin.collections.Collection и java.util.Collection ?

Я ссылку про Mapped Types выше кинул

Не так важно как, важно, что он есть

В stdlib - через typealias, в компиляторе - прибито гвоздями

Всё ясно. Я видел это когда за два часа побежался по спеке языка, но не обратил внимание. Спасибо!

Кстати, Александр, когда я только вошёл в чат я увидел что есть arrow. Там реально всё хорошо или это cats-effects курильщика?

Если вкратце - часть вещей выглядит хорошо, ибо их особо не испортить (всякие простые вещи, вроде Either, NonEmptyList, линзы)

Часть работает, но иногда бывают нюансы (сделан свой аналог monad comprehensions, но он работает через корутиновые фичи, что странно и в редких случаях может стрельнуть)

Часть вещей по причине отсутствия тайпклассов пока что выглядит более громоздко (условный traverse требует экземпляр аппликатива руками передать)

Ну и есть всякие проблемы с тем, что некоторых фич нету и их надо симулировать. Явный пример - HKT в языке нету, но есть симуляция. Ребята из 47deg работают над компиляторным плагином, чтобы со всем этим меньше страдать, но пока ещё не готов.


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

Понятно. Спасибо за подробный ответ. А зачем arrow тогда вообще нужен? Для тех у кого ностальгия по хаскелю/скале?

И да

1. В проде я не юзал, ибо я Котлин в проде только с декабря начну юзать :)
2. Вообще формально говоря, ни Arrow, ни платформенные типы не являются JVM-бэкенд специфичными (по крайней мере идейно), так что лучше в следующий раз писать в основной канал (ссылки в описании канала)

Зачем нужен:
1. Вообще там всё модульно, так что ты можешь забрать минимально полезные штуки и всё. А те, которые на Котлин ложатся не так хорошо, игнорировать.
2. Как ни странно, уже слышал историю о том, что человеку запретили Скалу на проде, вот он исхитрился с Котлином и Arrow. Но вообще так лучше проблемы не решать :)

В целом - развивая либу ребята умудряются немного развивать язык. Т.е. фича про тайпклассы наверное до сих самая заголосованная, пушат её как раз ребята, которые делают Arrow (см. KEEP-87). Возможно скоро они же научатся делать кучу компиляторных плагинов, даже если не их конкретные использовать (им нужно для правильных monad comprehensions, автофиксации hkt и тд), всё равно польза будет.

Да, интересно это всё. Я в целом похож на человека из Вашего пункта 2 :) У меня большая команда, сам я конечно тоскую по скале, но с точки зрения бизнеса понимаю, что не смогу такую толпу народа перевести на Scala и не умереть. С другой стороны писать на Java 8 совсем невыносимо, поэтому в качестве эксперимента решил потратить выходные на Kotlin и приятно удивлён пока что. Правда в первые же два часа нашёл баг в компиляторе, но надеюсь его починят скоро :)

Мне кажется, всё-таки котлин не для тех, кто хочет чисто функциональный подход, у него для этого много чего нет

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

375 строк на программиста. Это что за ужас такой?

именно

Ну тут скорее дело не в том, что нет, а в том, что принципиально не принята "чисто функциональная" парадигма. Идея в том, что то, что проще сделать объектно - должно быть объектно, а что лучше процедурно - должно быть процедурно. Именно поэтому ряда "фич" нет и не будет в мейнстриме. Они гораздо лучше другими способами делаются.
Я совершенно не фанат arrow, но я согласен, что они делают хорошее дело. По крайней мере экспериментируют. А еще лучше, что они делают это у себя в песочнице и не тащат все подряд в язык.