В этой заметке поговорим о Котлине в контексте серверной разработки (JVM). На Андроиде будет что-то похожее.
Почему же можно и нужно прямо сейчас перестать писать на Java и перейти на Kotlin?
- Co-routines. Сейчас заслуженно популярны асинхронные методы. При этом API Reactor приводит к совершенно ужасному коду. Достаточно иллюстративная (хоть и старая) статья на эту тему: https://habr.com/ru/articles/537716/ (в комментариях говорят о каких-то несовместимостях со Spring, но на практике с начала 22 года никаких проблем не заметил, хотя статья 21 года)
- Типизированное обращение с null. В Java с этим большие проблемы.
- Data classes. В Java вроде бы появились рекорды, но они все еще слабоваты. В целом, Lombok становится ненужным.
- Sealed classes. Интересная концепция, которая позволяет типизировать выбор между несколькими вариантами ответа. Что-то вроде Either на стероидах.
- Typealias. Позволяют типизировать айдишники – не просто string или int, а orderId.
- В целом компактный и читабельный синтаксис.
- Хорошее принятие и быстрое обучение Java-программистов до Kotlin-программистов.
- Уже развитая и стабильная инфраструктура: IDE и специфические библиотеки.
- Язык активно развивается, но без излишней революционности.
- Не требуется сразу переводить весь проект, можно по отдельным классам. Где-то в интернетах было исследование, что это не приводит к замедлению скорости работы приложения.
- Изначально можно 1 в 1 переводить, а уже потом отдельными шагами (рефакторинг) вводить специфические фичи (sealed classes и т.п.). Хотя корутины лучше сразу.
В целом, Kotlin выглядит как Java, которую мы заслужили ;).
Из сложностей можно выделить:
- Необходимость библиотекам зависеть не только от конкретной версии JVM, но и от конкретной версии Kotlin.
- Все-таки нужно организовывать проект адаптации Котлина: рассказывать и показывать программистам, первоначальное обновление кода, сборки и CICD. Чем больше программистов и кода, тем сложнее.
- Котлин может использовать библиотеки Java, но при этом теряется информация о nullablility и часть возможностей языка не поддерживается. Обычно это не страшно, но часть библиотек нужно переписывать (использовать Kotlin-варианты – mockk, log4j-api-kotlin, …). Для других использовать адаптеры (jackson-module-kotlin, reactor-kotlin-extensions, kotlin-allopen, springdoc-openapi-kotlin, …).