Вообще, как человек, который последнюю неделю воюет с голым JS, могу сказать, котлин - это просто совершенно другой уровень удобства и безопасности.

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

ну людям удобно 10 разных типов в одной переменной хранить

на жс не ради безопасности пишут

Я подозреваю, что на js пишут, потому что другого не знают. Программирование методом тыка - это ушлепство. Я задолбался, честно

я так на питоне писал

В питоне дока сильно лучше. В JS к сожалению, все сводится к "кривая выведет"

Ну и питон в репле, там всегда можно остановить и отдебажить. В приложение на JS только перезапустить

Доброго вечера. Вопрос по вариантивности дженериков и дата классам:

// компилируется
data class Foo1<out FOO>(val foo: FOO)

class Foo2<out FOO>(val foo: FOO) {
    // не компилируется
    // Type parameter FOO is declared as 'out'
    // but occurs in 'in' position in type FOO
    fun copy(_foo: FOO = foo): Foo2<FOO> = Foo2(_foo)
}

class Foo3<out FOO>(val foo: FOO)
// компилируется
fun <FOO> Foo3<FOO>.copy(_foo: FOO = foo): Foo3<FOO> = Foo3(_foo)

Собственно, вопрос: ограничение, из-за которого не компилируется, логично, но тогда почему два других варианта компилируются?

// компилируется
data class Foo1<out FOO>(val foo: FOO)

class Foo2<out FOO>(val foo: FOO) {
    // не компилируется
    // Type parameter FOO is declared as 'out'
    // but occurs in 'in' position in type FOO
    fun copy(_foo: FOO = foo): Foo2<FOO> = Foo2(_foo)
}

class Foo3<out FOO>(val foo: FOO)
// компилируется
fun <FOO> Foo3<FOO>.copy(_foo: FOO = foo): Foo3<FOO> = Foo3(_foo)

Третий так-то компилируется, потому что в функции FOO не тот же самый, что объявлен на уровне класса

Ок, а как компилируется copy в первом? И главный вопрос: "а это типобезопасно?"

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

Кажется я понял, почему второй вариант запрещает система типов.
Первый типобезопасен для copy, так как создаётся новый объект.
Третий типобезопасен так как объявлен расширением и опирается на типобезопасность расширяемого класса (предполагается, что все нетипобезопасные части, если есть, инкапсулированы).
Второй потенциально не типобезопасен, так как не известно, что делает метод, в котором FOO присутствует в in позиции. Он потенциально может изменять ресивер, что не всегда корректно и может приводить к ошибкам приведения типов во время исполнения.

Ну, сходу выглядит что-то генерится что-то типобезопасное, правда не очень гибкое

Пример странного кода:

data class Test<out T>(val t: T)

fun main() {
    val x = Test(5)
    val y: Test<Any> = x

    x.copy(t = 5)
//    x.copy(t = "abc") // will not work
    y.copy(t = "abc")
}

data class Test<out T>(val t: T)

fun main() {
    val x = Test(5)
    val y: Test<Any> = x

    x.copy(t = 5)
//    x.copy(t = "abc") // will not work
    y.copy(t = "abc")
}

Ну я не вижу тут странностей особо.

Это про какую доку речь?

Уверены?

Про либы. Я вот вчера читал документацию к require-js. Вроде массовая либа, но чтобы найти место, где описывается формат конфигурации - это убиться надо. Примеры есть, описания формата целиком в одном месте - нет

Ну я не говорю про веб на джанге. Честно говоря, мен до сих пор совершенно не понятно, откуда надо упасть, чтобы писать что-то крупное на джанге. Основная известная мне часть исползования питона - это короткие скрипты и репл. Это уже не про котлин, так что в @pofftop

С документацией библиотек (не языка) везде может быть плохо, хоть в том же расте на crates.io. А тем более requirejs, зачем она на сегодня нужна?