Почему Kotlin лучше Java?

[Kate]

Проприетарные метаданные?​

изрядное количество подробностей внутренней работы kotlinc скрыто внутри сгенерированных файлов классов...без IDEA Kotlin немедленно умрет

Это не проприетарный код, а просто способ для компилятора дописать дополнительные данные в жестко заданном формате .class-файлов, который ранее был заточен только под javac. Метаданные нужны для рефлексии и их можно удалить при компиляции. Исходный код метаданных открыт и общедоступен.

Kotlin будет отставать?​

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

В Kotlin сделали примерно так

if (x instanceof String) {
// теперь x имеет тип String!
System.out.println(x.toLowerCase());
}

Но в Java версии 16+ стало так:

if (x instanceof String y) {
System.out.println(y.toLowerCase());
}

Получается, что оба языка имеют способ обработать описанный сценарий, но разными способами. Я уверен, что если бы мог вдавить огромную кнопку «сброс», разработать Kotlin с нуля и снова выпустить сегодня бета-версию, то в Kotlin было бы сделано так же, как сейчас в Java. Учитывая, что синтаксис Java более мощный: мы можем сделать с ним намного больше, чем просто «проверить тип» (например, «деконструировать» типы-значения).
...
Ему придётся опираться только на себя и перестать рекламировать доступность всех преимуществ Java и её экосистемы. Пример с instanceof уже демонстрирует, почему я думаю, что Kotlin не будет лучше Java: почти каждая новая фича, которая появилась в Java недавно или вот-вот появится (в смысле, имеет активный JEP и обсуждается в рассылках) выглядит более продуманной, чем любая фича Kotlin.

Этот аргумент вызван плохим знанием Kotlin. Автор использовал неидиоматичный подход, и вся его критика по сути направлена против своего же неверно написаного Kotlin кода. На самом деле, стоит прочесть лишь вводную страницу документации по базовым инструкциям (чего автор видимо не сделал), чтобы понять что Kotlin вариант не только более лаконичный, но и намного функциональнее, судите сами:
when(val v = calcValue()) {
is String -> processString(v)
}
Здесь в одной области можно проверить сразу несколько типов вместе со значениями, без создания дополнительных переменных. Попробуйте повторить в Java c if/instanceof/switch:
when(val v = calcValue()) {
is String -> processString(v)
42 -> prosess42()
is Int -> processInt(v)
else -> processElse(v)
}
Остается разобраться с аргументом, что Kotlin, якобы, придется что-то делать с изменениями вносимыми Java, адаптироваться или расходиться, что это, якобы, создает проблему развития для Kotlin.

Прямо сейчас Kotlin оседлал волну успеха, но со временем жизнь его будет тем тяжелее, чем шире будет зазор между ним и Java, и чем сложнее будет преодолеть этот зазор.

Здесь автор путает местами причину и следствие, пытаясь выдать Kotlin за догоняющий язык. На самом деле, адаптация новых возможностей это в первую очередь проблема именно для Java. Уже давно C# и Kotlin подстегивают Java изменяться, и для Java изменения даются гораздо сложнее по причине изначально тяжеловесного и сложившегося за десятилетия синтаксиса, не предусматривавшего появление новых, функциональных возможностей. В Java для них попросту осталось не так много места, где их можно прикрутить к синтаксису, и именно поэтому они выглядят чужеродно и обременительно для восприятия.

Нативная поддержка null, которая греет душу любого котлиниста, легко заменяется в Java на обёртку из Optional.ofNullable. Data-объекты могут быть заменены более богатым функционалом record.

Многие догоняющие возможности Java содержат изъяны по умолчанию, все больше заставляют прибегать к соглашениям, а не к дизайну языка. Вместо громоздкой в коде обертки Optional можно просто передать null, а record ничуть не более богатый чем data class.

Как думаете, сохранит Kotlin свою популярность через пять лет и почему?

Отвечая на этот вопрос, некоторые в комментариях к исходной статье вспомнили историю Scala и Java. Но есть и другая история, история того что сделал С++ со старым Си.
Несомненно, Java останется там где нужно поддерживать старые решения. Однако новые решения будут все больше писаться на Kotlin, пока он не станет языком по умолчанию, как это уже произошло в Android экосистеме, и прямо сейчас происходит для backend разработки в jvm экосистеме. Kotlin не просто лучше, он страхует от старых ошибок на этапе компиляции, дает думать в другой парадигме, открыт для новых возможностей.


Источник статьи: https://habr.com/ru/post/558892/