Релокейт-опрос 2017 (для тех, кто уже уехал). Собрано более 1500 анкет.
×Закрыть

Без хайпа и маркетинга: нужен ли вам Kotlin?

В рамках QAFest 2017 автор блога automation-remarks.com и Lead QA Automation Engineer в Ciklum Сергей Пирогов рассказал, как он докатилися до Kotlin и что из этого вышло. Для читателей DOU, которые не присутствовали на конференции, Сергей изложил этот опыт в авторской статье.

Меня зовут Сергей Пирогов. Уже более пяти лет я занимаюсь вопросами автоматизации тестирования на проектах различного масштаба и сложности. В основном я занимаюсь автоматизацией тестирования с использованием технологий из мира Java.

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

Предыстория: Java, Groovy и другие альтернативы

Java является самым старым и популярным языком на JVM. Отличный язык и инфраструктура. Бесспорный фаворит различных рейтингов среди языков программирования. На Scala мы проектов писать не пробовали из-за излишней сложности, а вот на Groovy писали и достаточно успешно. Этим опытом я делился на конференции Selenium Camp 2016. Увы, Groovy умирает и появление Kotlin его агонию лишь ускоряет.

Откуда взялся этот ваш Kotlin?

Kotlin — достаточно молодой язык, который разрабатывается и спонсируется компанией JetBrains. Из открытых источников можно узнать, что в разработку языка было вложено более $15 млн, а сам язык — это еще один способ популяризовать компанию и еще больше повысить продажи для Idea.

Язык начал набирать популярность после того, как на конференции JavaOne 2015 Hans Dockter, CEO of Gradle, заявил, что Kotlin получает официальную поддержку для написания Gradle билд-скриптов. Тогда Kotlin все еще был в бете, но новость всколыхнула всех неравнодушных. Волна хайпа начала подниматься уже в тот момент. На пике популярности язык оказался в мае этого года на конференции Google I/O, где было объявлено о том, что Kotlin наряду с Java становится официальным языком разработки под платформу Android. Тут-то всех и «лупануло»: весь Twitter был в постах о Kotlin, появилась куча блог-постов с признаниями в любви языку. Представители JetBrains в различных источниках стали заявлять, что Kotlin — это будущее разработки на JVM.

В целом если смотреть на ситуацию здраво, то причины хайпа вполне понятны. Джава развивается слишком медленно. Java 8 появилась аж в 2014 году, Java 9 на момент публикации уже вышла, но в самом языке слишком мало вкусных фишек. Более того, с Java 9 у многих все в момент перестало работать. И тут людям дают язык, наполненный фичами, часть из которых появится только в 10-ке (и то с оговоркой «может быть ...»).

Чем этот ваш Kotlin круче?

Авторы языка признаются, что не пытались придумать что-то кардинально новое. Язык специально задумывался максимально прагматичным и удобным в использовании для разработчиков. Вот небольшой список фишек, которые есть в Kotlin:

C более полным списком можно ознакомиться по ссылке.

И что? Как оно помогает жить?

Null safety — это selling point Kotlin. Проверка на nullable type осуществляется еще во время компиляции.

var a: String = "abc"
a = null // compilation error

var b: String? = "abc"
b = null // ok

Это очень удобно и помогает избежать многих багов.

Extension functions — это фича, которой мне лично очень не хватает в Java. Ниже пример, как с помощью всего пары функций можно улучшить существующий Selenium API.

fun WebDriver.open(url: String) {
    get(url)
}

fun WebDriver.all(cssselector: String): MutableList<WebElement>? {
    return findElements(By.cssSelector(cssselector))
}

fun List<WebElement>.shouldHave(size: Int) {
    assert(this.size == size)
}

По итогу мы можем писать тесты в таком формате:

val driver = ChromeDriver()
driver.open("http://automation-remarks.com")
driver.all(".post").shouldHave(size = 9)

Еще одной фишкой являются функции типа .apply, .with. C их применением можно сделать код более компактным.

ChromeDriver().apply {
        open("http://automation-remarks.com")
        all(".post").shouldHave(size = 9)
}

String template — позволяет удобно форматировать строки. Мы очень часто пользуемся этим в тестах.

fun findCustomerById(id:Long): CustomerEntity{

    val query = """
                SELECT *
                FROM customer
                WHERE id = $id;
                """

    return findOne(CustomerEntity::klass, query)
}

