т.е. классы BlaBlaUtil для размешения нескольких функций это не сложности?
по мне top level подходят в 95% случаев, для остальных обычные object  (если нужен контекст в имени функций)

если для использования этих функций не нужно создавать экземпляр, то не вижу сложностей. другой вопрос, что обычно эти классы рождены невозможностью расширить текущие классы под свои нужды, то есть extension в разном виде. как только появляются extension, всё становится намного лучше и необходимость в такого рода утилитарных классах практически пропадает. но появляется другая интересная проблема - как понять, что нужно заимпортить и где лежат нужные extension. эта проблема была и в классической java, но, начиная поиск класса со String ты находил Strings, StringUtil, StringUtils, StringTools, ... c extenion-методами всё стало несколько интересней, их можно написать в любых странных местах :)

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

А какая penalty? Пара килобайт?

тут ведь вопрос не только в занимаемой памяти, а в том, что код выглядит как stateful и работает как stateful. object это singleton, а не static. companion object фактически тоже singleton с сахарком.

второй вопрос - вызов через инстанс почти наверняка дороже вызова static. я не спец по JIT, но мне кажется, что на такую оптимизацию он вряд ли способен (увидеть, что this не нужен и сконвертить в static)

А вот это прям вопрос - не умеет ли компилятор превратить такой метод в статик?

ещё мы часто дергаем kotlin код из java. для таких штук в companion object приходится везде набрасывать @JvmStatic, что всё равно нас возвращает к static методам, только таким неказистым путём

Стимул не писать на java

Есть вопрос. В джаве для каждого обьекта есть монитор. Т.е в заголовке обьекта есть место для монитора.А как с ним в котлине?

как я понял нету методов wait, notify, notifyAll. Но есть ли сам монитор?

может методов нету, а монитов есть

synchronized - Kotlin Programming Language
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/synchronized.html

во. сейчас опять пришлось это сделать и вспомнил.
планируется ли что-то делать с таким трешем, как
(::property.apply { isAccessible = true }.getDelegate() as MyDelegate<*>).myMethod()
runtime-рефлексия на ровном месте, где она нафиг не сдалась

Это вопрос оптимизации компиляции?

скорее вопрос поддержки делегатов. если уж решили делать поддержку делегатов, надо в этом желании идти до конца

а то поддержка вроде как есть, но только для установки/получения. а когда нужно получить сам делегат, сразу проблема и все compile-time проверки идут лесом. хотя если реализовать делегат без синаксического сахара kotlin, то таких проблем не будет, всё будет проверятся в compile-time и никакой рефлексии не понадобится.

Вот так развиваешь чат в телерамме, а государство берет и перечёркивает твои старания.
Кто где тусит помимо телеграмма? Слак? Фейсбук?

реддит)

нужно срочно написать новый мессенджер на котлине :)