Эмоджи Kotlin теперь в Telegram!
Возможно, вы уже видели такие эмоджи у кого-то в статусе:🏝 🏝 🏝 ⏯ 😾 . Этот пак был создан @y9san9, а большинство стикеров было подготовлено @y9maly.
На этом KotlinConf был аннонсирован ребрендинг для🏝 Kotlin Multiplatform и 🎨 Compose Multiplarfom, новые эмоджи уже повились в паке благодаря @y9maly.
Telegram | YouTube | Twitch
Возможно, вы уже видели такие эмоджи у кого-то в статусе:
На этом KotlinConf был аннонсирован ребрендинг для
Telegram | YouTube | Twitch
Please open Telegram to view this post
VIEW IN TELEGRAM
"У меня вообще нет желания писать на 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
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
Что по вашему должен выводить код на картинке?
Anonymous Quiz
24%
true
42%
false
33%
Ошибка компиляции
До версии Kotlin 1.6 код бы просто упал с ошибкой компиляции, и ведь логично, созданная лямбда ну никак не похожа на интерфейс Test. Но в последующих обновлениях
Это нужно для удобной работы с Java-функциями, которые в качестве параметров часто принимают такие интерфейсы. Начиная с версии Kotlin 1.6 их стало вызывать также просто, как и родные Kotlin функции.
И никакой особой магии тут нет, компилятор просто генерирует обёртку для лямбды. На картинке представлен примерный вид скомпилированного кода. Тут, как я и говорил, становится очевидно, почему же код вывел false: у нас 2 разных объекта.
Иногда красивые синтаксические конструкции не бесплатны. Будем рассказывать и дальше о таких штуках в этом канале.
Разобрались кто такие языковые сервера, а также: Почему они есть для всех языков программирования, а для Kotlin раньше не было? Что поменялось сейчас, что JetBrains решили выпустить LSP для котлин? Зачем JetBrains официальная поддержка Kotlin в VSCode?
Мы смогли скачать и проверить как работает первая версия LSP, и, спойлер, ошибки подсвечиваются моментально. Я был очень приятно удивлён, и сделал сравнение анализа одного и того же кусочка кода в VSCode и Intellij Idea.
YouTube
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
👀9🔥3❤1👍1
Rich Errors: В Kotlin 2.4 появятся Union-типы?
И да, и нет. Для тех, кто не знает, что такое Union-типы, – они позволяют создавать новые типы на основе существующих, подобно логическому оператору ИЛИ.
Например, конструкция userId: String | Int означает, что переменная может принимать значения либо строки, либо числа. Такое существует во многих языках программирования, таких как TypeScript, Python, C# (когда-то в будущем) и др.
В Kotlin же Union-типов не будет скорее всего никогда. Вместо этого предлагается использовать этот же синтаксис для выражения возможных ошибок при выполнении функции (что-то похожее на джавовое throws, но сделанное правильно).
🔴 Обсудим это на стриме уже в субботу в 17:00 МСК. Приходите!
Telegram | YouTube | Twitch
И да, и нет. Для тех, кто не знает, что такое Union-типы, – они позволяют создавать новые типы на основе существующих, подобно логическому оператору ИЛИ.
Например, конструкция userId: String | Int означает, что переменная может принимать значения либо строки, либо числа. Такое существует во многих языках программирования, таких как TypeScript, Python, C# (когда-то в будущем) и др.
В Kotlin же Union-типов не будет скорее всего никогда. Вместо этого предлагается использовать этот же синтаксис для выражения возможных ошибок при выполнении функции (что-то похожее на джавовое throws, но сделанное правильно).
🔴 Обсудим это на стриме уже в субботу в 17:00 МСК. Приходите!
Telegram | YouTube | Twitch
💬 Впервые за долгое время мы наконец смогли собраться в Москве российским Kotlin-сообществом в ФКН ВШЭ.
Хорошая новость в том, что это мероприятие планируется делать серийным и в разных городах (там, где найдём докладчиков). Если хотите встретиться и пообщаться со мной и Эмилем оффлайн, то самое то.
За анонсами можно будет следить в канале Kotlin Russia: https://t.iss.one/kotlin_russia
Хорошая новость в том, что это мероприятие планируется делать серийным и в разных городах (там, где найдём докладчиков). Если хотите встретиться и пообщаться со мной и Эмилем оффлайн, то самое то.
За анонсами можно будет следить в канале Kotlin Russia: https://t.iss.one/kotlin_russia
❤12😭1
🔴 Сегодняшний стрим переносится на завтра
Возникла куча обстоятельств, которые не зависят от нас, и по которым мы никак не сможем сегодня предоставить полезное обсуждение по теме.
Завтра в это же время (17:00 МСК) присоединяйтесь к стриму, который мы сможем хорошо для вас подготовить. Будем обсуждать Rich Errors в Kotlin и Union-типы.
Все остальные стримы планируем также по расписанию каждую субботу в 17:00 МСК.
Возникла куча обстоятельств, которые не зависят от нас, и по которым мы никак не сможем сегодня предоставить полезное обсуждение по теме.
Завтра в это же время (17:00 МСК) присоединяйтесь к стриму, который мы сможем хорошо для вас подготовить. Будем обсуждать Rich Errors в Kotlin и Union-типы.
Все остальные стримы планируем также по расписанию каждую субботу в 17:00 МСК.
👍10
🔴 Мы в прямом эфире!
Тема стрима – Rich Errors: В Kotlin 2.4 появятся Union-типы? Обсудим как это реализовано в других экосистемах, и что именно предлагается ввести в Kotlin.
В этот раз мы подключили чатик к онлайн-трансляции, так что будет сразу видеть ваши сообщение. Но работать он будет только из твича, так что пишите туда.
Telegram | YouTube | Twitch
Тема стрима – Rich Errors: В Kotlin 2.4 появятся Union-типы? Обсудим как это реализовано в других экосистемах, и что именно предлагается ввести в Kotlin.
В этот раз мы подключили чатик к онлайн-трансляции, так что будет сразу видеть ваши сообщение. Но работать он будет только из твича, так что пишите туда.
Telegram | YouTube | Twitch
🔥6❤1
В среду мы готовим полноценный ролик с разбором новой фишки Kotlin – Rich Errors a.k.a. Union-типы для ошибок (если вы из будущего, где ролик уже выложен, то обязательно гляньте!).
Я зарисовал на картинке минимальный пример с демонстрацией новой фичи для работы с ошибками. И да, эта фича вообще никак не связана с исключениями. Слева в типе указывается успешный результат, справа – все виды ошибок, которые могут произойти. Подобно тому, как работает Result в Rust, Either в Haskell, Ocaml, Scala, Error Union Type в Zig и error в Go.
Читайте ниже про новый синтаксис.
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤4
Особенности error class
Для того, чтобы тип мог использоваться в правой части Union-а, его необходимо объявить через специальную декларацию error class. Ограничения на такие классы:
• error class не может быть abstract/open
• error class не может содержать дженериков
Так почему же в каком-нибудь TypeScript я могу написать:
А в Kotlin эта фича будет работать только для 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 разработали быстрый алгоритм для проверки на сходство типов.
И этот тот самый случай, когда перформанс НЕ является примером Premature Optimization. Дело в том, что проверка того, является ли один Union-тип подтипом другого Union-типа – это неразрешённая проблема. Это приводит к экспоненциальному росту времени проверки при добавлении новых подтипов в Union-тип.
В других языках такая проблема есть, но с ней живут. Так, в мире TypeScript оптимизация времени проверки типов – это одна из актуальных задач на большом проекте. Но при разделении на "основной" и "побочные" типы, ребята из JetBrains совместно с Ross Tate разработали быстрый алгоритм для проверки на сходство типов.
❤3