Из Балтийского моря в Индийский океан

[zagayevskiy]

Stand!!.channell!!.stream!!.act()
Компилятор не будет проверять данное выражение. Как не будет проверять и в случае компиляции совместного проекта c Java. Спрашивается, в чем тогда преимущество?!

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

[zagayevskiy]

private fun checkConnections(silently: Boolean = false): Boolean {
        var isNotFailed = true
        mqToClearTable.items.filter { isMqValid(it) }.forEach { mq -> if (mq.queue.isNotEmpty()) {
                isNotFailed = isNotFailed && checkMqConnection(MQContainer(mq.host, mq.port.toInt(), mq.channel, mq.queue, mq.manager), silently)
            }
        }
        return isNotFailed
    }

легко заменяется на

private fun checkConnections(silently: Boolean = false) = mqToClearTable.items
        .filter { isMqValid(it) }
        .filter { it.queue.isNotEmpty() }
        .fold(true) { isNotFailed, mq -> 
            isNotFailed && checkMqConnection(MQContainer(mq.host, mq.port.toInt(), mq.channel, mq.queue, mq.manager), silently)
        }

Кто это пропустил на ревью:

testInfo.also {

 it.endDateProperty.onChange { it?.let { update(Tests.endDate, it) } }
     }

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

Best practice считается делать классы, не предназначенные для наследования, final. Т.о. создатель, например, библиотеки, должен явно подумать как будут использовать его классы и что будет при наследовании от них.

Примитивных типов данных, таких как int, boolean и т.д., в языке не наблюдается

А зачем вам про них думать? В тех местах, где это возможно, используются именно они (в реализации на JVM).

[pilot911]

спасибо за статью и примеры, пережил такие же ощущения при знакомстве с Kotlin

[Seldon]

Вот опять, широкие возможности языка подменяют кривыми руками программистов.
Я пишу на котлине пол года (довольно неплохой проект, причем в банке: kotlin, spring boot).
У нас нет кучи "?", нормальное код ревью и команда состоящая из людей не ниже senior уровня — решает эту проблемы. Котлин экономит кучу времени на написание и чтение кода.
И какие замечательные жалобы на final по умолчанию, а вы не думали, что это хорошо? И позволяет вам однозначно определять, что в вашем классе можно менять и можно ли вообще.

И на самом деле скорее просто вы не совсем правильно понимаете паттерны в программировании, отсюда и возникают такие вопросы и негодования, в тоже Java вообще куча провальных решений, которые благодаря совместимости тянуться годами и будут тянуться.
Но на проекте, где работают только опытные программисты, где отлажена работа черед кодревью и это не просто формальность, котлин взлетает (говорю по личному опыту)

[jeka_odessit]

Когда первый раз увидел Kotlin, сразу вспомнил старый добрый Groovy. Непонятно почему надо было изобретать велосипед Котлин когда можно было доработать/использовать Groovy который уже много лет до Котлина существовал и получил весь этот «сахарный синтаксис».

(Ничего против Котлина не имею, тоже интересный синтаксис и фитчи, каждому проекту и человеку свое!)