Как видите, SQL запрос не содержит уродливых переносов строк и конкатенаций. Его просто читать, копировать и редактировать.

Reified type — фишка, которая позволяет сделать ваш код очень красивым и лаконичным. Например, мы в тестах часто пользуемся библиотекой Apache DBUtils. С ее применением код получается таким:

val beanHandler = BeanHandler<City>(City::class.java)
val city: City  = QueryRunner().query("SELECT * FROM city", beanHandler)

Но, применив уже знакомые нам extension function и reified type, мы можем сделать так:

inline fun <reified T> QueryRunner.findOne(sql: String): T {
    return BeanHandler(T::class.java).run { query(sql, this) }
}

и получить следующий код:

val city : City = QueryRunner().findOne("SELECT * FROM city")

В этом случае тип, в который конвертируется результат запроса, будет браться из типа объявленной переменной. Это гораздо удобнее, чем Java Generics.

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

Из официальной документации известно, что Kotlin разрабатывался с оглядкой на максимальную совместимость с Java. Java Interop подается под соусом, что мы можем взять любой код, написанный раньше, и вызвать в Kotlin. Либо же обратно — няшный Kotlin-код вызвать в унылой джавке.

Так ли это на самом деле? Давайте разбираться.

Kotlin vs Rest Assured

Для написания тестов для API мы используем одну из лучших библиотек — Rest Assured. Посмотрим, как она будет работать в Kotlin.

Опа-опа, when зарезервированное слово. Обойти такое ограничение можно, обернув его в такие вот интересные кавычки. Скажу честно, я даже не сразу нашел эти символы на своей клавиатуре :-)

Kotlin + Selenide

Для написания UI тестов мы используем Selenide. Давайте посмотрим на совместимость.

И снова неудача — $ нельзя, val тоже нельзя.

Kotlin + Hamcrest (AssertJ)

Все мы при написании тестов активно используем такие библиотеки, как Hamcrest и AssertJ. Что с совместимостью?

Здесь нас тоже ждут ограничения.

Все через костыли

Когда начинаешь натыкаться на такие ограничения, то напрашивается вполне логичная мысль...

Чиним Kotlin и Rest Assured

На самом деле все предыдущие примеры можно в какой-то степени починить. Смотрим на пример с Rest Assured:

fun RequestSpecification.When(): RequestSpecification {
        return this.`when`()
}

@Test
fun basicPingTest() {
   given()
      .When()
      .get("/garage")
      .then().statusCode(200);
}

Делаем extension function, в который оборачиваем вызов when. Работает? Работает. Да, это костыль, но рабочий.

Чиним Kotlin vs Selenide

В случае с Selenide нам нужно просто обернуть вызовы функций $ и $$, a вместо .val() вызывать .setValue().

fun get(selector: String) : SelenideElement {
     return `$`(selector);
 }
    
 fun all(selector: String) : ElementsCollection {
     return `$$`(selector);
 }

Результат:

@Test fun usingDollarsWithBackticks() {
        get(By.name("q")).setValue("selenide")
        all("#ires .g").shouldHave(size(10))
        get("#ires .g").shouldHave(text("Kotlin"));
 }

Чиним Kotlin + Hamcrest (AssertJ)

Увы, по этому пункту нас ждет разочарование. Если Hamcrest еще как-то совместим с Kotlin, то AssertJ починить не получится из-за несовместимости в Generic types. Здесь нам нужно просто взять и заменить библиотеку. Благо, в GitHub уже есть энтузиасты, которые написали порт — assertk.

@Test fun example(){
    assertThat(1).isEqualTo(1)
}

assert {
    throw Exception("error")
}.throwsError {
    it.hasMessage("wrong")
}
// -> expected [message] to be:<["wrong"]> 
                         but was:<["error"]>

Следует отметить, что assertk обладает более удобным API и полностью совместима с Kotlin.

Вроде бы все наши проблемы мы «подлечили», ну или хотя бы подставили костыли. Естественно, вы можете не натолкнуться на проблемы, приведенные выше, если на старте проекта будете выбирать библиотеки и технологии, совместимые с Kotlin.

Чем же все-таки хАрош Kotlin?

В дополнение к языковым фичам и синтаксическим конструкциям, могу отметить, что язык очень лаконичный и позволяет строить удобные DSL. В подтверждение покажу пример теста, написанного с применением библиотеки Kirk, которая призвана заменить Selenide для Kotlin.

