Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Недавно публиковал статью, использовал там такое решение для Closeable:
Где use это экстеншн из стандартной библиотеки котлина. Для AutoCloseable пока приходится руками, да. А решение вроде ResourceHolder я использовал в другом проекте, для автоматического возвращения значений в пул — в этом смысле котлин дает большие возможности для собственных решений.
infix fun Closeable.and(other:Closeable):Closeable = Closeable {
this@and.close()
other.close()
}
fun incode() {
val firstResource = create()
val secondResource = create()
(firstResource and secondResource).use {
// do something
}
}
Где use это экстеншн из стандартной библиотеки котлина. Для AutoCloseable пока приходится руками, да. А решение вроде ResourceHolder я использовал в другом проекте, для автоматического возвращения значений в пул — в этом смысле котлин дает большие возможности для собственных решений.
Да и конвертр в json бут сконфигурировал мне сам, чем в этом смысле котлиновские классы хуже джавовских?
Да и конвертр в json бут сконфигурировал мне сам, чем в этом смысле котлиновские классы хуже джавовских?
Они не хуже, просто из коробки spring boot c data и nullable типами хуже работает, поэтому приходится делать подмену маппера
Можете рассказать немного подробнее?
Похоже был не прав был со spring boot. Из коробки все нормально работает и с data class, и с обычными классами, да и с nullable типами. Сейчас проверил на практике.
Но в любом случае неплохо иметь возможность кастомной настройки маппера:
Но в любом случае неплохо иметь возможность кастомной настройки маппера:
val jacksonMapper = ObjectMapper().registerKotlinModule()
.setSerializationInclusion(JsonInclude.Include.NON_ABSENT)
.enable(DeserializationFeature.FAIL_ON_NULL_FOR_PRIMITIVES)
fun main(args: Array<String>) {
println("Hello World!")
}
заменяем «fun» на «def» и "< >" на "[ ]"
def main(args: Array[String]) {
println("Hello World!")
}
и о чудо, Scala ты ли это!? )
По мне так Kotlin это что-то между Java и Scala — т.е. и не такое многословный как Java, но и не такой «навороченный» как Scala. Имхо, но лучше бы JetBrains контрибьютили в Scala, чем пилили очередной язык под JVM…
По мне так Kotlin это что-то между Java и Scala
Согласен, первое впечатление такое, но все же не совсем так, я бы сказал что более точно ему подходит «продуманная scala».
Те же nullable типы, на практике удобнее чем Option, и к тому же сохраняется полная совместимость с Java.
Или smart cast. От java ведь все равно никуда не деться, и когда что-нибудь вызываешь из нее, на выходе приходится проверять на null (ну или оборачивать в Option в scala). А kotlin позволяет всего лишь проверить на null, и дальше в коде уже сохраняется информация о том что эта переменная не может быть null. Не нужно никаких Option, и код становится понятнее.
Вообще советую поиграться с kotlin, он в живую выглядит еще лучше
В чем «продуманность» относительно скалы? Про пример с nullable понятно.
Тут можно много говорить на эту тему. Лучше всего попробовать самим kotlin на практике :)
Но если коротко, что лучше по сравнению со scala:
— взаимодействие с java и обратно. На kotlin вообще можно забыть про то что ты вызываешь что-то из java, все предельно прозрачно и удобно. Тоже самое наоборот. Из java также удобно работать с kotlin. Тут даже не только сходство типов помогает, сколько сама ориентированность kotlin на прозрачную работу с java. Проще всего это продемонстрировать на примерах:
— отсутствие implicit. Сами по себе implicit конечно мощное решение, но без студии разобраться в чужом коде что к чем, почти нереально. Особенно если авторы «сильно увлеклись». А для добавления методов kotlin позволяет писать extension, которые на практике выглядят гораздо удобнее аналогичных решений в scala. Пример:
Scala:
Kotlin:
— есть inline функции. Очень мощный функционал. С его помощью можно, например, убрать оверхед для лямбд (иногда это критично).
— удобные функции стандартной библиотеки
— ну и конечно же скорость компиляции. На практике действительно все очень быстро компилируется, особенно по сравнению со scala.
И опять же еще раз повторюсь, лучше самим пощупать Kotlin.
Но если коротко, что лучше по сравнению со scala:
— взаимодействие с java и обратно. На kotlin вообще можно забыть про то что ты вызываешь что-то из java, все предельно прозрачно и удобно. Тоже самое наоборот. Из java также удобно работать с kotlin. Тут даже не только сходство типов помогает, сколько сама ориентированность kotlin на прозрачную работу с java. Проще всего это продемонстрировать на примерах:
Примеры
1. Использование лямбд вместо анонимных классов (в scala правда тоже скоро это может появиться, но пока такой возможности нет).
Код в java:
В scala же уже не получится такое провернуть. А вот с kotlin проблем нет:
2. Есть тот же try-with-resources (да, можно сделать extension к языку, но из коробки этого нет, а значит придется тянуть решение из одного проекта в другой)
Это по крайней мере что первое приходит в голову
Код в java:
ExecutorService executor = Executors.newFixedThreadPool(1);
executor.execute(System.out::println);
В 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.
И опять же еще раз повторюсь, лучше самим пощупать Kotlin.
Вообще в scala давно уже добавлены implicit class'ы, которые позволяют писать более аккуратный код:
implicit class RichInt(val x: Int) extends AnyVal {
def square: Int = x * x
}
object App {
def print(): Unit = {
val two = 2
println(s"The square of 2 is ${two.square}")
}
}
Тут мой недочет, согласен. Но все же версия в kotlin выглядит лучше.
Но там разница в считанные символы, что никак нельзя назвать каким-то существенным улучшением. К тому же, чаще всего, добавляют сразу несколько функций, и в этом случае вараинт scala уже выглядит лучше, чем в kotlin.
И даже если учитывать несколько функций, вариант из kotlin, имхо, будет выглядеть логичней и лучше.
Скажем так, при множестве функций вариант из scala в итоге станет короче, это то что объективно можно померить. Но по большому счету синтаксис здесь скорее дело вкуса. Однако надо учитывать, что в scala это не просто функция, а класс, в котором могут быть в приватные методы и даже переменные, хотя это уже отдельный случай, т.к. будет производится выделение памяти.
По остальным пунктам, которые вы приводите к качестве плюсов:
— inline функции: в scala для этого есть аннотация
— удобные функции стандартной библиотеки: вполне присутствует в scala
— скорость компиляции: здесь конечно scala медленне почти всех существующих языков, но инкрементальный компилятор, который будет перекомпилировать отдельные функции (или даже блоки кода, не помню точно), в значительной степени уберет эту проблему.
Вообще хотелось развернутого сравнения от того, кто разбирается в обоих языках, потому что сейчас совершенно не понятно, зачем kotlin вообще нужен.
— inline функции: в scala для этого есть аннотация
@inline— удобные функции стандартной библиотеки: вполне присутствует в scala
— скорость компиляции: здесь конечно scala медленне почти всех существующих языков, но инкрементальный компилятор, который будет перекомпилировать отдельные функции (или даже блоки кода, не помню точно), в значительной степени уберет эту проблему.
Вообще хотелось развернутого сравнения от того, кто разбирается в обоих языках, потому что сейчас совершенно не понятно, зачем kotlin вообще нужен.
С inline функциями это я погорячился, но в остальном не согласен.
На счет удобных функций стандартной библиотеки, можете привести аналоги в scala для apply, with, let, run?
По поводу инкрементальной компиляции, вы часто в проекте меняете только одну функцию?
Основными преимуществами kotlin, имхо, является следующее:
— nullable типы
— smart cast
— null safely
— быстрая компиляция
— отсутствие implicit
— лучшее взаимодействие с java
— отличная поддержка от студии
— готовые решения для работы в jvm, android, трансляции в js
— стабильная обратная совместимость
Вообще темой публикации не было сравнение kotlin и scala, и вообще это тема достойна отдельной статьи. И в самом начале публикации указано, что если вы счастливы со scala, но вам не нужен kotlin.
На счет удобных функций стандартной библиотеки, можете привести аналоги в scala для apply, with, let, run?
По поводу инкрементальной компиляции, вы часто в проекте меняете только одну функцию?
Основными преимуществами kotlin, имхо, является следующее:
— nullable типы
— smart cast
— null safely
— быстрая компиляция
— отсутствие implicit
— лучшее взаимодействие с java
— отличная поддержка от студии
— готовые решения для работы в jvm, android, трансляции в js
— стабильная обратная совместимость
Вообще темой публикации не было сравнение kotlin и scala, и вообще это тема достойна отдельной статьи. И в самом начале публикации указано, что если вы счастливы со scala, но вам не нужен kotlin.
Согласен с тем, что сравнение двух языков — это скорее для отдельной статьи. Но мы здесь это обсуждаем потому, что не обсуждать же REST-сервис? Понятно для чего статья была написана. К сожалению полноценно поспорить с вами не могу, т.к. kotlin не знаю и именно по этому считаю статью с честным сравнением и примерами кода наиболее интересным вариантом знакомства с языком. Однако попробую написать по поводу известных вещей.
— По поводу инкрементальной компиляции, вы часто в проекте меняете только одну функцию?
По идее инкрементальная компиляция может работать параллельно с написанием кода, сводя до минимума ожидание. Но даже если она отрабатывает по всем изменениям, то это обычно значительно меньше целого проекта. Т.к. она даже не будет целые файлы перекомпилировать.
На счет работы с null. В scala достаточно удобно использовать Option, особенно в сочетании с for, хотя это не 100% защита от null. Однако не так давно было обсуждение, а не ввести ли в scala аналогичные nullable типы, так что возможно скоро здесь не будет различий.
— отсутствие implicit
Не сказал бы что это прямо плюс. Считаю, что при аккуратном использовании implicit дает больше преимуществ, чем недостатков.
— лучшее взаимодействие с java
Это палка о двух концах. Если в kotlin такая хорошая интероперабильность с java, то значит, что ряд косяков за java перенесся в kotlin. Кроме того, если где-то надо предоставить какое-то очень навороченно api из scala, то можно и несколько оберток написать, как например play делает. Но этот сценарий встречается гораздо реже, чем наоборот. А наоборот почти никаких проблем нет, а с выходом 2.12 будет ещё меньше.
— отличная поддержка от студии
Это не плюс kotlin'а, это — минус jetbrains'у )
— готовые решения для работы в jvm, android, трансляции в js
Для js в scala точно есть решение — scalajs. На счет android не знаю. Возможно здесь действительно есть объектичное преимущество kotlin.
— стабильная обратная совместимость
В scala совместимость на уровне исходных кодов до версии 3. Но сейчас идет активная работа над тем, чтобы компилировать исходники в ast-деревья и распространять пакеты с ними, а не с class-файлами. Тогда не будет зависимости от версии.
— По поводу инкрементальной компиляции, вы часто в проекте меняете только одну функцию?
По идее инкрементальная компиляция может работать параллельно с написанием кода, сводя до минимума ожидание. Но даже если она отрабатывает по всем изменениям, то это обычно значительно меньше целого проекта. Т.к. она даже не будет целые файлы перекомпилировать.
На счет работы с null. В scala достаточно удобно использовать Option, особенно в сочетании с for, хотя это не 100% защита от null. Однако не так давно было обсуждение, а не ввести ли в scala аналогичные nullable типы, так что возможно скоро здесь не будет различий.
— отсутствие implicit
Не сказал бы что это прямо плюс. Считаю, что при аккуратном использовании implicit дает больше преимуществ, чем недостатков.
— лучшее взаимодействие с java
Это палка о двух концах. Если в kotlin такая хорошая интероперабильность с java, то значит, что ряд косяков за java перенесся в kotlin. Кроме того, если где-то надо предоставить какое-то очень навороченно api из scala, то можно и несколько оберток написать, как например play делает. Но этот сценарий встречается гораздо реже, чем наоборот. А наоборот почти никаких проблем нет, а с выходом 2.12 будет ещё меньше.
— отличная поддержка от студии
Это не плюс kotlin'а, это — минус jetbrains'у )
— готовые решения для работы в jvm, android, трансляции в js
Для js в scala точно есть решение — scalajs. На счет android не знаю. Возможно здесь действительно есть объектичное преимущество kotlin.
— стабильная обратная совместимость
В scala совместимость на уровне исходных кодов до версии 3. Но сейчас идет активная работа над тем, чтобы компилировать исходники в ast-деревья и распространять пакеты с ними, а не с class-файлами. Тогда не будет зависимости от версии.
Некоторые моменты есть у них на сайте. Если субъективно, мне котлин нравится тем, что он простой в чтении, написании и изучении, при этом в нем есть всё, что мне хотелось бы иметь в языке. Конечно, котлин более бедный в плане возможностей язык, чем скала, но в этом же и его прелесть — видно, что при создании пытались сохранить простоту при наличии всех необходимых фич. Почти любой Java-программист без труда может писать на котлине, чего не всегда можно сказать о скале. Скала замечательный язык, котлин тоже, просто преследующий немного другие цели, сравнение по колчеству фич здесь очевидно не уместно.
Еще забыл добавить что результирующий jar меньше аналогичного в scala.
Например тут приводятся такие цифры:
-kotlin 2.2мб
-scala 5.5мб
Для android это является критичным фактором
И еще что немаловажно, JetBrains обещают полную обратную совместимость (привет еще раз scala c либами под 2.10, 2.11, 2.12 и т.д.)
Например тут приводятся такие цифры:
-kotlin 2.2мб
-scala 5.5мб
Для android это является критичным фактором
И еще что немаловажно, JetBrains обещают полную обратную совместимость (привет еще раз scala c либами под 2.10, 2.11, 2.12 и т.д.)
Весомые аргументы. Но я все же возлагаю на детище Одерки и его команды наибольшие надежды, чем на Kotlin(хотя Jetbrains конечно большой респект, думаю их труды тоже не пропадут даром). Особенно учитывая последний пост Одерски, в котором он упомянул, что в этом году он приложит усилия на упрощение Scala. Да и про Dotty не стоит забывать.
По поводу упрощения scala я бы особо не переживал. Язык может быть упрощен на концептуальном уровне, без особого ограничения возможностей программиста. Например, Clojure относительно простой язык, но все думаю прекрасно представляют, каких размеров горы данный язык позволяет ворочать.
Я не переживаю, я наоборот воодушевлен тем, что люди пилящие Scala очень тщательно следят за комьюнити/трендами/критикой и стараются вовремя реагировать. У команды Scala есть опыт и понимание того что и как нужно делать, крупные продукты на их стеке и амбициозные планы. А вот что есть у Kotlin команды кроме того, что они знают как делать хорошие инструменты для разработчиков — я не знаю. Вся эта вкусовщина и духе nullable лучше Option или у нас нет implicit'ов и это плюс — чистой воды маркетинг…
Я вот знаю, что выйдет Scala 3.0 — и это будет прогресс и куча улучшений, еще большее комьюнити и увеличение спроса. А выйдет Kotlin 2.0 и будет ли на нем писать кто-то чуть больше чем люди уставшие от геттеров-сеттеров в Java — не ясно.
Я вот знаю, что выйдет Scala 3.0 — и это будет прогресс и куча улучшений, еще большее комьюнити и увеличение спроса. А выйдет Kotlin 2.0 и будет ли на нем писать кто-то чуть больше чем люди уставшие от геттеров-сеттеров в Java — не ясно.
Полная обратная совместимость — весьма тревожный звоночек. У котлина есть все шансы породить свой сохранять язык в чистоте. Только представьте законсервировавшуюся скалу. И ряд неудачных решений, которые в ближайшем времени будут устранены (view bounds, xml...)
В случае, например со scala, (передаю так же привет всем ее библиотекам и их множественным версиям), смена версии не является большой проблемой. У меня были крупные проекты, внутри которых я проводил миграцию 2.9 -> 2.10, 2.10 -> 2.11 и проблем это не совершенно не вызвало.
Запугивания миграцией, я зачастую слышу от людей которые эту самую миграцию не проводили.
java.util.Date и жить с этим наследством на протяжении всего жизненного цикла языка. Обратная совместимость позволяет поддерживать энтропию В случае, например со scala, (передаю так же привет всем ее библиотекам и их множественным версиям), смена версии не является большой проблемой. У меня были крупные проекты, внутри которых я проводил миграцию 2.9 -> 2.10, 2.10 -> 2.11 и проблем это не совершенно не вызвало.
Запугивания миграцией, я зачастую слышу от людей которые эту самую миграцию не проводили.
Совсем вечной она конечно не будет. Разработчики лишь обещают, что обратная совместимость будет сохраняться как можно дольше. Они и сами говорят, что может наступить момент в далеком будущем, когда нужно будет что-то капитально изменить
А если рассмотреть проект, у которого большое количество стороних библиотек на scala? Тут как раз и может получиться ситуация, что одна либа есть под новую версию scala, а других нет.
В самой миграции проблем нет, сложность есть лишь в долгой поддержки проекта, особенно с большим количеством зависимостей.
В случае, например со scala, (передаю так же привет всем ее библиотекам и их множественным версиям), смена версии не является большой проблемой. У меня были крупные проекты, внутри которых я проводил миграцию 2.9 -> 2.10, 2.10 -> 2.11 и проблем это не совершенно не вызвало.
А если рассмотреть проект, у которого большое количество стороних библиотек на scala? Тут как раз и может получиться ситуация, что одна либа есть под новую версию scala, а других нет.
Запугивания миграцией, я зачастую слышу от людей которые эту самую миграцию не проводили.
В самой миграции проблем нет, сложность есть лишь в долгой поддержки проекта, особенно с большим количеством зависимостей.
def main(args: Array[String]) {
println("Hello World!")
}
заменяем ещё несколько символов
(defun main (args)
(print "Hello World!")
)
и о чудо, lisp, ты ли это?
null-safety, насколько я знаю, сделан приворачиванием сотен метаданных к имеющимся либам.
Нет, null-safety внутри Котлина реализуется прикручиванием метаданных в скомпиленный jar, а всё что за пределами, решается с помощью flexible types.
дженерики с use-site variance еще в яве более чем отстойны, стоило ли пилить новый язык, чтоб наступить на те же грабли?
Полагаю, иначе нельзя, ведь надо бесшовно интегрироваться с Java, а она пишет метаинфу к class-файлы с прицелом на use-site variance. Кроме того, никто не мешает использовать declaration-site variance в Kotlin :-)
Некоторые траблы явы просто не решаются без введения своей стандартной библиотеки, как с скале или цейлоне.
Может и не решаются, но Jetbrains умудрились неожиданно хорошо решить ряд проблем без введения стандартной библиотеки, например, те же List/MutableList. Формально оно находится в пакете kotlin, но фактически компилится в старый добрый java.util.List и полностью с ним совместими при интеропе.
Отличный язык. Но, боюсь, как бы он не встал на одну полку с Ceylon, GoSu, Fantom, Xtend, etc… На мой взгляд основные просчеты:
— Долго тянут с релизом. Язык был анонсирован несколько лет назад, и вау эффект уже изрядно поутих. Самое время его было выпустить до Java 8. Сейчас внимание программеров переключилось на джавовские лямбды и стримы, и мощь котлина в их глазах уже поугасла.
— Недостаточная огласка в СМИ. Взять хотя бы Одерски, который пиарит свою скалу везде, где только возможно. Несколько статей на хабре не решат проблемы.
— Нет своего стека технологий. Красивый язык оценят, но без сопутствующих технологий им пользоваться не будут. Вот Groovy некрасивый язык, а им пользуются (про Scala толерантно помалкиваю). Нужен стек типа typesafe (или, упаси господи, JEE) и фреймворки типа play. Кроме того, на первое время нужно определиться с нишей решаемых задач, напр. scala — параллельное программирование, kotlin — андроид, клиентские веб приложения (прощай, GWT), микросервисы. На одной экосистеме Java далеко не уедешь.
— Success stories. Типа «Twitter признал свою ошибку со scala и переписал свой стек на kotlin-е» :)
P.S. Персональное ощущение: пробовал Kotlin несколько раз. Писал несколько проектов. В итоге, за пару часов все переписывал на java и избавлялся от котлина в проекте, ибо отличия в структуре несущественны. Да, код короче, элегантнее, но IDE позволяет быстро писать и на Java.
— Долго тянут с релизом. Язык был анонсирован несколько лет назад, и вау эффект уже изрядно поутих. Самое время его было выпустить до Java 8. Сейчас внимание программеров переключилось на джавовские лямбды и стримы, и мощь котлина в их глазах уже поугасла.
— Недостаточная огласка в СМИ. Взять хотя бы Одерски, который пиарит свою скалу везде, где только возможно. Несколько статей на хабре не решат проблемы.
— Нет своего стека технологий. Красивый язык оценят, но без сопутствующих технологий им пользоваться не будут. Вот Groovy некрасивый язык, а им пользуются (про Scala толерантно помалкиваю). Нужен стек типа typesafe (или, упаси господи, JEE) и фреймворки типа play. Кроме того, на первое время нужно определиться с нишей решаемых задач, напр. scala — параллельное программирование, kotlin — андроид, клиентские веб приложения (прощай, GWT), микросервисы. На одной экосистеме Java далеко не уедешь.
— Success stories. Типа «Twitter признал свою ошибку со scala и переписал свой стек на kotlin-е» :)
P.S. Персональное ощущение: пробовал Kotlin несколько раз. Писал несколько проектов. В итоге, за пару часов все переписывал на java и избавлялся от котлина в проекте, ибо отличия в структуре несущественны. Да, код короче, элегантнее, но IDE позволяет быстро писать и на Java.
— Долго тянут с релизом. Язык был анонсирован несколько лет назад, и вау эффект уже изрядно поутих. Самое время его было выпустить до 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 выглядит весьма странно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем простой RESTful сервис на kotlin и spring boot