Почему Kotlin вместо Java

В этой заметке поговорим о Котлине в контексте серверной разработки (JVM). На Андроиде будет что-то похожее.

Почему же можно и нужно прямо сейчас перестать писать на Java и перейти на Kotlin?

  1. Co-routines. Сейчас заслуженно популярны асинхронные методы. При этом API Reactor приводит к совершенно ужасному коду. Достаточно иллюстративная (хоть и старая) статья на эту тему: https://habr.com/ru/articles/537716/ (в комментариях говорят о каких-то несовместимостях со Spring, но на практике с начала 22 года никаких проблем не заметил, хотя статья 21 года)
  2. Типизированное обращение с null. В Java с этим большие проблемы.
  3. Data classes. В Java вроде бы появились рекорды, но они все еще слабоваты. В целом, Lombok становится ненужным.
  4. Sealed classes. Интересная концепция, которая позволяет типизировать выбор между несколькими вариантами ответа. Что-то вроде Either на стероидах.
  5. Typealias. Позволяют типизировать айдишники – не просто string или int, а orderId.
  6. В целом компактный и читабельный синтаксис.
  7. Хорошее принятие и быстрое обучение Java-программистов до Kotlin-программистов.
  8. Уже развитая и стабильная инфраструктура: IDE и специфические библиотеки.
  9. Язык активно развивается, но без излишней революционности.
  10. Не требуется сразу переводить весь проект, можно по отдельным классам. Где-то в интернетах было исследование, что это не приводит к замедлению скорости работы приложения.
  11. Изначально можно 1 в 1 переводить, а уже потом отдельными шагами (рефакторинг) вводить специфические фичи (sealed classes и т.п.). Хотя корутины лучше сразу.

В целом, Kotlin выглядит как Java, которую мы заслужили ;).

Из сложностей можно выделить:

  1. Необходимость библиотекам зависеть не только от конкретной версии JVM, но и от конкретной версии Kotlin.
  2. Все-таки нужно организовывать проект адаптации Котлина: рассказывать и показывать программистам, первоначальное обновление кода, сборки и CICD. Чем больше программистов и кода, тем сложнее.
  3. Котлин может использовать библиотеки Java, но при этом теряется информация о nullablility и часть возможностей языка не поддерживается. Обычно это не страшно, но часть библиотек нужно переписывать (использовать Kotlin-варианты – mockk, log4j-api-kotlin, …). Для других использовать адаптеры (jackson-module-kotlin, reactor-kotlin-extensions, kotlin-allopen, springdoc-openapi-kotlin, …).