Всем привет, меня зовут Сергей Прощаев, и в этой статье расскажу про то, как на самом деле выглядит противостояние Java и Kotlin на бэкенде в 2026 году. Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech, а ещё преподаю на курсах разработки и архитектуры в OTUS.
Последние несколько лет я наблюдаю, как Kotlin перестаёт быть «языком для Android» и всё увереннее заходит на территорию, где десятилетиями правит Java. Но значит ли это, что Java сдаёт позиции? Давайте разбираться без холиваров, на конкретных кейсах и цифрах.
Роль JVM‑языков в современной разработке
JVM никуда не уходит. Spring Boot, Quarkus, Micronaut, Kafka, Elasticsearch — всё это живёт на Java‑платформе. При этом бизнес требует ускорять time‑to‑market, снижать количество багов и упрощать поддержку кода. И вот тут на сцену выходит Kotlin: он предлагает решать те же задачи быстрее и безопаснее. Но правда в том, что у Java появился мощный ответ в виде Project Loom, улучшенного pattern matching и постоянного развития. Так что в 2026 году битва стала интереснее, чем когда‑либо.
Синтаксис и выразительность
Начну с банального примера — описание модели данных. В Java вы пишете что‑то вроде:
public class User { private final Long id; private final String name; private final String email; public User(Long id, String name, String email) { this.id = id; this.name = name; this.email = email; } public Long getId() { return id; } public String getName() { return name; } public String getEmail() { return email; } @Override public boolean equals(Object o) { ... } @Override public int hashCode() { ... } @Override public String toString() { ... } }
В Kotlin:
data class User(val id: Long, val name: String, val email: String)
И это не просто экономия строк. Это снижение когнитивной нагрузки: ты сразу видишь суть, а не обёртку. Когда я показываю такой пример новичкам на курсах, у них загораются глаза — они чувствуют, что язык работает на них, а не наоборот.
Надо заметить, что в Java‑мире уже давно используют Lombok, чтобы не писать руками километры геттеров и equals. С @Data тот же класс превращается в три строки:
import lombok.AllArgsConstructor; import lombok.Data; @Data @AllArgsConstructor public class User { private final Long id; private final String name; private final String email; }
Выглядит почти как Kotlin‑овский data class, правда? Но есть нюанс. Lombok — это внешняя библиотека, которая работает через аннотационный процессор и модифицирует байт‑код во время компиляции. Иногда он конфликтует с другими инструментами (например, с модульной системой JPMS), а обновление версий Lombok может потребовать перекомпиляции всего проекта. Kotlin же даёт ту же лаконичность из коробки, на уровне языка, без дополнительных зависимостей и сюрпризов при обновлении JDK.
И ещё один момент: когда новый разработчик приходит в проект с Lombok, ему нужно ставить плагин в IDE, иначе он видит красные ошибки на вызове методов, которых в исходнике нет. В Kotlin таких проблем нет — всё явно и понятно.
Так что Lombok — отличный костыль для Java, но именно костыль. Kotlin идёт дальше: он не просто генерирует шаблонный код, а делает его частью языка, с чёткой семантикой и гарантиями.
Ещё один любимый пример — extension functions. Допустим, вам часто нужно проверять, является ли email корпоративным. В Java вы бы создали статический метод в каком‑нибудь EmailUtils:
public final class EmailUtils { private EmailUtils() {} // запрет инстанцирования public static boolean isCompanyEmail(String email) { return email != null && email.endsWith("@company.com"); } } // использование в коде: if (EmailUtils.isCompanyEmail(user.getEmail())) { // ... }
В Kotlin вы можете написать:
fun String.isCompanyEmail(): Boolean = this.endsWith("@company.com")
И использовать: if (user.email.isCompanyEmail()) { ... }. Код читается как обычный английский текст. Такие мелочи складываются в колоссальную разницу при работе над большим проектом.
Безопасность кода
Самое громкое преимущество Kotlin — null safety. В Java вы вечно гадаете, может ли метод вернуть null, и либо ставите @Nullable (которые никто не проверяет), либо заворачиваете всё в Optional. Kotlin на уровне системы типов разделяет nullable и non‑nullable переменные:
var name: String = "John" // не может быть null var email: String? = null // может быть null
Попытка вызвать метод на nullable типе без проверки приведёт к ошибке компиляции. Это не просто удобно — это устраняет целый класс багов. По данным исследований, NullPointerException остаётся одной из главных причин падений Java‑приложений. В Kotlin вы просто не можете ошибиться.
Что касается обработки ошибок — здесь Java идёт по пути исключений. Kotlin предлагает более функциональный подход с типом Result<T> или использованием sealed class для явного моделирования состояний. В функциональном стиле вы явно указываете, что операция может завершиться ошибкой, и компилятор заставляет вас обработать все варианты.
Производительность
Бытует миф, что Kotlin медленнее Java из‑за дополнительных абстракций. На практике же байт‑код, генерируемый Kotlin, практически идентичен Java. Data class генерирует те же методы, что и ручное написание. Inline‑функции позволяют избежать накладных расходов на лямбды. Время старта приложения на Spring Boot с Kotlin и Java отличается в пределах погрешности.
Потребление памяти — аналогично. Небольшой оверхед может быть разве что из‑за дополнительных метаданных в классах, но в реальных продакшн‑системах это незаметно.
Настоящий интерес вызывает тема асинхронности, о которой поговорим дальше.
Асинхронность и конкурентность
Вот здесь, на мой взгляд, и происходит самое жаркое сражение.
Kotlin Coroutines — это легковесные потоки, которые позволяют писать асинхронный код в синхронном стиле:
suspend fun fetchUserData(): UserData { val profile = async { profileService.get() } val settings = async { settingsService.get() } return UserData(profile.await(), settings.await()) }
Код простой, линейный, легко читается. Под капотом корутины используют ограниченное число реальных потоков и эффективно переключаются в точках приостановки. Это позволяет держать десятки тысяч одновременных соединений без раздувания пула потоков.
Java долгое время полагалась на CompletableFuture и реактивные стримы (Project Reactor, RxJava). Код получался сложным, с кучей flatMap, zip, subscribe. Project Loom с виртуальными потоками (Virtual Threads) изменил правила игры. Теперь вы можете создать миллион виртуальных потоков, и JVM будет управлять ими так же эффективно, как корутины:
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) { executor.submit(() -> { ... }); }
Но есть нюанс: виртуальные потоки всё ещё привязаны к синхронным блокировкам, и не все библиотеки готовы к работе с ними. Корутины Kotlin глубже интегрированы с экосистемой (например, поддержка в Spring WebFlux, Ktor) и предоставляют богатый набор операторов для управления конкурентностью.
Чтобы наглядно показать разницу, я подготовил небольшую схему:
Оба подхода дают схожий результат — возможность обрабатывать огромное количество конкурентных задач без раздувания ресурсов. Но корутины предоставляют более декларативный API и лучшую поддержку в существующих фреймворках.
Экосистема и инструменты
Здесь у обоих языков полный порядок. IntelliJ IDEA от JetBrains — бесспорный лидер, и поддержка Kotlin в ней идеальна (что неудивительно, ведь язык создан той же компанией). Gradle Kotlin DSL позволяет писать сборочные скрипты на Kotlin с автодополнением и проверкой типов — это огромный шаг вперёд по сравнению с Groovy.
Spring Boot отлично поддерживает Kotlin наравне с Java: есть специализированные DSL для бинов, маршрутов, тестов. Ktor — легковесный фреймворк от JetBrains, написанный на Kotlin с нуля, — заслужил любовь в микросервисных архитектурах за скорость и простоту. Quarkus также предоставляет первоклассную поддержку Kotlin.
С другой стороны, многие библиотеки всё ещё ориентированы на Java и требуют небольших адаптеров при использовании из Kotlin. Но ситуация улучшается с каждым годом.
Сообщество, тренды и рынок труда
Если посмотреть на статистику вакансий в 2026 году, Java остаётся лидером по количеству предложений — слишком много legacy‑кода и корпоративных систем написано на ней. Но доля Kotlin в бэкенд‑разработке уверенно растёт. Многие компании, которые начинали с Android на Kotlin, теперь переносят опыт на серверную часть.
Интересный кейс — миграция в Allegro, крупнейшей торговой площадке Польши. Несколько лет назад они начали постепенно переписывать микросервисы с Java на Kotlin. Результат: среднее количество строк кода сократилось на 30%, количество багов, связанных с |
Лично я в своих проектах в FinTech всё чаще выбираю Kotlin для новых сервисов. Причина проста: меньше кода → меньше ошибок → быстрее доставка ценности бизнесу. Но если команда десятилетиями пишет на Java и не готова переучиваться, я не настаиваю. Важнее результат, а не религиозная приверженность языку.
Заключение
Так кто же выигрывает битву за бэкенд в 2026 году? Если смотреть на цифры вакансий, Java ещё впереди. Но если смотреть на технологический тренд и удобство разработки, Kotlin наступает по всем фронтам.
Мой личный прогноз на ближайшие 2–3 года: Java останется основой для поддержки legacy и крупных корпоративных систем, а Kotlin продолжит завоёвывать новые проекты, особенно в сфере микросервисов и стартапов. При этом граница будет размываться: Loom приблизит Java к удобству корутин, а Kotlin будет впитывать лучшие практики из экосистемы Java.
Когда выбирать Kotlin: если вы стартуете новый проект, хотите писать меньше шаблонного кода, заботитесь о null‑безопасности и планируете использовать асинхронные операции.
Когда оставаться на Java: если у вас огромная кодовая база, команда глубоких экспертов в Java и нет веских причин для перехода, или если вы жёстко привязаны к библиотекам, которые не дружат с Kotlin.
В любом случае, знание обоих языков сегодня — обязательный продукт для серьёзного бэкенд‑разработчика. Если вы хотите прокачать свои навыки в Java или Kotlin на реальных кейсах, приглашаю вас на открытые уроки и курсы в OTUS. Мы разбираем не только синтаксис, но и архитектурные паттерны, асинхронное программирование, работу с базами данных и многое другое — всё то, что делает из просто разработчика востребованного специалиста!
➦ [Посмотреть календарь открытых уроков]
Актуальные открытые уроки по темам, которые сейчас действительно востребованы.
➦ [Перейти к каталогу курсов]
Программы для тех, кто хочет системно прокачать навыки и расти в разработке.
Комментарии (22)
Lewigh
23.04.2026 19:04Реальность:
Язык без какой либо уникальной идеи или киллер-фичи. Просто Java с лучшим синтаксисом.
Полная зависимость от JVM мира. Java может позволить продвигать новые фичи через оптимизацию механизмов JVM. Kotlin только через кодогенерацию и костыли. Kotlin не может позволить себе реализовать такие вещи как специализацию для дженериков или нормальный петтерн-матчинг, потому что придется угробить на это ресурсы а потом сделают в Java более оптимально и повториться история с корутинами. Kotlin вынужден считаться с JVM поэтому никогда не сможет качественно обогнать Java и вынужден быть завязан на ее жизненный цикл. Медленно, но с каждой новой фичей в Java, смысла в Kotlin все меньше а предоставить что-то качественно иное он не может по описанным выше причинам.По поводу производительности, можно просто написать Int и попросить кого-нибудь ответить на вопрос где это число будет размещено в памяти. Без похода в байткод не разобраться.
Совместимость? Хреновая. Можно сколько угодно рассказывать про безопастность по null и наследующем шаге отстрелить себе ноги в любом месте где есть вызов Java кода. И это еще хуже так как от not null типа вообще не ожидаешь NPE, а оно будет. Также большинство либ рассчитано под Java и не все без приседаний и костылей будет работать.
Очевидность и понятность языка - хреновая. В Java, при всех ее минусах, то что написано в коде плюс минус будет в байткоде. Kotlin вам вообще ничего и нигде не гарантирует. Любите читать исходники? Если повезет почитаете не месиво. Если не поведет исходники вы вообще не увидите.
Вот и получается язык без какой то внятной причины для существования. С каждый шагом когда Java медленно но верно завозит сахар, смыла в этом еще меньше. Язык который не имеет контроль над основной своей платформой и в следствии чего вечный аутсайдер.
Лет 5-6 назад, когда были надежды что это будет язык для всех платформ и на нем можно будет делать от бэка до мобилок, фронтов до десктопов - звучало несколько интригующе и смело. Сейчас, когда понятно что загнулись все платформы кроме андроида и JVM, ну такое себе.
panzerfaust
23.04.2026 19:04Согласен с вами почти по всем пунктам, но в то же время считаю, что работать с котлином тупо приятнее. Да, вероятно, в будущем все его фишки появятся в джаве, но мы-то живем сейчас.
Ну и корутины это хороший козырь. Наша система работает на самописном фреймворке на корутинах поверх Vert.x. До этого за асинхронность отвечала RxJava и это была дичь в плане читаемости и сопровождения. На легковесных потоках тоже был бы заковыристый апи. А корутины полностью отрабатывают обещание представлять асинхронный код как синхронный.
Lewigh
23.04.2026 19:04На легковесных потоках тоже был бы заковыристый апи.
А в чем заковыристость, если не секрет?
stdpmk
23.04.2026 19:04Лично моё мнение, что как бы это странно не казалось — код на Котлине не очень то читаемый... val, lateinit var, class MyClass(private val veriable...). итд. Да, вроде кода меньше, а когнитивная нагрузка почему то выше)
Scogun
23.04.2026 19:04Kotlin уже лет 8 не просто Java syntax sugar. Слышали про Kotlin Multiplatform?
Lewigh
23.04.2026 19:04Kotlin уже лет 8 не просто Java syntax sugar. Слышали про Kotlin Multiplatform?
Разуметься. Проблема в том что Kotlin Multiplatform не взлетел.
STFBEE
23.04.2026 19:04Откуда такой вывод?
Lewigh
23.04.2026 19:04Откуда такой вывод?
Ну поправьте если не так но я не наблюдаю сколь значимого интереса у публики, ни ни в виде статей, ни в виде видео, ни на конференциях, ни на проектах. А вот критики хватает. Где то есть немного KMM, но такое чтобы у проекта был и back и web-frontend и мобилки и desktop на KMP скорее на экзотику тянет чем на что-то серьезное. И я молчу что по сравнению с каким нибудь React-native или Flutter, KMP позиции очень слабые.
Используется ли оно? Используется.
Можно ли сказать что идея выстрелила и стала мейнстримной, что можно массово наблюдать целые проекты полностью написанные на Kotlin? Однозначно - нет.
stdpmk
23.04.2026 19:04Да месилово это... Вы пробовали работать с проектом строк на 500к? Голова взорвётся просто
Scogun
23.04.2026 19:04Чем проект на 500k строк на KMP отличается от проекта на 500k строк на Java или C#?
Проверил - мой самый жирный проект на KMP >15k строк, и все чинно-благородно.
Может дело не в KMP таковом?
Dancho67
23.04.2026 19:04Пу пу пу … тяжелый случай. Ну начнем по пунктам.
Котлин мультиплатформенный язык так-то, JVM, LLVM, JS, WASM.
Kotlin не может позволить себе реализовать такие вещи как специализацию для дженериков.
Ну так и у Джавы с этим все стабильно плохо. В dotnet уже как с десяток лет существуют обобщения на уровне рантайма, а в джаве мы продолжаем затирать типы во время компиляции. Вальхаллу уже 15 лет обещают и все никак не сделают. И все же у Котлина с этим получше будет, т.к. есть reified типы, которые позволяют определить тип класса у обобщенных функций не прибегая к рефлексии и все во время компиляции. Сюда же можно отнести и inline функции. В некоторых случаях компилятор Котлина просто уберет type erasure(для примера возьмем любой примитив, без null аннотации) и подставит сгенерированную функцию с необходимым типом. Частичка мономорфезации как у Плюсов, хРуста.
Java более оптимально и повториться история с корутинами.
Тоже спорно, VT конечно лучше обычных потоков, но утилизация процессора на еденицу работы у него кратно хуже, чем у WebFlux, Coroutines. У VT RPS ниже, p99, p95 задержки выше, чем у последних двух. А нормального structured concurency так до сих пор и нету, JEP сидит в инкубаторе с 20 JDK. В Котлине это идет из коробки и будет попроще для восприятия.
Java пример
UserProfile loadUserProfile(String userId) throws Exception { try (var scope = new StructuredTaskScope.ShutdownOnFailure()) { Future<String> userFuture = scope.fork(() -> fetchUser(userId)); scope.join(); scope.throwIfFailed(); String userData = userFuture.resultNow(); try (var innerScope = new StructuredTaskScope.ShutdownOnFailure()) { Future<List<String>> ordersFuture = innerScope.fork(() -> fetchOrders(userData)); Future<List<String>> recommendationsFuture = innerScope.fork(() -> fetchRecommendations(userData)); innerScope.joinUntil(Instant.now().plusSeconds(2)); innerScope.throwIfFailed(); return new UserProfile(userData, ordersFuture.resultNow(), recommendationsFuture.resultNow()); } } }Kotlin пример
suspend fun loadUserProfile(userId: String): UserProfile { return coroutineScope { val userData = async { fetchUser(userId) }.await() val orders = async { fetchOrders(userData) } val recommendations = async { fetchRecommendations(userData) } UserProfile( user = userData, orders = orders.await(), recommendations = recommendations.await() ) } }И VT в Джаве все еще далеко до Корутин из котлина, т.к. если мы захотим побаловаться Reactive Streams, настроить как-то под себя backpressurе, то Джава нас тут оставляет с голым носом и нужно тащить в стек RxJava или Reactor.
Совместимость? Хреновая.
Совместимость у Котлина с джавой лучшая в своем классе. Для ознакомления советую попробовать написать обертки с Жабы на Скалу, интересное занятие, которое никому не порекомендую. Хуже только, у нативных языков, когда нужно прибегать к JNI. А NPE это косяк разработчика написавшего Джава код и забывшего поставить аннотации.
Также большинство либ рассчитано под Java и не все без приседаний и костылей будет работать.
Про наличие библиотек оберток и аналогов говорить или нет?
В Java, при всех ее минусах, то что написано в коде плюс минус будет в байткоде. Kotlin вам вообще ничего и нигде не гарантирует.
Да не уже-ли? For each итератор по списку сгенерирует одинаковый байткод как на Java, так и на Kotlin. Если хотите предсказуемый байткод, так и пишите простой и предсказуемый код, в документации все описанно, где, что и когда генерируется. Каждая фича языка, будь то record в Жабе или data class из Котла сгенерирует вам здоровую портянку кода.
Отдельного упоминания стоят именованные параметры, defauld параметры и перегрузки функций. Как там с ними дела?
Пунктик за который нужно в панамку накидать автору статьи - не указанны фишки Котлина, которых у Джавы пока-что нету и не факт, что будут:
Contracts
Extension methods
SmartCast
Context parameters
Value classes (inline classes)
Power Assert
DSL
Я это все к чему. Котлин в первую очередь проектировался для снижения нагрузки для разработчика и утверждение, что Котлин это просто сахарок от части верно. Но Котлину уже 15-ый год стукнул, за это время он успел обрасти своими уникальными фишками и экосистемой, а после перехода на K2 перед разработчиками открылись двери для введения новых фишек по типу Error types | Unions, позволяющих отказаться от try catch в пользу более понятных ошибок, отлавливаемых еще на этапе компиляции. Котлин проще Джавы в прямом сравнении? По уровню входа Джава проще, по уровню поддержки Котлин выигрывает за счет лучшей читаемости и большей гибкости. Главный плюс это Котлина, что он может работать на любой версии Джавы начиная с 6, а в Java хочешь не хочешь, а придется поднимать JDK до последней версии, если хочется себе какие-нибудь новые плюшки.
З.Ы.
Kotlin это сахар над Java Java это сахар над C++ С++ это сахар над C С это сахар над ASM ASM это сахар над Оп кодами ASM и OpCodes лучшие ЯП. Change my mind.Lewigh
23.04.2026 19:04Котлин мультиплатформенный язык так-то, JVM, LLVM, JS, WASM.
Существует небольшая разница между может и нужен. Scala вон тоже все может, другой вопрос что про знаменитое использование Scala на фронтенде мы чего-то не слышим. В Kotlin все это делали, разумеется и если бы взлетело, у языка было бы сильно больше смысла. Но не взлетело. По факту сейчас Kotlin это андроид, немного backend и еще меньше KPM. Остальным не зашло.
Ну так и у Джавы с этим все стабильно плохо. В dotnet уже как с десяток лет существуют обобщения на уровне рантайма, а в джаве мы продолжаем затирать типы во время компиляции.
Какой смысл говорить что у Java проблемы если язык который ее должен заменить не может решить эти проблемы? И открою секрет, не могут не потому что глупые а потому что зависимы от JVM, не смотря на всю мультиплатформенность. И во многих фичах всегда будут ограничены и придется ждать пока лет через 100 лет не сделают в Java.
Тоже спорно, VT конечно лучше обычных потоков, но утилизация процессора на еденицу работы у него кратно хуже, чем у WebFlux, Coroutines. У VT RPS ниже, p99, p95 задержки выше, чем у последних двух. А нормального structured concurency так до сих пор и нету, JEP сидит в инкубаторе с 20 JDK. В Котлине это идет из коробки и будет попроще для восприятия.
Мне тоже корутины нравятся больше, но вопрос не в этом. Вопрос в том что VM это ментрим который диктует Java и который влияет на всю экосистему Java с которой Kotlin вынужден считаться.
Совместимость у Котлина с джавой лучшая в своем классе. Для ознакомления советую попробовать написать обертки с Жабы на Скалу, интересное занятие, которое никому не порекомендую.
Здорово. Но у Java, с Java экосистемой, совместимость еще лучше. Человека выбирающего между Java и Kotlin мало будет интересовать что там у Scala.
Да не уже-ли? For each итератор по списку сгенерирует одинаковый байткод как на Java, так и на Kotlin. Если хотите предсказуемый байткод, так и пишите простой и предсказуемый код, в документации все описанно, где, что и когда генерируется.
-А что это у нас тут написано?
x : Int-Это целое число.
-Этот ссылочный или примитивный тип?
-Да.Я это все к чему. Котлин в первую очередь проектировался для снижения нагрузки для разработчика и утверждение, что Котлин это просто сахарок от части верно. Но Котлину уже 15-ый год стукнул, за это время он успел обрасти своими уникальными фишками и экосистемой, а после перехода на K2 перед разработчиками открылись двери для введения новых фишек по типу Error types | Unions, позволяющих отказаться от try catch в пользу более понятных ошибок, отлавливаемых еще на этапе компиляции.
Смысл языка в его концептуальной модели, т.е. в ответ на вопрос - а зачем его вообще создали а не выбрали уже существующее решение. К примеру Scala тоже на JVM но концептуальная модель Scala - гибрид ООП + ФП на JVM. У Clojure идея уже про более простую и практичную интерпретацию ФП на JVM. Каждый из этих языков концептуально самодостаточен и особо в этом не пересекается с Java или JVM или друг другом. Также, концептуальная модель есть и у Java, что дико разделяет ее с модельную C#. У других языков все тоже самое. Но вот когда доходит до Kotlin все становиться не понятно. Язык сделали для собственных нужд. Делали по принципу - а давайте понапихайем со всех языков модных фич. Выстрелило на андроид по историческим причинам (привет Java7).
Потом придумали концепцию - пишем все на Kotlin. Идея не взлетела. И по итогу остался язык который, добавляет свистоперделки, с которыми в целом прикольно но можно и без них, но который не решил многих важных проблем Java и вынужден ждать когда она решит их сама, и который вообще не может выбежать за само развитие Java.
Они сделали Error types | Unions? А концептуально оно где должно встать в языке где все на исключениях? В какой-нибудь Scala это сто лет в обед есть и даже больше. Kotlin пере-Java недо-Scala? Или это очередной прием из серии - давайте возьмем модную фичу и запихнем в язык?
В конце концов - проектировался для снижения нагрузки для разработчика? Получилось? Ну спорно. С одной стороны добавилось модных фич, коду стало меньше. С другой появились фичи которые это нагрузку только повышают а в "умелых" руках вообще позволяют писать ахтунг.
Концептуально, ничего такого критического, чтобы отвечало на вопрос зачем переходить с Java на Kotlin, на данный момент нет. Только свистоперделки и по приколу.
gBear
23.04.2026 19:04Просто Java с лучшим синтаксисом.
И гораздо лучшей системой типов. Про это, почему-то всё время забывают.
И речь даже не о nullable или type inference, каких-нибудь… банальное наличие bottom type позволяет “делать вещи”, которые в Java в принципе не работают.
Kotlin не может позволить себе реализовать такие вещи как специализацию для дженериков …
Вообще-то может. И более того, на старте это даже, имнип, рассматривалось. Но оно действительно ломает совместимость со стороны Java кода, и - по большому счету - именно поэтому остались только reified type parameters (которые - "чудес не бывает"™ - тоже нельзя из Java вызывать), которые, с одной стороны, требуют явного использования, а с другой, покрывают львиную долю практической потребности в специализации.
… или нормальный петтерн-матчинг, …
?! Если вы про ML-подобный (с deep deconstruction и т.п.) - так от него тоже отказались осознано, а не потому, что “невозможно”. На практике, PM в Kotlin (в гораздо более продвинутой форме) был (и есть) с самых первых версий. Он постоянно развивается, и - насколько я в курсе - даже в самой своей продвинутой форме (на данный момент) не требует никаких фич от JVM… т.е. вполне себе компилируется в “java 8”.
… потому что придется угробить на это ресурсы а потом сделают в Java более оптимально и повториться история с корутинами.
Вы зря сравниваете корутиты Kotlin и виртуальные потоки Java. Они - сильно “про разное”…
“Зарутиль” корутины на dispatcher, который будет работать поверх виртуальных потоков - вообще не проблема. И в этом даже бывает практический смысл. Условный LOOM.Dispatcher - он хоть и не Kotlin SDK (пока), но ничего “такого” в нем там нет… кроме того, что он вас “прибивает гвоздиками” к вполне конкретной Java SDK. А "мы такое не любим"™
А вот добиться от виртуальных потоков семантики continuation - ровно также “просто”, как и от обычных.
Я это к тому, что ваш посыл про “полную зависимость от JVM мира”, он даже в отношении Kotlin JVM не верен. Даже в Kotlin JVM есть вещи, которые, скажем так, не дружат с “миром JVM”. Но они там, есть, т.к. с точки зрения развития языка “это нам нада”(с).
По поводу производительности, можно просто написать Int и попросить кого-нибудь ответить на вопрос где это число будет размещено в памяти. Без похода в байткод не разобраться.
?! А можно по подробнее, об чём речь? Емнип, правила аллокации в Kotlin полностью аналогичны таким же в Java. Зачем в бейткод-то смотреть? Это раз. А два - если таки вдруг надо, то в чём проблема его посмотреть… этож буквально “пара шорткатов”.
Можно сколько угодно рассказывать про безопастность по null и наследующем шаге отстрелить себе ноги в любом месте где есть вызов Java кода.
Это "вы просто не умете их готовить"™ :-) Во-первых, null safety - оно же, в первую очередь, про свой собственный контракт. Во-вторых, Kotlin тебя честно предупреждает об обнаружении т.н. platform-specific types (и кстати, огромный шаг в этом направлении был сделан как раз с выходом KMP). В том числе, и “в любом месте где есть вызов Java кода”. А то, что такого рода предупреждения - по первости - игнорируются в большинстве своем - так это больше от неопытности, имхо.
Также большинство либ рассчитано под Java и не все без приседаний и костылей будет работать.
А можно чуть подробнее про “приседания и костыли”? Реально интересно, чего вы там “такого” находили, что оно было нужно.
Очевидность и понятность языка - хреновая.
Если я правильно понял, о чём речь - это сугубо дело привычки. Лично про себя (я с Kotlin прям с версии 1.0… т.е. лет десять уже), скажу так.
Если писать в Java style (а оно таки можно, даже если вот лично я смысла особого в этом не вижу) - то разницы тут особой и нет.
Если писать в Kotlin style (необходимый минимум идиоматики) - он непривычен на старте, но и только. Уровень “понятности” - именно что - Java с чуть приятным синтаксисом.
Если к этому добавляется полная идиоматика языка - он ещё более непривычен (не непонятен!!!)… особенно, если предыдущий шаг был пропущен. Но после того, как понимаешь, что читается это исключительно “снизу вверх” (без всякого рода разрыва контекста), что объем “лишнего кода” - это minimum minimorum - возвращение к чтению Java исходников (причем даже в лучшем их виде) ничего кроме раздражения (вот лично у меня) не вызывает.
А “возвращаться” приходится гораздо чаще, чем хотелось бы… к сожалению. Все эти бесконечные проверки на null, upper cast’s и "вот это вот всё"™, про что ты уже и забыл - оно, банально, “мылит глаз”. Продираться через это - удовольствие, прямо скажем, на любителя.
Ну и маленький оффтоп ...
Я, при работе с Java/Kotlin в какой-то момент … достаточно давно уже - словил момент, который у меня был (тож очень давно), когда я, работая долго с Erlang, вынужден был периодически переключаться на C#.
Момент - если на пальцах - заключается в следующем… тебя реально начинают пугать ф-ции, которые не помещаются на экране :-)
С Kotlin/Java ощущения, конечно, слабее были. Но прям очень похоже было :-)
В Java, при всех ее минусах, то что написано в коде плюс минус будет в байткоде.
О да. Особенно - на практике :-) Вы не используете annotation processing? Ну там Spring и/или Lombok? Реально? А что вы такое пишете на Java?
Kotlin вам вообще ничего и нигде не гарантирует. Любите читать исходники? Если повезет почитаете не месиво. Если не поведет исходники вы вообще не увидите.
Тут вообще не понятно “про что”. Если вы про то, что “стандартные” java decompiler’ы сильно плохо дружат с Kotlin - то есть такое. Но есть же специализированные инструменты для. Да даже какой-нибудь шикарный Kotlin Explorer уже как лет пять, емнип, есть. Или вы о чём?
Язык который не имеет контроль над основной своей платформой и в следствии чего вечный аутсайдер.
:-) Рискую открыть вам “страшную тайну”, но даже kotlin 2.3 (самая новая, на данный момент версия языка) компилируется в JDK 1.8 без особых ограничений по, собственно, фичам Kotlin’а. Ну да… какие-то платформозависимые (типа @JvmRecords) аннотации становятся не доступны - но и только.
Это я к тому, что самому Kotlin JVM от самой JVM “много не нужно”.
DmitriyMX
23.04.2026 19:04Если мы говорим про иммутабельные data-классы, то c Java 16 (2021г) существуют record:
record User(Long id, String name, String email) {}Не засчитано.
Kotlin предлагает более функциональный подход с типом
Result<T>...Конечно замечательно, что такое поставляется "из коробки", но из того что мне известно, если есть острая необходимость в подобной обёртке написать такой класс - дело 10 минут.
Не засчитано.
... или использованием
sealed classдля явного моделирования состояний.Каким образом "sealed class" поможет при обработки runtime ошибок? При проектировании архитектуры - да. Для отлова(!) ошибок - нет.
Не засчитано.
IntelliJ IDEA от JetBrains — бесспорный лидер, и поддержка Kotlin в ней идеальна
Думал я так же, пока на одном из проектов случился случай: я использовал последнюю версию IDE на тот момент, ребята в команде - на пару версий ниже. Открываю я в своей IDE проект, а подсветка синтаксиса отваливается, потому что в строке N по мнению IDE написана чепуха, а не синтаксис котлина. При этом всё компилируется и запускается. Когда стал спрашивать коллег, мне предложили либо вручную удалить встроенный котлин-плагин и установить старую его версию, либо установить старую версию IDEA, где уже есть старый котлин-плагин.
Пруфов, увы, не будет. Но я для себя понял, что "обратная совместимость" в Kotlin в JetBrains IDEA не гарантирована.
n7nexus
23.04.2026 19:04Null safety в Kotlin успешно работает лишь если используешь kotlin style либы и фреймворки, либо везде nullable проставляешь.
Так что на бэке, где постоянно используются джавовые либы, эта фича не так уж эффективна(
mmMike
23.04.2026 19:04В Java вы пишете что‑то вроде:
Все. Начало статьи и сразу передергивание (типа lombok не существует) Дальше можно не читать.
Хотя на мой взгляд, все это “вот тут красивее” вообще не принципиально. Все одно на JVM в итоге крутится.
А вообще, выбор между Kotlin и Java - это скорее выбор между IntelliJ и всем остальным. Как то (и это уже увы надолго), выбирать в России продукт от IntelliJ в долгосрочной перспективе (уровень исходников) - это, ну как минимум, рискованно.
Для многих наверное будет открытием, но, как только вам придется пройти сертификацию исходников на Kotlin, то проблемы гарантированы. Ну и разработчика на Java проще найти, если что.
quantumwall
23.04.2026 19:04Тем более, что стандарты красоты субъективны. Лаконично? Да. Красиво? На мой вкус нет. Для меня красиво - это не про наименьшее количество строк, а про структурирование этих строк. Не просто же так есть кодстайлы с их четкими требования по расположению полей объектов, статических полей классов, конструкторов, методов и пр. А если вся программа умещается в одну строку, извините, но это не красиво, это неявно. Лучше потратить несколько строк на java, чем разбирать шумерскую клинопись котлина
ma1uta
23.04.2026 19:04В Kotlin data-классы:
data class User(val id: Long, val name: String, val email: String)В Java record-классы:
public record User(Long id, String name, String email) {}
Совместимость ломается в непредсказуемых местах. Пример: https://github.com/spotbugs/spotbugs-gradle-plugin/issues/972 - в плагине spotbugs есть два enum-а Effort и Confidence. Они лежат рядом, но после переписывания плагина на kotlin один enum недоступен, то есть вот такой конфиг:spotbugs { ... effort = com.github.spotbugs.snom.Effort.DEFAULT reportLevel = com.github.spotbugs.snom.Confidence.DEFAULT ... }приводит к ошибке на старте gradle:
Cannot set the value of extension 'spotbugs' property 'reportLevel' of type com.github.spotbugs.snom.Confidence using an instance of type java.lang.ClassПриходится изгаляться через костыли:
spotbugs { ... effort = com.github.spotbugs.snom.Effort.DEFAULT reportLevel = com.github.spotbugs.snom.Confidence.values()[0] ... }
null-safety?Ловим NPE в непредсказуемых местах из-за оператора
!!, который любят ставить kotlin-разработчики. Или из-за библиотек на java, которые вернули внезапно null. А как вы выполняете проверку на null при переходе от nullable к nonnull?
Поддержка IDE?И ооооооочень долгая компиляция kotlin-программы. В итоге переключение между ветками превращается в ад, когда успеваешь сходить заварить, чай, подождать когда он остынет, выпить, а компиляция ещё идёт. Именно поэтому так носятся с новым компилятором K2, одной из фич которой является более быстрая компиляция.
mihteh
У нас на основном проекте Kotlin + Ktor + Exposed и связка себя прекрасно показала.