Пример четко демонстрирует, какого формата DSL можно писать. По сути — это BDD, только в коде, со всеми плюшками в виде строгой типизации, автодополнениями и поддержкой рефакторинга.

Еще одним примером является Gradle Kotlin-DSL. Уже сейчас gradle.build файл можно писать более приятным способом, получая автодополнения и статическую компиляцию. Эта фича пока что не достигла стадии релиза, но я больше чем уверен: когда будет 1.0, Groovy DSL можно будет помахать ручкой и полностью перейти на Kotlin.

Что имеем в итоге?

Kotlin — очень приятный язык. Все, что уже реализовано у конкурентов Java, в нем есть. Конвертировать существующий код на Java в Kotlin немного проблематично. Нет еще пока полной совместимости со всеми самыми популярными Java-фреймворками и библиотеками. Лично я получаю удовольствие от работы с языком. В заключение я не буду давать явных советов — писать или не писать, учить Kotlin или хейтить и идти учить JavaScript. Я просто оставлю вам ссылочку на свежий репорт от Rebel Labs о состоянии Java-экосистемы, в котором Kotlin назван самым любимым языком c коэффициентом удовлетворенности 9.1 из 10.

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

LinkedIn

Лучшие комментарии пропустить

Я вот в принципе не понимаю зачем тратятся усилия на «чуть-другой» способ написания простейших систем. Реально на андроид проектах любая функциональность пишется за 5 минут на джаве. Зачем вам новые языки чтоб писать тонкий нативный клиент? 99% процентов всех апп тянет данные с сервака и показывает на гуе, все! Сложность космос, да? Новые технологии надо там где можно что-то значительно улучшить — робототехника, АИ, медицина, какие-то научные моделирования и т д. А вот токо сюрприз, им не надо эти новые языки ибо критический вопрос там не на «чем» делать а «как» это сделать в принципе!
Другими словами — польза от котлина такая же как от этого поста.

85 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Спасибо за статью, супер интересно разобраться как Kotlin адаптируется в Android Dev Community.

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

Фидбек супер важен, поэтому если возникают какие-то пожелания или проблемы с использованием Android Studio или Tools, связанные с Котлин в частности или с другими вопросами, можно зарепортить здесь: issuetracker.google.com/...​nt=192708&template=840533

Уже полгода как используем Kotlin в продакшене и ни разу не было, чтобы мы об этом пожалели. Подобные мелкие проблемы конечно же время от времени проскакивают, но они полностью окупают себя в итоге, в виде лаконичного и удобочитаемого кода, той же null-safety и immutability на уровне языка и кучи других приятных вещей.

Отличная статья, спасибо

AssertJ починить не получится из-за несовместимости в Generic types

К примеру, версия 3.4.1 не работает, но вот прям сейчас пишу тесты на Kotlin, где в зависимостях прописано: testCompile 'org.assertj:assertj-core:3.8.0'
И никаких проблем нет (кусок с кодом как пример — bit.ly/2wufWiX).

Как андроид разработчик могу сказать, что Котлин удобнее джавы, когда хочется писать чистый и лаконичный код. Ей не хватает именно тех высокоуровневых конструкций, которые просто дают больше удовольствия от работы и есть в Котлине, а также null-safe из коробки. К сожалению основной язык развивается не так быстро как хотелось бы, хотя саму джаву я тоже люблю.

Пример с apply очень напоминает JS + Python от первого контексты, а от второго with. Мультистрочность явно из Python. Сам язык немного напоминает нечто собранное по кусочкам из разных языков, а поскольку выполняется на JVM то еще костыликов навставляли дабы как-то сгладить ограничения налагаемые средой выполнения.

Так разработчики и не скрывают, что взяли со всех языков лучшее

Я вот в принципе не понимаю зачем тратятся усилия на «чуть-другой» способ написания простейших систем. Реально на андроид проектах любая функциональность пишется за 5 минут на джаве. Зачем вам новые языки чтоб писать тонкий нативный клиент? 99% процентов всех апп тянет данные с сервака и показывает на гуе, все! Сложность космос, да? Новые технологии надо там где можно что-то значительно улучшить — робототехника, АИ, медицина, какие-то научные моделирования и т д. А вот токо сюрприз, им не надо эти новые языки ибо критический вопрос там не на «чем» делать а «как» это сделать в принципе!
Другими словами — польза от котлина такая же как от этого поста.

