Русский
Русский
English
Статистика
Реклама

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

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

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

изрядное количество подробностей внутренней работы 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 не просто лучше, он дает думать в другой парадигме, открыт для новых возможностей, страхует от многих ошибок на этапе компиляции.

Источник: habr.com
К списку статей
Опубликовано: 24.05.2021 08:13:54
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Программирование

Java

Kotlin

Jvm

Jetbrains

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru