Kotlin. Часть 1. Введение

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

Kotlin

Логотип Kotlin, куда же без него

Я хотел бы сэкономить ваше время, по этому не буду разбавлять этот текст цитатами из википедии, а дам только конкретику из своего опыта.

Kotlin - это очередной язык программирования со статической типизацией, который работает на той же виртуальной машине, что и Java. Делали его с 2010 года и не так давно он релизнулся с версией 1.0 (текущая 1.1). Совсем недавно Kotlin вошёл в топ 50 упоминаемых языков по версии индекса Tiobe (ссылка будет в конце).

Куда движется Kotlin?

Честно говоря, не понятно. Ребята, можно сказать, откусили большую часть рынка мобильной android разработки, теперь компилируются в javascript, Spring Framework уже наладили совместимость на бэкэнде, а в данный момент, параллельно с предыдущими активностями, пыхтит проект "Kotlin Native" (это LLVM бэкэнд, об этом в другой раз), который будет компилироваться под конкретную платформу и работать без виртуальной машины. Это напоминает наступление по всем фронтам (и бэкам).

Совместимость

Котлин на 100% совместим с Java. Что это означает? Вы можете взять свой Java проект и разбавить его качественным, концентрированно полезным кодом или наоборот - взять свой проект на Kotlin и написать туда немножко Java (ну как бы поностальгировать). Это одна из причин его большой популярности среди Android разработчиков. Применение первого вида совместимости понятно, вы можете использовать библиотеки типа guava или apache commons. А вот зачем нужно использование Kotlin из Java? Самое очевидное, что приходит на ум это постепенное переписывание старого кода на новый и, конечно, вы можете написать свою библиотеку на Kotlin скомпилировать её для совместимости, например, с Java 6 и использовать в вашем коде. Стоит сразу отметить, что максимальное количество преимуществ вы получаете, когда используете Kotlin вместо написания кода на Java 6.

Nullability

Разработчиков Kotlin охватила аллергия на NullPointerException и они, если и не избавились от NPE окончательно, то точно хорошо постарались, чтобы минимизировать их. Представьте, был у вас String и в нем могло лежать что угодно и строка, и null. Глядя на это JetBrains (да да, разработчики вашей любимой среды разработки еще и языки умеют делать), покачав головой добавили аппендикс вида "?" для типов переменных в которых может храниться null. Итого, в арсенале Kotlin разработчика кроме String появился String?. То же самое с остальными типами.

В Kotlin, по моим оценкам, брата NPE - KotlinNullPointerException (хитро не правда ли?) в 95% случаев можно встретить на стыке совместимости двух языков. Дело в том, что Java не знает ничего ни о каких String?, Int? и MyClass? по этому появляется специальный "платформенный тип". Вы не можете объявить переменную с этим типом сами, но выглядит он так "String!". Мне не хватает еще String% и String#, а вам?

Выведение типов

Пожалуй, лучшая фича Котлина это выведение типов (type inference). Давайте сравним:

Java 6

Map<Integer, String> someMap = new HashMap<Integer, String>();

Java 7, 8

Map<Integer, String> someMap = new HashMap<>();

Kotlin

val someMap = HashMap<Integer, String>()

Моё лицо, когда код стал короче на пару символов

В Котлине есть два ключевых слова без которых не обходится декларация ни одной переменной, это val и var. Наличие типа не обязательно, если сразу следует его декларация. Val и var означают immutable или mutable переменная соответственно. Т.е. на уровне компилятора у вас есть гарантии, что если вы написали val abc = "ok" в начале метода, то к концу метода никто не мог поменять это значение (никто никогда не использует final для переменных в Java, только зануды и разработчики библиотек).

Умное приведение типов

Приятная фишка Котлина - это "умное" приведение типов. Пример ниже:

val a: String? = "abc"
if(a != null) {
    println(a.toLowerCase()) // если убрать if - код не скомпилируется
}

Компилятор "по умному" приводит String? к String и это снимает 85% оверхеда привносимого с Nullability.

Пара моментов, которых нас лишили

Здесь, естественно, не всё, а то, вы бы уснули от скуки.

Элвис бы в гробу перевернулся

Разработчики Kotlin дали нам замечательный Elvis оператор, который выглядит вот так ?: (поверните голову на -90 градусов и поймете почему elvis) и позволяет делать вот такие вещи

val a: Int? = null
val b: Int = a ?: 0 //b = 0

если мы нащупали null, то мы можем предложить что-то в замен, в одну строку, но вот при этом всём у нас, джавистов, наглым образом забрали тернарный оператор, а именно, конструкцию:

val a = isBusy ? 1 : 0 // так сделать нельзя, не скомпилируется
val a = if(isBusy) 1 else 0 // а так можно, но это - уродство

Обещали вернуть, но посмотрим.

А циклы чем не угодили?

Второе чего нас лишили это

for(int i = 0; i < x; i++)

Нету больше этой конструкции в Kotlin. Искренне жаль, т.к. это крайне привычно в любом языке. Здесь на смену приходят Ranges - диапазоны. Не то чтобы диапазоны - это хуже, но "фор"-то куда забрали...

Подытожим

Сегодня мы провели вводную в Kotlin, познакомились с некоторыми особенностями этого языка и мельком взглянули на код. Это была первая статья в цикле. Далее будет еще несколько статей, в которых я расскажу о различных вариантах применения языка.

На этом всё. Здесь и закончим. Пока!