Реально на андроид проектах любая функциональность пишется за 5 минут на джаве

Это в идеале. А в жизни бывает так что попадаешь на древний легаси проект на котором эту фичу команда месяц пишет

Как я понимаю это не из-за джави а тому что команда такая либо PO такой флов задизайнил что уже сам не понимает как оно должно работать.

А для легаси Котлин мало чем поможет, надо переписывать этот легаси, а уж тем более в мире андроид)

надо, но если он до тебя писался годами, а время на переписывание никто не даст

Я пока понял, что для всяких DTO-шек зело удобен)

Наверное у вас в компании менеджмент просто счастлив таким естимейтам. Любая фича — за 5 минут! Ну или не очень, когда 5 минут уже прошли. А юнит тесты тогда вообще бесполезная трата времени, ведь функционал элементарный

А как вы угадали про юнит тести?

Реально на андроид проектах любая функциональность пишется за 5 минут на джаве.

Ну, это явное преувеличение. :) Апки разные бывают. Другое дело, что я не могу припомнить случая, когда проектые сложности, с которыми доводилось сталкиваться, магически решились бы сменой языка. Что Java, что Kotlin, всё равно останется вагон факторов, влияние которых на успех проекта несоизмеримо выше.

Ну я бы сказал не «чуть-другой» способ написания, а «чуть-меньше» писанины, а скорее сильно меньше писанины благодаря Kotlin. К примеру большой прорыв для jvm это корутины от котлин, с помощью которых можно писать более удобно в фрп, чем с async и await.
Конечно, ни кто не отменяет того, что Kotlin из разработчика сделает лучшего разработчика, но по крайней мере даст фан фактор для нового самообрзования — а это уже очень хорошо

К примеру большой прорыв для jvm это корутины от котлин, с помощью которых можно писать более удобно в фрп, чем с async и await.

Вы functional reactive programming с functional and reactive programming не путаете?

3 роки назад про студію щось схоже казали, навіщо лагуча студія якщо є екліпс, зараз я кажу навіщо мені тратити більше часу на джаву, якщо я це швидше напишу на коліні.

Я предположу, что вы пишете не только без Котлина, но и без юнит-тестов, Dagger, RxJava и Leak Canary. В БД вы лазите через ручной SQLiteDatabaseHelper, URL connection создаёте с нуля, для логирования у вас исключительно Log.d(), а слово Guava считаете ругательным.

Осторожно! Вентилятор поломаете стоко набрасывать то сходу!

Это разве много? Несколько базовых инструментов для тех, кому не повезло с фичами на 5 минут работы.

так а если инструменты убрать то может за 5 минут получится? :)

На проектах уровня визиток, где дописать строку в build.gradle и отрефрешить — это серьёзный в рамках проекта эффорт? Да, получится. На чём-то хоть немного серьёзном? Даже не смешно.

Мнение, больше говорящее о своем носителе, чем о сложности проектов на Android.

99% процентов всех апп

99.999% всех апп абсолютно неконкурентоспособный мусор. Когда говорят о реальной сложности, понятно, что имеют в виду оставшийся 0.001%.

PS. Попробуй сделать хороший mail—клиент. Как бы да, данные с сервера, показать в гуях, но с суммарной сложности ты внезапно потеряешь дар речи.

А в чому суперскладність мейл-клієнта? Можна подробиці?

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

Можно оценить сложность github.com/k9mail/k-9

На Scala мы проектов писать не пробовали из-за излишней сложности

Scala не сложнее PHP, пока вы не используете её в контексте дисциплины функционального программирования. А вот после того, как начинаете писать в соответствии с FP-парадигмами, то и синтаксис Kotlin не спасёт вас от сложностей, через которые разработчик вынужден будет пройти из-за дополнительных слоёв абстракций.

С такими аргументами б до сих пор бы писали бы UI на C++ и MFC.
Любые улучшения позволяют делать проект быстрее и проще.

Чего только не придумают, что бы просто на Scala не перейти.

можно на котлине писать, пока скала компилится

Та котлин тоже долго компилится))

У kotlin есть свои проблемы, например, отсутсвие нормальных строковых литералов как в swift’e, с другой стороны это все равно на порядок лаконичнее и удобнее чем java. Рекомендую попробовать, по началу будет непривычно, но, со временем, java покажется громоздкой.

А какие это «нормальные» строковые литералы?

Опечатался и получился каламбур, имел ввиду container literal initializers
т.е. таки штук как [[1, "some"]:"etc", [2, "moar"]:"etc2″] — Map, String>
с одной стороны довольно сильно подгружают парсер во время компиляции, с другой стороны смотрится лаконично и очень удобно

А еще ужасно выедает глаза эта конструкция в котлине как hasMapOf("key" to "value) когда во всех остальных языках просто ["key":"value"]

это было в голосовании на фичи не так давно, но народ особо не оценил

Не согласен, что это хорошо смотрится..

[[1, "some"]:"etc", [2, "moar"]:"etc2″]

Почему бы не сделать легковесный массив или удобную коллекцию соответствующего объекта. А то не однозначно ясно, какую проблему решает такая конструкция.
А может пример не удачный?

Да, пример совсем с потолка

В коліні 1.2 будуть вже бета вийшла

не будет. только в аннотациях короткая запись массива

В свифте нет хвостовой рекурсии. Что умножает литералы на нуль.

Спасибо за статью. Можно вопрос на засыпку: есть вакансии на этом вашем Котлине? Если нет, ценность его примерно равна ценности лиспа(крутой язык с возможностями 70-х годов, которые только — только появляются в новых языках. При этом работы нет от слова совсем)

jobs.dou.ua/...​es/?search=kotlin&descr=1
jobs.dou.ua/...​ies/?search=scala&descr=1
Что собственно неплохо для языка, который релизнулся полтора года назад. А если посмотреть objective-c и swift, то вакансий на последний уже почти в 2 раза больше

В андроид тащат его щас без угрызения совести. На бекенде можно без проблем его затащить даже в легаси проект на 6й джаве. Прелесть в том, что интероп работает в обе стороны и можно в проекте миксовать языки и новую функциональность писать на нем

То есть, в основном это язык для андроида.

Пока так, но обещают поддержку мультиплатформенности
kotlinlang.org/...​erence/multiplatform.html

Так обычно в java проекты его пихают

Вакансии есть и будет только больше. Гугл то сказал чтоб использовали котлин для андроид. Не андроиду одному котлин приносит профит

Котлін відносно нещодавно зарелізився і більшість просто спостерігають за ним з далека з позицією «якщо він і далі буде популярний то можливо ми його спробуємо», тому в вакансіях він ще не скоро буде як required skill

Забавно, что чувак, который позиционирует себя, как спеца по dsl, говорит о нулевой ценности лиспа и отсутствии вакансий. И зачем уточнять, что такое лисп? Тут что, хоть кто-то не знает, что такое лисп?

А работа на лиспе есть. На нем вакансий нет. Да и то, на clojure, clojurescript таки есть, а это ж диалект лиспа.

www.upwork.com/...​&sort=renew_time_int+desc
8 вакансий, где упоминается лисп! Восемь, Карл! Из них семь — дикий треш. Ты по прежнему считаешь, что учить лисп ради работы — хорошая идея?
www.upwork.com/...​&sort=renew_time_int+desc
На кложуре 19-ть. Тоже считаешь нужно знать?

Скала, руби, питон — вот за них платят

А, ну да, я все время забываю, что разговариваю со индусом-фрилансером, который мнит, что из себя что-то представляет при рейте в 30 баксов в час на месячный проект раз в полгода. Ты бы хоть не позорился, показывая мне ссылки на апворк, Вовик. Я ж с тобой веду буеседу, как со взрослым.

И блин, при твоем уровне размышлений, я уже реально хочу увмдеть длсы, которые ты создал. Я-то думал, ты их на лиспе создаешь, даж слегка пропитался уважением, как к профи, хоть и презираю тебя, как личеость, а тут от эвонокак, Михалыч.

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

Мне на твоё уважение, равно на презрение как то .... Не нравлюсь как личность — приходи, набей мне морду. Адрес дать? Секция спортивная, никто тебя судить не станет

Мне на твоё уважение, равно на презрение как то .... Не нравлюсь как личность — приходи, набей мне морду. Адрес дать? Секция спортивная, никто тебя судить не станет

Это все, что ты можешь сказать по техническим претензиям к тебе? Ну ок.

Зассал?:)

Канеш.

Техническим претензиям к чему? К фразам о невостребованности лиспа?

И блин, при твоем уровне размышлений, я уже реально хочу увмдеть длсы, которые ты создал. Я-то думал, ты их на лиспе создаешь
Ты бы хоть не позорился, показывая мне ссылки на апворк, Вовик. Я ж с тобой веду буеседу, как со взрослым.

Поясняю ещё раз: болт мне ложить на твоё мнение относительно моей персоны. natribu.org

Поясняю ещё раз: болт мне ложить на твоё мнение относительно моей персоны. natribu.org

Вовик, ты так кладешь болт, что не можешь мне не ответить? Сорян, но твоя любовь ко мне останется без ответа.

Хорошая статья. Жаль, коммерческих предложений для Kotlin в Украине пока что негусто. Подозреваю, они есть, но мне не встречались.

Вакансии появятся. Учите Котлин.

Полагаю, там особо долго учить не придется, это ж просто инструмент. Судя по статье, он еще и интуитивно удобнее той же Джавы. Вопрос скорее в том, ЧТО на нем будут писать и сколько за это предложат.

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

Простите, а что там учить дольше, чем два дня?)) Если кандидат толковый, то он с любого языка программирования перейдет на котлин за недельку. А если не толковый, то зачем такие нужны?

