кроме native есть ещё и js. для него вся эта глупая возня с дженериками jvm тоже высосана из пальца :)

думаю, основной профит от совместимости с java как раз в том, что kotlin-код можно вызвать из java без особых проблем. если лишить kotlin косяков java, он лишится и interoperability. так что тут вопрос, насколько для koltin это важно. создатели scala решили, что это неважно. возможно, фейл scala отчасти связан с этим, хотя идея вызывать scala из java приходит людям в голову редко :) обратно ещё понятно зачем - библиотек для java существенно больше

есть один предварительный вопрос. Вчера на JPoint выступал Андрей Бреслав. Так я его понял, что он сожалеет сейчас, что не оставили static методы, а ввели object. Соттветственно и вопрос. Правильно ли я его понял и если правильно, то почему именно он сожалеет.

ну, это вопрос лично Бреславу? не факт что он будет у нас )

я надеялся )

А это точно было про object вообще или про companion object?

думаю, про companion object, так как object особо не пересекается с идеей static

это обсуждается вроде https://github.com/Kotlin/KEEP/pull/87

да там и тусят в основном Scala-исты и Haskell-исты :)
так что вопрос в том, будет ли Kotlin дальше двигаться в сторону FP или всё-таки займёт такую хитрую промежуточную позицию. Scala лично для меня плоха ещё и очень медленной компиляцией и отвратительной поддержкой в IDE.
если с этими факторами что-то поделать, и в рамках Koltin реализовать тот же фуникцонал... такой язык вполне может стать массовым

в этой нише уже eta и scala отчасти, котлин массовым будет как раз, если не свалится в одну парадигму, на мой взгляд

я бы не сказал, что scala свалилась в какую-то одну парадигму :) если только не считать парадигмой "свой язык для каждого приложения". Language Oriented Programming и всё такое. но не все используют scala таким образом

а насколько популярны shapeless и cats?

scalaz еще

Я с Андреем Бреславом этот вопрос обсуждал на прошлом JPoint.
Companion object не особо нужны т.к. все утильные функции, константы идеоматично размещаются на top level, а все остальное лучше в обычных object

классом удобно задавать контекст. некоторые функции без задания контекста звучат слишком общё, а давать им длинные названия не айс.

если нужен контекст для имени, можно использовать object

используя object там где не надо, приходишь к мысли, а зачем так делать?

top-level функции в этом плане даже лучше :)

то есть, на уровне package теоретически можно построить контекст, если всё грамотно организовать

просто непонятно, зачем создавать сложности, которых в jvm не было, сохраняя все сложности, которые там уже есть