Такими статьями вы только отпугиваете желание других людей смотреть в сторону Kotlin. Мне нравится этот язык, и я считаю его прекрасным инструментом для решения повседневных задач, но то что вы привели это не аргументы. Тот же lombok убирает весь ненужный код, и получается что с ним и Kotlin не нужен?
Дело в том что в Kotlin куда больше прекрасных возможностей для написания красивого и выразительного кода, а читая такие посты у читателей будет создаваться именно негативное впечатление.
А тут получается что котлин и для бэка не очень, т.к. есть другие альтернативы и получше
С чего вы взяли что он для backend «не очень»? Про другие альтернативы, которые, как вы утверждаете, получше, можно долго спорить. Все сильно субъективно. Могу лишь посоветовать вам попробовать самому написать что-нибудь на Kotlin и решить для себя, плох он или хорош.
После выхода релизной версии Kotlin, переходы на все последующие версии были без изменений, кроме 1.1.2. Но там, насколько я помню, после обновления компилятор стал ругаться на код, в котором был раньше баг, и на который компилятор раньше не ругался.
встречали ли вы какие-либо баги\проблемы\странное поведение компилятора kotlin
На Kotlin я пишу еще начиная с Beta и проблем было много :)
Но в основном это были детские болячки и краши плагина студии. Сейчас все намного стабильнее и багов давно не встречал. И еще ни разу не было чтобы возникающий баг трудно было обойти.
А из интересных багов, что я встречал, примерно год назад у меня крашился компилятор Kotlin, когда из функции с tailrec фозвращалась nullable лямбда (внутри который был вызов этой же функции) для которой была указана другая лямбда, если первая равна null. Проблему решил в итоге переходом на возвращение результата выражения if.
С какими недостатками этого языка сталкивались вы?
В Kotlin нет ключевого слово static, вместо него нужно добавлять аннотацию @JvmStatic для методов в object и companion object. С ключевым словом, возможно, было бы лучше.
На kotlinlang есть дискусия по этому поводу.
Еще не хватает pattern matching, похожего на то, что есть в Scala. Но тоже не сильно мешается,
и хоть без него код получается чуть более многословным, но в то же время с ним проще разобраться потом.
В остальном, наверное, не хватает мелких вещей, которые еще могут появиться :)
Например, хотелось бы чтобы можно было оставлять запятую после последнего аргумента, тогда редактирование будет проще и т.п.
К вопросу о производительности, хотел добавить к предыдущему ответу:
Для предыдущего Russian Ai Cup 2016 я делал первое решение на Java, которое в целом выдавало неплохой fps при запуске, на локальной машине. Как только появилась возможность отправлять решение на Kotlin, я конвертнул весь код на него и fps не изменился.
Если интересно, ссылки на код: версия на Java, версия на Kotlin. И если хотите сравнить 1 в 1, то берите крайний коммит Java версии, и один из первых коммитов Kotlin версии.
Спринг какой? Запущенный с embedded Tomcat? Jetty? Или может уже тестировали новую возможность запускать приложение на Netty или Undertow?
А сам Koltin не ухудшает производительность. Конечно за некоторые абстракции приходится немного платить, но если все переписать в стиле Java, то думаю вы с трудом сможете увидеть разницу в производительности.
Посмотрите как выглядит Kotlin в байткоде, там никакой магии нет. Все конструкции достаточно просты и производительность приложение зависит больше от используемых решений и подходов. А так, код на Kotlin может быть и быстрее аналогичного на Java, если, например, даже перейти от Stream API на использование стандартных расширений для коллекций (при условии что коллекции небольшого размера).
Не нужно противопоставлять Kotlin и Java 9, они прекрасно уживаются вместе. Еще в релизах Kotlin 1.1.3-4 было указано на счет поддержки Java 9. Да и сам Андрей Бреслав в своих выступлениях говорил, что как только выйдет новая версия jvm они сделают необходимые доработки для ее поддержки.
А вот на счет Kotlin vs Java можно говорить очень много и это тема куда больше одного поста. Да и все усложняется тем, что для разных людей одна функциональность будет являются преимуществом, а для других — недостатком.
Для меня Kotlin это не только data class, но и опциональные типы, функции первого порядка, DSL, делегаты, удобные функции расширения, встроенная поддержка иммутабельности, корутины, type aliases и многое другое. Но самое важное это то, что в коде потом проще разбираться, его проще рефакторить и, как показала практика, в Kotlin есть приятная особенность. Он помогает выявлять "плохо написанный код".
Java конечно стремится перенять многие хорошие вещи в язык (тот же Project Amber, Project Loom), но процесс идет медленно и если посмотреть на тот же Stream API, насколько "трудно" встраивали в язык и как он теперь выглядит (для сравнения реализация в Kotlin), то можно примерно понять как будет выглядеть Java потом. Да и нужно обновление языку, который появился еще в 1995, но отбросить все то что уже есть для Java было бы кощунством. Поэтому тут Kotlin подходит в самый раз. Получаем современный язык, с отличным тулингом не бросая весь свой накопленный опыт с Java.
Да и синтаксис Kotlin ближе к тому как выглядят многие другие современные языки (Rust, Golang, Scala, Swift). Везде типы необязательны, типы справа. И даже это небольшое изменение значительно улучшает читабельность. Но многие против будут так изменить Java и даже если и добавят JEP 286 то будет выглядеть не на много лучше чем сейчас.
Так то он должен быть такой же по размеру и читабельности :)
Kotlin Dsl только стремится быть таким же с виду как Groovy Dsl. Цель перехода на Kotlin лишь в том чтобы получить статическую типизацию и поддержку студии. Хотя и в Groovy можно тоже самое сделать при желании… но ведь никто не заморачивается и в этом вся проблема.
Можно посмотреть [мнение] Cédric Champeau (http://melix.github.io/blog/2016/05/gradle-kotlin.html) на счет Kotlin и Gradle.
Если смотреть в рамках всего банка, то наверное не очень активно…
Но проектов много, как и команд. Поэтому все относительно :)
А так, в нашей команде он весьма активно используется.
Это не то чтобы прям совсем новое, скорее возвращение к истокам)
Новое лишь заключается в том, что в Kotlin в самом языке реализован лишь «core» механизм корутин, а сама непосредственная реализация вынесена в библиотеки.
inline, crossinline, noinline появились еще до корутин, и никак не связаны с ними. А в подкасте, что вы упомянули, Алексей Шипилёв выражал свою озабоченность в целесообразности давать возможность разработчикам использовать inline, что было вполне неплохо аргументировано Романом Елизаровым и многие опасения были развеяны.
банальное вынесение строки в константу пока еще не работает, к примеру
Да, пока не все возможности Java реализованы для Kotlin, но в тоже время в Kotlin многие вещи наоборот упрощают различные изменения и рефакторинг. Те же именованные параметры, необязательными типы, destructuring и многое другое.
Интересное заключение. Вы не могли бы привести пример этих самых библиотек, для которых которых, как вы говорите, нет аналогов в Java?
Где-то есть статистика?
Spring нервно курит в стороне смотря на такие названия :)
Дело в том что в Kotlin куда больше прекрасных возможностей для написания красивого и выразительного кода, а читая такие посты у читателей будет создаваться именно негативное впечатление.
С чего вы взяли что он для backend «не очень»? Про другие альтернативы, которые, как вы утверждаете, получше, можно долго спорить. Все сильно субъективно. Могу лишь посоветовать вам попробовать самому написать что-нибудь на Kotlin и решить для себя, плох он или хорош.
Добрый день.
На Kotlin я пишу еще начиная с Beta и проблем было много :)
Но в основном это были детские болячки и краши плагина студии. Сейчас все намного стабильнее и багов давно не встречал. И еще ни разу не было чтобы возникающий баг трудно было обойти.
А из интересных багов, что я встречал, примерно год назад у меня крашился компилятор Kotlin, когда из функции с tailrec фозвращалась
nullableлямбда (внутри который был вызов этой же функции) для которой была указана другая лямбда, если первая равнаnull. Проблему решил в итоге переходом на возвращение результата выраженияif.В Kotlin нет ключевого слово
static, вместо него нужно добавлять аннотацию @JvmStatic для методов вobjectиcompanion object. С ключевым словом, возможно, было бы лучше.На kotlinlang есть дискусия по этому поводу.
Еще не хватает pattern matching, похожего на то, что есть в Scala. Но тоже не сильно мешается,
и хоть без него код получается чуть более многословным, но в то же время с ним проще разобраться потом.
В остальном, наверное, не хватает мелких вещей, которые еще могут появиться :)
Например, хотелось бы чтобы можно было оставлять запятую после последнего аргумента, тогда редактирование будет проще и т.п.
К вопросу о производительности, хотел добавить к предыдущему ответу:
Для предыдущего Russian Ai Cup 2016 я делал первое решение на Java, которое в целом выдавало неплохой fps при запуске, на локальной машине. Как только появилась возможность отправлять решение на Kotlin, я конвертнул весь код на него и fps не изменился.
Если интересно, ссылки на код: версия на Java, версия на Kotlin. И если хотите сравнить 1 в 1, то берите крайний коммит Java версии, и один из первых коммитов Kotlin версии.
Спринг какой? Запущенный с embedded Tomcat? Jetty? Или может уже тестировали новую возможность запускать приложение на Netty или Undertow?
А сам Koltin не ухудшает производительность. Конечно за некоторые абстракции приходится немного платить, но если все переписать в стиле Java, то думаю вы с трудом сможете увидеть разницу в производительности.
Посмотрите как выглядит Kotlin в байткоде, там никакой магии нет. Все конструкции достаточно просты и производительность приложение зависит больше от используемых решений и подходов. А так, код на Kotlin может быть и быстрее аналогичного на Java, если, например, даже перейти от Stream API на использование стандартных расширений для коллекций (при условии что коллекции небольшого размера).
Не нужно противопоставлять Kotlin и Java 9, они прекрасно уживаются вместе. Еще в релизах Kotlin 1.1.3-4 было указано на счет поддержки Java 9. Да и сам Андрей Бреслав в своих выступлениях говорил, что как только выйдет новая версия jvm они сделают необходимые доработки для ее поддержки.
А вот на счет Kotlin vs Java можно говорить очень много и это тема куда больше одного поста. Да и все усложняется тем, что для разных людей одна функциональность будет являются преимуществом, а для других — недостатком.
Для меня Kotlin это не только
data class, но и опциональные типы, функции первого порядка, DSL, делегаты, удобные функции расширения, встроенная поддержка иммутабельности, корутины,type aliasesи многое другое. Но самое важное это то, что в коде потом проще разбираться, его проще рефакторить и, как показала практика, в Kotlin есть приятная особенность. Он помогает выявлять "плохо написанный код".Java конечно стремится перенять многие хорошие вещи в язык (тот же Project Amber, Project Loom), но процесс идет медленно и если посмотреть на тот же Stream API, насколько "трудно" встраивали в язык и как он теперь выглядит (для сравнения реализация в Kotlin), то можно примерно понять как будет выглядеть Java потом. Да и нужно обновление языку, который появился еще в 1995, но отбросить все то что уже есть для Java было бы кощунством. Поэтому тут Kotlin подходит в самый раз. Получаем современный язык, с отличным тулингом не бросая весь свой накопленный опыт с Java.
Да и синтаксис Kotlin ближе к тому как выглядят многие другие современные языки (Rust, Golang, Scala, Swift). Везде типы необязательны, типы справа. И даже это небольшое изменение значительно улучшает читабельность. Но многие против будут так изменить Java и даже если и добавят JEP 286 то будет выглядеть не на много лучше чем сейчас.
Надеюсь ответил на ваш вопрос.
Kotlin Dsl только стремится быть таким же с виду как Groovy Dsl. Цель перехода на Kotlin лишь в том чтобы получить статическую типизацию и поддержку студии. Хотя и в Groovy можно тоже самое сделать при желании… но ведь никто не заморачивается и в этом вся проблема.
Можно посмотреть [мнение] Cédric Champeau (http://melix.github.io/blog/2016/05/gradle-kotlin.html) на счет Kotlin и Gradle.
Но проектов много, как и команд. Поэтому все относительно :)
А так, в нашей команде он весьма активно используется.
Спасибо, выглядит неплохо. Попробую поэкспериментировать с библиотекой.
А не рассматривали вариант расширения функционала mockito-kotlin вместо написания отдельной библиотеки?
Новое лишь заключается в том, что в Kotlin в самом языке реализован лишь «core» механизм корутин, а сама непосредственная реализация вынесена в библиотеки.
inline, crossinline, noinlineпоявились еще до корутин, и никак не связаны с ними. А в подкасте, что вы упомянули, Алексей Шипилёв выражал свою озабоченность в целесообразности давать возможность разработчикам использоватьinline, что было вполне неплохо аргументировано Романом Елизаровым и многие опасения были развеяны.Да, пока не все возможности Java реализованы для Kotlin, но в тоже время в Kotlin многие вещи наоборот упрощают различные изменения и рефакторинг. Те же именованные параметры, необязательными типы, destructuring и многое другое.
Как не самый красивый вариант, можно попробовать вот так:
Можно и без jackson-module-kotlin, только тогда чисто Kotlin специфичные вещи работать не будут, что вполне логично.
Вы серьезно? Основное, чем вы аргументируете свое заключение, это internal. Который и не так часто используется.