Мы уже год ток на нем пишем. Зачем это требование писать в вакансии? Его осилить — неделя от силы.

Можно написать «будет плюсом»

Я честно не понимаю ценности. Это просто еще один язык. А cv-driven development лично мне не нужен.

Может кто-то будет искать именно котлин

Может кто-то будет искать именно котлин

Я хз, я бы скорее уже искал дроидера, знающего хаскель. Просто для того, чтобы в Котлине писать более эффективно с type inference и без отвратительных синтаксических конструктов, которые захламляют восприятие.

Эй, я люблю хаскель и дроид :D

Эй, я люблю хаскель и дроид :D

Таки я и не сомневаюсь. Вспоминайте, что я грил сударыня. Наши двери таки открыты, главное, с лидами собес пройти.

Не думаю, что у этого очередного заменителя есть перспективы.

действительно. Spring 5 идет с дополнительной поддержкой из коробки docs.spring.io/...​ork-reference/kotlin.html
Gradle официально поддерживает и вот такие твиты показывают что с груви не все так радужно twitter.com/...​status/913334345322156032
то что на андроиде он официально идет тоже наверное гугл не понимает ничего в перспективах и прагматичности
kotlin javascript и kotlin native мертворожденные проекты ведь
да и кому нужны эти корутины из коробки?

то что на андроиде он официально идет тоже наверное гугл не понимает ничего в перспективах и прагматичности
kotlin javascript и kotlin native мертворожденные проекты ведь
да и кому нужны эти корутины из коробки?

Это вовсе не значит, что котлин настолько крутой:
У гугла было довольно громкое судебное разбирательство с Ораклом по поводу джавы в андроиде. Не сомневаюсь, что это сыграло на руку Котлин — они в нужное время успешно себя продали гуглу. Котлин использует кучу синтаксического сахара без которого, как мы видим, уже никто не может спокойно кодить, тем более, что это действительно ускорит разработку на андроиде, (просадит перфоманс и наплодит кучу своих новых багов?) и в будущем поможет избежать многомиллиардных судов с Oраклом — похоже это вин-вин.

действительно. Spring 5 идет с дополнительной поддержкой из коробки docs.spring.io/...​ork-reference/kotlin.html
Gradle официально поддерживает и вот такие твиты показывают что с груви не все так радужно twitter.com/...​status/913334345322156032

ИМХО: Не хотел бы я работать в команде, которая решила перейти с джавы/скалы — на котлин. Независимо от того что выходит в 5 спринге.

Ну гуглу понравился язык, котлин отныне всего лишь превоклассный язык для разработки андроид приложений
techcrunch.com/...​for-writing-android-apps

Да нафиг этот котлин бажный, если есть Lombok

какие у Вас были баги?

Ну автокомплит медленно работает
Иногда компиляция выполняется с внезапными эксепшонами, типа не найден класс Any

истину глаголишь, отрок!

Круто! Все четко по полочкам разложил!!!

Когда я вырасту я хочу быть таким как ты. Спасибо за статью и доклады!

Вы одногодки :)

Сережа — молодец :)

Подписаться на комментарии