то есть DI вы тоже предпочитаете избегать, потому что поведение кода начинает зависеть от xml файла конфигурации.
В статье приведено мнение автора, но да, мне тоже не нравится implicit. Но никто про DI не говорит что его нужно избегать (правда без xml конфигурации).
Вы видимо забыли перенести кусок кода из черновика, никаких проблем монад не описано — только использование.
Тут вопрос к автору
Ну и самое интересное вы не рассказали — как вам понравились в сравнении скаловский и котлиновский pattern matching
автор как раз и говорит что ему не хватает pattern matching в kotlin
По своему опыту могу сказать что критичных багов мы тоже не нашли. Есть некоторые вещи, которых сильно не хватает, например typedef. Но в версии 1.1. они появятся.
Судя по Источник, Google еще официально ничего не объявило, а лишь рассматривает Swift в качестве альтернативного языка для разработки под Android, впрочем как и Kotlin.
А есть ли возможность добавить подсветку в студии для типов с <!>, которые получаются при взаимодействии с java? Сейчас очень велика вероятность пропустить такой тип (под пропустить имеется ввиду забыть его проверить на null) из-за прозрачной конвертации в not null типы в kotlin.
Жалко кармы не хватает плюсануть… полностью согласен с автором!
п.с. вообще возникает ощущение что "последователи scala" не спят, и только и делают что ищут отрицательные комментарии в сторону своего детища, чтобы потом их безжалостно топить…
Final by default действительно очень спорный вопрос. Как по мне, было бы гораздо лучше если бы везде было open by default. По этому поводу на форуме kotlin, как раз идет большой холивар.
Рассуждение авторов языка на тему выбора defaults: статья
Совсем вечной она конечно не будет. Разработчики лишь обещают, что обратная совместимость будет сохраняться как можно дольше. Они и сами говорят, что может наступить момент в далеком будущем, когда нужно будет что-то капитально изменить
В случае, например со scala, (передаю так же привет всем ее библиотекам и их множественным версиям), смена версии не является большой проблемой. У меня были крупные проекты, внутри которых я проводил миграцию 2.9 -> 2.10, 2.10 -> 2.11 и проблем это не совершенно не вызвало.
А если рассмотреть проект, у которого большое количество стороних библиотек на scala? Тут как раз и может получиться ситуация, что одна либа есть под новую версию scala, а других нет.
Запугивания миграцией, я зачастую слышу от людей которые эту самую миграцию не проводили.
В самой миграции проблем нет, сложность есть лишь в долгой поддержки проекта, особенно с большим количеством зависимостей.
— Долго тянут с релизом. Язык был анонсирован несколько лет назад, и вау эффект уже изрядно поутих. Самое время его было выпустить до Java 8. Сейчас внимание программеров переключилось на джавовские лямбды и стримы, и мощь котлина в их глазах уже поугасла.
Не соглашусь с вами. Даже сейчас, после выхода java 8, kotlin выглядит намного лучше. Посмотрите тоже сравнение лямбд в java и kotlin. Да и помимо этого в языке собраны многие интересные решения, которые в совокупности позволяют сделать код более читабельным и понятным.
— Недостаточная огласка в СМИ. Взять хотя бы Одерски, который пиарит свою скалу везде, где только возможно. Несколько статей на хабре не решат проблемы.
В android kotlin уже завоевал сердца разработчиков :)
А так релиз еще впереди, да и, как мне кажется, все кто интересуются продуктами JetBrains знакомы с Kotlin.
— Нет своего стека технологий. Красивый язык оценят, но без сопутствующих технологий им пользоваться не будут. Вот Groovy некрасивый язык, а им пользуются (про Scala толерантно помалкиваю). Нужен стек типа typesafe (или, упаси господи, JEE) и фреймворки типа play. Кроме того, на первое время нужно определиться с нишей решаемых задач, напр. scala — параллельное программирование, kotlin — андроид, клиентские веб приложения (прощай, GWT), микросервисы. На одной экосистеме Java далеко не уедешь.
Для java есть просто огромное количество библиотек, и да, на ней можно выехать на первое время. При большом желании можно даже использовать библиотеки из scala.
— Success stories. Типа «Twitter признал свою ошибку со scala и переписал свой стек на kotlin-е» :)
Посмотрите подробнее информацию на их сайте (Who's using Kotlin). Да и сами JetBrains у себя его используют.
На kotlin уже сейчас разрабатываются приложения под android, тот же avito, например.
Не забывайте, что язык еще находится в Beta, пока нельзя гарантировать полную обратную совместимость, стандартная библиотека еще допиливается. Вот после релиза и появятся «Success stories»
Да, код короче, элегантнее, но IDE позволяет быстро писать и на Java.
Если бы вы сказали что писали до этого на scala и kotlin вам не понравился, я бы еще понял. Но по сравнению с java у языка такое огромное количество улучшений, что обратный переход с kotlin на java выглядит весьма странно.
С inline функциями это я погорячился, но в остальном не согласен.
На счет удобных функций стандартной библиотеки, можете привести аналоги в scala для apply, with, let, run?
По поводу инкрементальной компиляции, вы часто в проекте меняете только одну функцию?
Основными преимуществами kotlin, имхо, является следующее:
— nullable типы
— smart cast
— null safely
— быстрая компиляция
— отсутствие implicit
— лучшее взаимодействие с java
— отличная поддержка от студии
— готовые решения для работы в jvm, android, трансляции в js
— стабильная обратная совместимость
Вообще темой публикации не было сравнение kotlin и scala, и вообще это тема достойна отдельной статьи. И в самом начале публикации указано, что если вы счастливы со scala, но вам не нужен kotlin.
Еще забыл добавить что результирующий jar меньше аналогичного в scala.
Например тут приводятся такие цифры:
-kotlin 2.2мб
-scala 5.5мб
Для android это является критичным фактором
И еще что немаловажно, JetBrains обещают полную обратную совместимость (привет еще раз scala c либами под 2.10, 2.11, 2.12 и т.д.)
Тут можно много говорить на эту тему. Лучше всего попробовать самим kotlin на практике :)
Но если коротко, что лучше по сравнению со scala:
— взаимодействие с java и обратно. На kotlin вообще можно забыть про то что ты вызываешь что-то из java, все предельно прозрачно и удобно. Тоже самое наоборот. Из java также удобно работать с kotlin. Тут даже не только сходство типов помогает, сколько сама ориентированность kotlin на прозрачную работу с java. Проще всего это продемонстрировать на примерах:
Примеры
1. Использование лямбд вместо анонимных классов (в scala правда тоже скоро это может появиться, но пока такой возможности нет).
Код в java:
В scala же уже не получится такое провернуть. А вот с kotlin проблем нет:
val executor = Executors.newFixedThreadPool(1)
executor.execute { println() }
2. Есть тот же try-with-resources (да, можно сделать extension к языку, но из коробки этого нет, а значит придется тянуть решение из одного проекта в другой)
Это по крайней мере что первое приходит в голову
— отсутствие implicit. Сами по себе implicit конечно мощное решение, но без студии разобраться в чужом коде что к чем, почти нереально. Особенно если авторы «сильно увлеклись». А для добавления методов kotlin позволяет писать extension, которые на практике выглядят гораздо удобнее аналогичных решений в scala. Пример:
Scala:
object MyExtensions {
implicit def richInt(i: Int) = new {
def square = i * i
}
}
object App {
import MyExtensions._
def print(): Unit = {
val two = 2
println(s"The square of 2 is ${two.square}")
}
}
Kotlin:
fun Int.richInt(): Int = this * this
object App {
fun print(): Unit {
val two = 2
println("The square of 2 is ${two.richInt()}")
}
}
— есть inline функции. Очень мощный функционал. С его помощью можно, например, убрать оверхед для лямбд (иногда это критично).
Согласен, первое впечатление такое, но все же не совсем так, я бы сказал что более точно ему подходит «продуманная scala».
Те же nullable типы, на практике удобнее чем Option, и к тому же сохраняется полная совместимость с Java.
Или smart cast. От java ведь все равно никуда не деться, и когда что-нибудь вызываешь из нее, на выходе приходится проверять на null (ну или оборачивать в Option в scala). А kotlin позволяет всего лишь проверить на null, и дальше в коде уже сохраняется информация о том что эта переменная не может быть null. Не нужно никаких Option, и код становится понятнее.
Вообще советую поиграться с kotlin, он в живую выглядит еще лучше
Похоже был не прав был со spring boot. Из коробки все нормально работает и с data class, и с обычными классами, да и с nullable типами. Сейчас проверил на практике.
Но в любом случае неплохо иметь возможность кастомной настройки маппера:
val jacksonMapper = ObjectMapper().registerKotlinModule()
.setSerializationInclusion(JsonInclude.Include.NON_ABSENT)
.enable(DeserializationFeature.FAIL_ON_NULL_FOR_PRIMITIVES)
В статье приведено мнение автора, но да, мне тоже не нравится implicit. Но никто про DI не говорит что его нужно избегать (правда без xml конфигурации).
Тут вопрос к автору
автор как раз и говорит что ему не хватает pattern matching в kotlin
п.с. вообще возникает ощущение что "последователи scala" не спят, и только и делают что ищут отрицательные комментарии в сторону своего детища, чтобы потом их безжалостно топить…
Рассуждение авторов языка на тему выбора defaults: статья
А если рассмотреть проект, у которого большое количество стороних библиотек на scala? Тут как раз и может получиться ситуация, что одна либа есть под новую версию scala, а других нет.
В самой миграции проблем нет, сложность есть лишь в долгой поддержки проекта, особенно с большим количеством зависимостей.
Не соглашусь с вами. Даже сейчас, после выхода java 8, kotlin выглядит намного лучше. Посмотрите тоже сравнение лямбд в java и kotlin. Да и помимо этого в языке собраны многие интересные решения, которые в совокупности позволяют сделать код более читабельным и понятным.
В android kotlin уже завоевал сердца разработчиков :)
А так релиз еще впереди, да и, как мне кажется, все кто интересуются продуктами JetBrains знакомы с Kotlin.
Для java есть просто огромное количество библиотек, и да, на ней можно выехать на первое время. При большом желании можно даже использовать библиотеки из scala.
Посмотрите подробнее информацию на их сайте (Who's using Kotlin). Да и сами JetBrains у себя его используют.
На kotlin уже сейчас разрабатываются приложения под android, тот же avito, например.
Не забывайте, что язык еще находится в Beta, пока нельзя гарантировать полную обратную совместимость, стандартная библиотека еще допиливается. Вот после релиза и появятся «Success stories»
Если бы вы сказали что писали до этого на scala и kotlin вам не понравился, я бы еще понял. Но по сравнению с java у языка такое огромное количество улучшений, что обратный переход с kotlin на java выглядит весьма странно.
На счет удобных функций стандартной библиотеки, можете привести аналоги в scala для apply, with, let, run?
По поводу инкрементальной компиляции, вы часто в проекте меняете только одну функцию?
Основными преимуществами kotlin, имхо, является следующее:
— nullable типы
— smart cast
— null safely
— быстрая компиляция
— отсутствие implicit
— лучшее взаимодействие с java
— отличная поддержка от студии
— готовые решения для работы в jvm, android, трансляции в js
— стабильная обратная совместимость
Вообще темой публикации не было сравнение kotlin и scala, и вообще это тема достойна отдельной статьи. И в самом начале публикации указано, что если вы счастливы со scala, но вам не нужен kotlin.
Например тут приводятся такие цифры:
-kotlin 2.2мб
-scala 5.5мб
Для android это является критичным фактором
И еще что немаловажно, JetBrains обещают полную обратную совместимость (привет еще раз scala c либами под 2.10, 2.11, 2.12 и т.д.)
Но если коротко, что лучше по сравнению со scala:
— взаимодействие с java и обратно. На kotlin вообще можно забыть про то что ты вызываешь что-то из java, все предельно прозрачно и удобно. Тоже самое наоборот. Из java также удобно работать с kotlin. Тут даже не только сходство типов помогает, сколько сама ориентированность kotlin на прозрачную работу с java. Проще всего это продемонстрировать на примерах:
Код в java:
В scala же уже не получится такое провернуть. А вот с kotlin проблем нет:
2. Есть тот же try-with-resources (да, можно сделать extension к языку, но из коробки этого нет, а значит придется тянуть решение из одного проекта в другой)
Это по крайней мере что первое приходит в голову
— отсутствие implicit. Сами по себе implicit конечно мощное решение, но без студии разобраться в чужом коде что к чем, почти нереально. Особенно если авторы «сильно увлеклись». А для добавления методов kotlin позволяет писать extension, которые на практике выглядят гораздо удобнее аналогичных решений в scala. Пример:
Scala:
Kotlin:
— есть inline функции. Очень мощный функционал. С его помощью можно, например, убрать оверхед для лямбд (иногда это критично).
— удобные функции стандартной библиотеки
— ну и конечно же скорость компиляции. На практике действительно все очень быстро компилируется, особенно по сравнению со scala.
И опять же еще раз повторюсь, лучше самим пощупать Kotlin.
Согласен, первое впечатление такое, но все же не совсем так, я бы сказал что более точно ему подходит «продуманная scala».
Те же nullable типы, на практике удобнее чем Option, и к тому же сохраняется полная совместимость с Java.
Или smart cast. От java ведь все равно никуда не деться, и когда что-нибудь вызываешь из нее, на выходе приходится проверять на null (ну или оборачивать в Option в scala). А kotlin позволяет всего лишь проверить на null, и дальше в коде уже сохраняется информация о том что эта переменная не может быть null. Не нужно никаких Option, и код становится понятнее.
Вообще советую поиграться с kotlin, он в живую выглядит еще лучше
Но в любом случае неплохо иметь возможность кастомной настройки маппера: