🔴 Мы в прямом эфире!

Сегодня будем обсуждать Kotlin LSP – поддержку для альтернативных редакторов, дальнейшие планы, влияние на экосистему и что было до оффициального LSP.

Telegram | YouTube

"У меня вообще нет желания писать на Java", – создатель Spring.

Kotlin уже давно завоевал сферу Android и является стандартом индустрии не только де-факто, но и де-юре. При этом остаётся огромная ниша, где, казалось бы, не ожидается смещение Java в долгой перспективе. Подвижка – возможно, но серьёзное смещение – нет.

И вот, месяц назад, выходит передача Talking Kotlin, в которой создатель Spring рассказывает о том, как отлично дружит Kotlin и Spring (откуда я и взял цитату из заголовка). А на этой неделе Spring и JetBrains официально объявили о сотрудничестве. Spring со своей стороны будет делать более Kotlin-friendly API, но что действительно интересно – даже подготовит обучающие материалы для Spring на Kotlin. Подробнее можно прочитать в блог-посте.

Какие выводы можем сделать из этой новости мы?

Во-первых, спешу развеять ваши сомнения, Ktor точно живёт как раньше. Про его развитие JetBrains продолжают рассказывать на KotlinConf. На него ставится огромная ставка в мультиплатформенном IO. Во-вторых, все мы, включая сам Ktor, выиграли от этого решения. Рассказываю, как я вижу эту ситуацию:

• Spring заявили о сотрудничестве с JetBrains и первоклассной поддержке Kotlin.

• Java-разработчики, которые даже не рассматривали Kotlin, задумаются об использовании этого языка.

• Будет намного проще убедить бизнес использовать Kotlin, когда речь идёт о разработке на Spring.

• Новый пласт Java-разработчиков увидит классные сахарные конструкции Kotlin и захотят попробовать что-то, сделанное специально под Kotlin.

• Они пойдут пробовать Ktor, и он им скорее всего понравится своей легковесностью и кастомизируемостью.

А что думаете вы?

Telegram | YouTube | Twitch

Rich Errors: В Kotlin 2.4 появятся Union-типы?

И да, и нет. Для тех, кто не знает, что такое Union-типы, – они позволяют создавать новые типы на основе существующих, подобно логическому оператору ИЛИ.

Например, конструкция userId: String | Int означает, что переменная может принимать значения либо строки, либо числа. Такое существует во многих языках программирования, таких как TypeScript, Python, C# (когда-то в будущем) и др.

В Kotlin же Union-типов не будет скорее всего никогда. Вместо этого предлагается использовать этот же синтаксис для выражения возможных ошибок при выполнении функции (что-то похожее на джавовое throws, но сделанное правильно).

🔴 Обсудим это на стриме уже в субботу в 17:00 МСК. Приходите!

Telegram | YouTube | Twitch

💬 Впервые за долгое время мы наконец смогли собраться в Москве российским Kotlin-сообществом в ФКН ВШЭ.

Хорошая новость в том, что это мероприятие планируется делать серийным и в разных городах (там, где найдём докладчиков). Если хотите встретиться и пообщаться со мной и Эмилем оффлайн, то самое то.

За анонсами можно будет следить в канале Kotlin Russia: https://t.iss.one/kotlin_russia

🔴 Сегодняшний стрим переносится на завтра

Возникла куча обстоятельств, которые не зависят от нас, и по которым мы никак не сможем сегодня предоставить полезное обсуждение по теме.

Завтра в это же время (17:00 МСК) присоединяйтесь к стриму, который мы сможем хорошо для вас подготовить. Будем обсуждать Rich Errors в Kotlin и Union-типы.

Все остальные стримы планируем также по расписанию каждую субботу в 17:00 МСК.

🔴 Мы в прямом эфире!

Тема стрима – Rich Errors: В Kotlin 2.4 появятся Union-типы? Обсудим как это реализовано в других экосистемах, и что именно предлагается ввести в Kotlin.

В этот раз мы подключили чатик к онлайн-трансляции, так что будет сразу видеть ваши сообщение. Но работать он будет только из твича, так что пишите туда.

Telegram | YouTube | Twitch

Особенности error class

Для того, чтобы тип мог использоваться в правой части Union-а, его необходимо объявить через специальную декларацию error class. Ограничения на такие классы:

• error class не может быть abstract/open
• error class не может содержать дженериков

Так почему же в каком-нибудь TypeScript я могу написать:

type MessageId = string | number

А в Kotlin эта фича будет работать только для error class-ов?

Перформанс

И этот тот самый случай, когда перформанс НЕ является примером Premature Optimization. Дело в том, что проверка того, является ли один Union-тип подтипом другого Union-типа – это неразрешённая проблема. Это приводит к экспоненциальному росту времени проверки при добавлении новых подтипов в Union-тип.

В других языках такая проблема есть, но с ней живут. Так, в мире TypeScript оптимизация времени проверки типов – это одна из актуальных задач на большом проекте. Но при разделении на "основной" и "побочные" типы, ребята из JetBrains совместно с Ross Tate разработали быстрый алгоритм для проверки на сходство типов.

Rich Errors не заменяют sealed interface, а делают работу с неудачными сценариями проще, чем это можно достичь с sealed interface. И это я бы назвал Game Changer-ом для распространения подхода Errors as Values.

Для полноценной замены Union-типов, возможно, стоит ожидать нового удобного синтаксиса для sealed interface из этого тикета в YouTrack.

Rich Errors также не заменяют исключения, и они всё ещё нужны в своей нише, а именно – логические ошибки программиста. Подобно тому, как работает panic в Go и Rust, и fatalError в Swift.