Год назад языку Kotlin пророчили, что к концу 2018-го он станет популярнее Java в разработке приложений для Android. Новость о первенстве Kotlin как о свершившемся факте пока не прозвучала, но ещё и год не окончился. Между тем, всё больше белорусских ИТ-компаний переходят на новый язык. Некоторые, правда, не очень успешно: dev.by известно об одной компании, которой пришлось свернуть эксперимент. Мы собрали мнения разработчиков, попробовавших продукт компании JetBrains. Идеального разделения на Pro&Сontra не получилось, но поводы для дискуссии есть.
«Java останется с нами, но фокус сместится на Kotlin»
Руслан Ибрагимов, лидер белорусского Kotlin User Group:
Многие белорусские компании сейчас заявляют о том, что они используют Kotlin в разработке. Это Juno, Flo, Apalon, cyber•Congress, Id Finance, exp(capital), Яндекс, Itransition, Gismart и другие. В большинстве своём это, конечно, Android проекты, но некоторые из этих компаний используют Kotlin и на бэкенде.
Про Kotlin/Android
Массовый переход на Kotlin на Android-проектах начался, очевидно, в мае 2017 года, когда Google на конференции Google I/O заявила об официальной поддержке Kotlin на Android. Нужно понимать, что это было движение снизу вверх, то есть сначала множество разработчиков оценило удобство разработки на Kotlin под Android, а потом уже Google, увидев в Kotlin реальную альтернативу Java для платформы, сделала его официальным языком. Многие компании использовали Kotlin под Android ещё до Google I/O, а сейчас проще пересчитать проекты, которые не собираются переходить на Kotlin.
Вообще вся эта история напоминает то, как Google анонсировал Android Studio: официально говорилось что будет поддерживаться и старая IDE, основанная на Eclipse, и новая Android Studio, основанная на Intellij Idea CE. Но по факту, конечно, от поддержки Eclipse они отказались. Очевидно, такая же судьба ждёт и Java. Java останется с нами, но фокус Google наверняка сместится с Java на Kotlin.
Про Kotlin/JVM
Если на Android Kotlin уже победил, то на Server Side не всё так однозначно. Хотя Java и начала делать релизы чаще, но фич, которые значительно повышают продуктивность Java разработчика и качество его кода, становится всё меньше с каждым релизом. Так, в JDK 11 фактически не было достойных внимания фич. В то же время Kotlin, хотя и является инкрементальным улучшением с точки зрения внедрения в проект, позволяет значительно повысить качество, читаемость кода и искоренить в проекте некоторые типы ошибок.
Несмотря на это, в массе своей бэкенд разработчики не спешат переходить на Kotlin. С одной стороны, в этом может быть виноват менеджмент, который видит риск в новом языке. Наверняка они уже проходили историю с ещё одним JVM языком в проект и не верят, что Kotlin в этом плане значительно отличается от Scala, Groovy или Clojure. С другой стороны, есть разработчики, которых устраивает текущий порядок вещей, и они не хотят учить новый язык.
Радует, что множество крупных проектов обратили внимание на Kotlin и поддерживают его или используют для того, чтобы сделать лучшие инструменты для разработчиков. Так, можно выделить Spring Framework, развиваемый Pivotal, и систему сборки Gradle. Spring уже давно заявили о поддержке Kotlin, а сейчас даже разрабатывают экспериментальный микрофреймворк spring-fu на Kotlin. Gradle тоже использует на всю мощь Kotlin в проекте Gradle Kotlin DSL, который позволяет писать билд-скрипты на Kotlin. В результате разработчик получает все прелести статически типизированного языка как автодополнения, проверку корректности скрипта, документацию — всё то, чего не было при использовании Groovy.
Кстати, если вы хотите больше узнать о spring-fu, то приходите на jfuture.by, там будет доклад от создателя этого фреймворка.
Про сообщество
Целью сообщества Belarus Kotlin User Group является популяризация языка Kotlin и помощь разработчикам.
Можно сказать, сообщество отделилось от Java Professionals By, и до сих пор ядра сообществ очень сильно пересекаются. Первый митап мы провели буквально через месяц после релиза Kotlin 1.0. (Хотя о Kotlin я рассказывал ещё на митапе Java Professionals By, который состоялся через день после первого релиза). Кажется, это была первая Kotlin User Group в мире, сейчас же подобных сообществ насчитывается больше 160-и.
За всё время мы провели 10 митапов и не собираемся на этом останавливаться. Разные компании обращаются к нам за консультацией: например, просят прийти к ним и рассказать о Kotlin.
4-5 октября пройдет KotlinConf — главная конференция для разработчиков на Kotlin. И в этом году для всех будет доступна трансляция первого потока. В свою очередь, BKUG организует просмотр трансляции в SPACE.
«Сократилось время разработки и количество ошибок»
В компании Flo начали переводить Android-разработку c Java на Kotlin в январе 2018 года. СТО компании Роман Бугаев и разработчик, сооснователь сообществ GDG Minsk и Android Academy Павел Щегельский рассказали, как это было.
Павел Щегельский о мотивах
— Почему приняли такое решение? Во-первых, Kotlin даёт нам скорость разработки. Как правило, фичу надо было написать ещё вчера, и то, что 10 строчек можно заменить одной, сильно упрощает жизнь бизнеса.
Во-вторых, наш код становится более безопасным. Теперь мы понимаем, где и как можно использовать ту или иную переменную и какого типа она будет. Это была одна из проблем в Android-фреймворке на Java: ты не всегда понимал, стоит ли обрабатывать ошибку. Например, можно ли передавать nullable тип в функцию, будет ли возвращаемый тип nullable. Если в комментариях к методу нет чёткого описания, то ты не всегда уверен, вернёт он безопасное значение или нет.
Kotlin даёт явную возможность это указать, понимание кода значительно упрощается. И сейчас Android команда стала уже в Java коде обставлять эти случаи аннотациями, то есть Kotlin положительно повлиял на фреймворк Java.
В-третьих, с Kotlin мы всё больше приобщаемся к функциональному программированию, меняя майндсет. Код на Kotlin легче читается, чем на Java. На нём можно писать как в терминах предметной области, так и в терминах языка, но уже продвинутого языка, с поддержкой многих фич.
А ещё Kotlin и Java могут работать вместе: какая-нибудь штука в Kotlin легко интерпретируется на уровне Java. Конечно, иногда привносится overhead, поэтому к некоторым механизмам надо подходить с умом. Это основной минус. Других явных минусов за два года использования Kotlin я не нахожу. Плюсов гораздо больше.
Кому Kotlin может не понравиться? Возможно, тем людям, кому лень или трудно оставаться на волне новых трендов. Они еле освоили Java, а теперь их заставляют ещё один язык учить, быть в курсе новостей.
Сейчас в нашей компании открыто много вакансий, и тот факт, что наша разработка Kotlin based, мы стараемся обязательно упоминать. Это даёт преимущество компании в глазах кандидата. Если компания инвестировала в Kotlin, это значит, что она следит за тенденциями, использует современные инструменты и ценит комфорт разработчика. А кроме того, поработав у нас, разработчик сможет добавить хороший пунктик в резюме: для Android-программиста не знать Kotlin в 2018 году — это очень плохо.
Google настолько активно популяризирует Kotlin как официальный язык разработки под Android, что на рынке скоро будет больше разработчиков на Kotlin, чем на Java. И если какая-нибудь компания будет продолжать вкладываться в Java, то скоро она не сможет найти себе разработчиков.
Роман Бугаев о результатах
— Пока на Kotlin у нас только Android-разработка. Да ещё команда QA используют Kotlin для написания функциональных тестов для сервера и Android. Была идея также писать на Kotlin серверные решения, но мы от неё отказались: по сути, серверных разработчиков, владеющих Kotlin, не так много. Если же говорить про Android-разработчиков, то сейчас уже сложно найти программистов, готовых идти на проект с языком Java вместо Kotlin.
По отношению к Kotlin программисты настроены дружелюбно, так как они получают инструмент, который сильно упрощает им жизнь. Язык даёт им много «синтаксического сахара»: это когда можно написать что-то более простым способом.
И по количеству фичей в производстве, и по времени на их разработку в компании Flo серьёзный прогресс. Не уверен, что это связано только с переходом на Kotlin (одновременно у нас менялась архитектура, в компанию пришли более сильные программисты), но среднее время разработки одной фичи сократилось с 20 до 5 дней.
Кроме того, за последние 90 дней число ошибок (non-fatal exceptions) в коде сократилось в два раза. Если раньше у всех пользователей суммарно было 9 млн событий в день, то сейчас — 3,6 млн. Несмотря на столь большие цифры, приложение у нас качественное: признаком этого является рейтинг в Google Play — 4,9.
При этом надо понимать, что за эти 9 месяцев мы перевели на Kotlin только 35% кода Android-разработки приложения, который писали более 2 лет. Но у нас и нет цели переписать весь код на Kotlin. У нас прагматичный подход: если мы работаем над какой-то фичей, которая затрагивает код, то мы его переводим на Kotlin. Если мы этот функционал не трогаем, то так на Java и живём.
И всё же процент перехода — довольно большой. Это связано с тем, что компания-создатель языка JetBrain сделала переход на Kotlin очень лёгким, частично он делается автоматически. Берётся Java-код, конвертируется в Kotlin, а дальше разработчик смотрит результат и добавляет пропущенные элементы.
О том, почему только Android
— Основной сдерживающий фактор использования Kotlin за пределами Android-разработки — это количество разработчиков. Kotlin — один из языков программирования в JVM мире (Java Virtual Machine), которые компилируются в Java-код, но не единственный. Если сравнивать Kotlin с другими языками семейства JVM, например, Groovy и Scala, то на них гораздо больше программистов. Наши бэкенд-разработчики предпочитают использовать язык Scala, в котором, как и в Kotlin, делается упор на функциональное программирование. У него те же преимущества, что и у Kotlin, плюс большое число разработчиков.
Кроме того, компаний, которые пишут бэкенд на Scala, намного больше. Это и Twitter, и LinkedIn, и Uber. Поэтому на Scala есть фреймворки, которые оптимизированы под бекэнд-разработку.
Будут крупные разработчики — появится и инфраструктура, позволяющая писать бекэнд на Kotlin. Пока этого нет, и нужны сильные вендоры, которые будут вести этот рынок.
Ещё мы с интересом следим за кроссплатформенной разработкой для Kotlin. Если у них получится, это окажет большое влияние на рост популярности языка. Если на Kotlin можно будет делать разработки и под iOS, и под Android, и бекэнд, это будет означать, что один и тот же программист сможет делать фичу от А до Я, один человек заменит троих.
Правда, это похоже на создание «серебряной пули», не знаю, насколько это реалистично.
«Навигация отваливается, и скрипт краснеет»
Александр Росолько, разработчик в компании Tispr, на Kotlin пишет «домашние» проекты, делает вклад в open source. Участвует в разработке библиотеки Selenide (один из новых модулей будет написан полностью на Kotlin) на GitHub.
— К Kotlin отношусь нейтрально: как и во всяком языке, в нём есть и плюсы, и минусы.
Плюсы в том, что язык даёт много синтаксического сахара, удобных конструкций и избавляет от шаблонного кода. Это потенциально делает ваш код более компактным и менее «багованным», а также более простым и читаемым. И, наверное, повышает вашу эффективность и продуктивность.
Так как язык появился относительно недавно, одной из больших проблем является недостаточно большое комьюнити.
Отсюда вытекает и вторая проблема — недостаточное количество ресурсов для обучения.
На данный момент количество библиотек, написанных и работающих с Kotlin, невелико, причём львиная доля их заточена под Android-проекты.
Из этого вытекает следующий минус: почему-то Kotlin многие считают созданным именно под Android, поэтому другие проекты на нём даже не пробуют писать. Хотя на деле Kotlin позволяет делать всё то же, что и с Java, и даже немного больше.
Также досадным является тот факт, что скорость компиляции кода на Kotlin медленнее в сравнении с той же Java.
Следующая большая проблема Kotlin — это интеграция с текущими билд-системами.
Возьмём популярную билд-систему Gradle: изначально билд-скрипты использовали и используют на синтаксисе языка Groovy. Он так и называется — Groovy-скрипт. Он работает быстро, однако у него довольно высокий порог вхождения, а без навигации по методам (конструкция) иногда непонятно, что происходит в том или ином месте, и как это вообще работает.
Потом нам представили Kotlin-скрипт. Он работает, и неплохо, но очень медленно.
Плюс к этому часто хвалёная навигация по скрипту «отваливается». И становится очень грустно, когда почти весь скрипт «краснеет», а подсказки редактора говорят вам, что «всё очень плохо». Решается эта проблема перезапуском среды разработки. Операция простая, но это не лучшее решение проблемы.
Если в вашем проекте на Groovy использовалась конфигурация с применением нескольких скрипт-файлов (которые в дальнейшем были использованы в основном), то с применением Kotlin-скрипта вы лишаетесь этой возможности. Так как использовать подскрипты в одном скрипте на Kotlin попросту невозможно, придётся все описать в одном основном скрипте, который может получиться очень большим. Надеюсь, что в дальнейшем такая возможность всё-таки появится.
«Пугает костыльность реализации»
Александр Бруй, Java разработчик в ITS Partner. Думаю, Kotlin наиболее актуален сейчас для Android-разработки из-за сильного отставания «мобильной» Java от её «взрослой» версии. Перспективе писать код на старой Java 7 я предпочту использовать Kotlin.
Изначально Kotlin мне был интересен именно как «Java с модным синтаксисом», работающий на том же JVM, так как развитие синтаксиса у Java шло очень медленно. С выходом 8-й версии Java стал намного приятнее.
Учитывая, что развитие Java ускорилось с переходом на полугодовой релизный цикл, думаю, этот язык будет постепенно модернизироваться. При таком положении вещей смысл переходить на Kotlin есть только в тех случаях, когда нет желания/возможности постоянно мигрировать на свежую версию Java.
JVM не единственная платформа для работы Kotlin, а значит, этот язык будет пытаться максимально абстрагироваться от специфики работы JVM на уровне синтаксиса, и мало ли к каким ограничением это приведет в будущем. Сейчас это хорошо видно на примере специфичных аннотаций для тех случаев, когда надо использовать эту специфику.
Kotlin старается быть совместимым сразу с несколькими мажорными версиями JVM, и это приводит к тому, что он не пользуется «новыми возможностями» более новых JVM. Хотя теоретически, конечно, может этому научиться.
Кроме этого, мне не нравится подход Kotlin в реализации каких-то сложных «фич» без поддержки их же на уровне платформы. К примеру, корутины. То, как это работает «под капотом», пугает меня «костыльностью» реализации: уж лучше я подожду Project Loom на Java, где это сделают максимально адекватно.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.