Вышел Kotlin 1.0

А он есть. Например если есть огромный проект на Java и хочется переводить его потихоньку на другой язык.

Не имеет смысла переводить огромный Java-проект как на Scala так и на Kotlin по многим причинам: качество кода в таких проектах очень разное (в основном плохое), огромное количество костылей и другого легаси. В большинстве случаев проще написать с нуля, что и делается в том же опенсорсе постоянно.

Дело не в полноценности, а в том, что Scala переизобретает многое, что уже есть в стандартной библиотеке Java

Я бы сказал, что улучшает. Но в одном ты прав, Scala сильно отличается от Java и если юзать Scala из Java-кода, то ни к чему хорошему это не приведет. Что еще раз показывает что есть что.

Я не специалист по андроиду, но читал, что это реальная проблема из-за каких-то особенностей андроида (вроде не более 65535 методов может быть в приложении) и Scala этот лимит сильно уменьшает.

Не проблема.

Scala считаю непрактичной для 90% проектов из-за её чрезмерной сложности.

Не осилил, ясно.

Судя по популярности Kotlin-а я не один так считаю.

Стая мух не может ошибаться:) Windows тоже популярен.

Насколько я знаю, Scala развивается Мартином Одерски, который является основателем коммерческой компании Typesafe. Я не вижу отличий.

Скажи еще что Linux Foundation развивает Linux kernel:) Почитай хотя бы прежде чем что-то утверждать.

Естественно в реальности там скорее всего не будет null, но от ошибки никто не застрахован.

Андроид компилируется в *.class, собирается в *.jar, переформатируется в *.dex, и пакуется в *.apk.

*.dex собирается довольно долго и процессорожруче, и ограничения по числу классов/методов идет именно здесь. Scala не просто понижает лимит, она тупо в него не влезает.

Поэтому для Скалы обязателен Proguard, который выкидывает неиспользованный код, после этого проблема больше не всплывает.

Вторая часть беды, опять же, тормознутость. Тормозит и компилятор (как обычно), и Proguard (надо же разобраться, кто нужен, а кто нет), и *.dex-запаковщик (даже после выкидывания ненужного остается много жира), и кэширование запаковок тоже периодически отваливается, так что весь процесс по новой запускается.

С дебагом стандартные проблемы — компилятор скалы очень умный, и работающий код может сильно отличаться от того, что в тексте написано.

JRuby это ж динамическая типизация, совсем другая тема

Ад. Не проблема, для которой нужно прочитать 2к слов и поясняющий скриншот.

Может быть я открою Америку для тебя, но чтобы научится создавать качественный софтовый продукт надо прочитать много больше 2к слов.

Ты не понял, такие обороты вообще не должны быть написаны, язык не при чем.

в idea ctl+shift, convert to kotl<enter> - и весь код автоматом сконверчен

А в обратную сторону?

Качественного софта под Андроид на Скале нет. В том числе и потому, что не нужно решать надуманных проблем.

смелый шаг, значительно приближающий Kotlin к самому уродливому ЯП XXI века

Мне тоже, при просмотре видео, пришел на ум Rust.
Там, как и здесь, прекрасные идеи испоганили отвратительным синтаксисом

Из-за этого выпилили ternary operator, вместо него предлагают юзать уродливый if … else …

А на Kotlin есть?

Спасибо за пример. Точно такая фича есть в groovy, а вот в Scala нет. Мне не хватало когда я свой DSL писал на Scala. Буду знать что в Kotlin есть.

В Scala это делается через import, например

val sb = new StringBuilder()
import sb._

append("")

В случае с Kotlin дело не только в том, что можно не писать «sb.», а в том, что код исполняемый внутри лямбды будет исполняться в определенном контексте, окруженный определенными конкретными элементами.

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

db.beginTransaction()
try {
   db.delete("users", "first name = ?", new String[] { "Jake" });
   db.setTransactionSuccessful();
} 
finally {
   db.endTransaction();
}

Можно определить extension-метод:

inline fun SQLiteDatabase.inTransaction(func: SQLiteDatabase.() -> Unit) 
{
   beginTransaction()
   try {
      func()
      setTransactionSuccessful()
   } 
   finally {
      endTransaction()
   }
}

И потом использовать его вот так:

db.inTransaction {
   delete("users", "first name = ?", arrayOf("Jake" ));
}

Существенно упрощает жизнь, куда меньше шансы что в одном каком-то конкретном месте будет забыт вызов или случайно порядок выйдет не правильный. При этом в плане байткода скомпилированного код выходит 1-в-1 такой-же что и оригинальный код на Java (для этого inline там).

Или можно например создать класс-враппер, который будет гарантировать что доступ к внутреннему обьекту можно получить только заблокировав его, тем самым исключая случайный доступ без блокировки:

data class Lock<T>(private val obj: T) 
{
   public fun acquire(func: (T) -> Unit)
   {
      synchronized (obj) {
         func(obj)
      }
   }
}

val readerLock = Lock(JsonReader(stream))

readerLock.aquire {
   println(it.readString())
}

от «it» внутри последней лямбды я специально не стал избавлятся, это можно сделать если заменить

public fun acquire(func: (T) -> Unit)

на

public fun acquire(func: T.() -> Unit)

Эти обе задачи в Scala решены через call by name параметры и implicit'в.

JRuby - динамически типизированная тормозня.

Не сметь перечислять убогую борщету в одном списке с Java!

Утенок порвался.

По сравнению с Java 8, есть что-то стоящее?

При переходе на Haskell, существенно уменьшается объем «Java/Kotlin лапши» в коде.

Java / Kotlin лапша исчезает полностью.

... и ограничения по числу классов/методов идет именно здесь. Scala не просто понижает лимит, она тупо в него не влезает.

Причем не влезает из-за пристрастия некоторых разработчиков Scala к traits, особенно в библиотеке коллекций. Это при раскрытии traits образуется такое огромное количество методов.

На мой частный взгляд эта библиотека коллекций в Scala - пример плохого дизайна, но в программировании всегда существует множество точек зрения, и кому-то она может даже нравиться) Причем некоторые готовы доказывать свою точку зрения до посинения с пеной у рта, как обычно.

Было забавное видео с Доном Саймом (создателем F#), Джо Армстронгом (создателем Erlang) и Мартином Одерским (создателем Scala). На картинке было очень четко видно, как первые двое разошлись в одном важном вопросе с последним, вплоть до занятия позы психологической защиты, когда человек подсознательно переминает ногу в положение от собеседника, как бы огораживаясь. Вопрос был общий, но туда можно отнести и злоупотребление traits.

Абсолютно мертворожденная идея.

Взялись улучшать совершенный ЯП? Но компилируют его под ту же самую кривульку JVM?

Образцовое ненужно.

ту же самую кривульку JVM

Потому что некоторые придурки умудрились написать на этом гавне архиважное АПИ к ОС, обходить которое с jni выйдет еще печальнее, чем терпеть jvm под своим апп. В принципе надо бы попробовать завести на андроиде какуюто иную ВМ с полноценным мостом в jvm, причем так, что не будет виснуть на хеловорлде, как xamarin. Но это из серии фантастики пока. А котлин вот уже есть пожалуйста, для текущих нужд да и внутри java проектов на нем писать можно (если шеф не проведает).

Но на андроиде нет JVM. Там Dalvik.

Хрен редьки... Покажи хотяб один ЯП, который не может компилиться в .class, а сразу генерит .dex, причем не потому что афтор идиот, а ради каких-то реальных плюшек.

Но api это абстракция. А jvm это суровая реальность, деревяные игрушки и скользкие подонники.