Особенности 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.

🔴️️️️️️ Стрим в 17:00 МСК в субботу

Расскажем про fuzz-тестирование и про новую библиотеку kotlinx.fuzz для написания таких тестов.

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

Telegram | YouTube | Twitch

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

Расскажем про то, как находить больше багов с помощью fuzz-тестирования с помощью новой библиотеке kotlinx.fuzz для написания таких тестов.

Telegram | YouTube | Twitch

Production-ready Compose Multiplatform

Не так давно произошло большое событие – вышла стабильная версия CMP под iOS. JetBrains заявляет, что Compose Multiplatform теперь является стабильным и KMP сейчас является полным решением для мобильной разработки – от общей бизнес логики вплоть до общего нативного UI.

Перед этим CMP под iOS находился довольно продолжительное время в нестабильном состоянии и многие довольно скептично относились к дальнейшему развитию технологии, но сейчас, возможно, он поменяет рынок.

До этого на рынке доминировали технологии по типу Flutter или React Native, которые рекламируются как компромисс в виде лишения возможности использовать платформенно-специфичное API в в обмен на кроссплатформенный UI. Теперь появилась стабильная технология, которая позволит писать кроссплатформенный UI с возможностью вызывать любые platform-specific API.

Но я считаю, что писать кроссплатформенный UI всё же не очень хорошо во многих случаях. Это может быть хорошо в случаях, когда надо быстро написать мобильное приложение, сэкономив на том, что UI пишется один раз. Однако если есть какие-то сложные UI-компоненты всё же было бы проще писать UI нативно, сэкономив только на написании общей логики при помощи KMP, где будет попроще вынести некоторую логику платформенной реализацией. Или, к примеру, есть рассчёт на поддержку приложения на долгосрочной перспективе – тут тоже было бы проще писать нативно UI на обеих платформах, потому что приложение рано или поздно будет обрастать сложной логикой, что сложно было бы поддерживать используя кроссплатформенный UI, если есть рассчёт на некоторое развитие приложения. Также у кроссплатформенного UI могут быть проблемы с перформансом.

И самое главное, с чем могут возникнуть проблемы при написании кроссплатформенного UI – соответствие гайдлайнам конечных платформ. Есть некоторые библиотеки для CMP с поддержкой material 3/human design, но эти стандарты отличаются друг от друга и всё равно финальная вёрстка будет отличаться на конечных платформах. Тут вступает в силу трейд-офф, по которому вы должны писать свою platform-agnostic дизайн-систему, из-за чего приложения будут выглядить менее естественными.

А как думаете вы?