company_banner

Почему следует полностью переходить на Kotlin

https://medium.com/@magnus.chatt/why-you-should-totally-switch-to-kotlin-c7bbde9e10d5
  • Перевод


Хочу рассказать вам о новом языке программирования, который называется Kotlin, и объяснить, почему вам стоит использовать его в своём следующем проекте. Раньше я предпочитал Java, но в последний год пишу на Kotlin везде, где только можно. И в данный момент я не представляю себе ситуации, в которой лучше было бы выбрать Java.


Kotlin разработан в JetBrains, и участие тех же людей в создании наборов IDE, таких как IntelliJ и ReSharper, хорошо заметно по самому языку. Он прагматичен и краток, благодаря чему написание кода превращается в приятный и эффективный процесс.


Хотя Kotlin компилируется в JavaScript и скоро будет компилироваться в машинный код, я сконцентрируюсь на его первичной среде — JVM.


Итак, несколько причин, почему вам следует полностью переходить на Kotlin (порядок случаен):


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


Kotlin на 100 % совместим с Java. Вы можете в буквальном смысле продолжать работать над своим старым Java-проектом, но уже используя Kotlin. Все ваши любимые Java-фреймворки также будут доступны, и, в каком бы фреймворке вы ни писали, Kotlin будет легко принят упрямым любителем Java.


1# Знакомый синтаксис


Kotlin — не какой-то там странный язык, рождённый в академических кругах. Его синтаксис знаком любому программисту, воспитанному на парадигме ООП, и с самого начала может быть более-менее понятным. Конечно, есть некоторые отличия от Java вроде переработанного конструктора или объявлений переменных val var. В этом коде отражена большая часть базового синтаксиса:


class Foo {

    val b: String = "b"     // val means unmodifiable
    var i: Int = 0          // var means modifiable

    fun hello() {
        val str = "Hello"
        print("$str World")
    }

    fun sum(x: Int, y: Int): Int {
        return x + y
    }

    fun maxOf(a: Float, b: Float) = if (a > b) a else b

}

2# Интерполяция строк


Это как бы более умная и читабельная версия String.format() из Java, встроенная в язык:


val x = 4
val y = 7
print("sum of $x and $y is ${x + y}")  // sum of 4 and 7 is 11

3# Выведение типа


Kotlin будет выводить ваши типы, если вы посчитаете, что это улучшит читабельность:


val a = "abc"                         // type inferred to String
val b = 4                             // type inferred to Int

val c: Double = 0.7                   // type declared explicitly
val d: List<String> = ArrayList()     // type declared explicitly

4# Умные приведения типов (Smart Casts)


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


if (obj is String) {
    print(obj.toUpperCase())     // obj is now known to be a String
}

5# Интуитивные равенства (Intuitive Equals)


Можно больше не вызывать явно equals(), потому что оператор == теперь проверяет структурное равенство:


val john1 = Person("John")
val john2 = Person("John")
john1 == john2    // true  (structural equality)
john1 === john2   // false (referential equality)

6# Аргументы по умолчанию


Больше не нужно определять несколько одинаковых методов с разными аргументами:


fun build(title: String, width: Int = 800, height: Int = 600) {
    Frame(title, width, height)
}

7# Именованные аргументы


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


build("PacMan", 400, 300)                           // equivalent
build(title = "PacMan", width = 400, height = 300)  // equivalent
build(width = 400, height = 300, title = "PacMan")  // equivalent

8# Выражение When


Оператор ветвления заменён гораздо более читабельным и гибким в применении выражением when:


when (x) {
    1 -> print("x is 1")
    2 -> print("x is 2")
    3, 4 -> print("x is 3 or 4")
    in 5..10 -> print("x is 5, 6, 7, 8, 9, or 10")
    else -> print("x is out of range")
}

Оно работает и как выражение (expression), и как описание (statement), с аргументом или без него:


val res: Boolean = when {
    obj == null -> false
    obj is String -> true
    else -> throw IllegalStateException()
}

9# Свойства


Можно добавить публичным полям кастомное поведение set & get, т. е. перестать набивать код безумными геттерами и сеттерами.


class Frame {
    var width: Int = 800
    var height: Int = 600

    val pixels: Int
        get() = width * height
}

10# Data Class


Он наполнен POJO-объектами toString(), equals(), hashCode() и copy(), но, в отличие от Java, не занимает 100 строк кода:


data class Person(val name: String,
                  var email: String,
                  var age: Int)

val john = Person("John", "john@gmail.com", 112)

11# Перегрузка оператора (Operator Overloading)


Заранее определённый набор операторов, которые можно перегружать для улучшения читабельности:


data class Vec(val x: Float, val y: Float) {
    operator fun plus(v: Vec) = Vec(x + v.x, y + v.y)
}

val v = Vec(2f, 3f) + Vec(4f, 1f)

12# Деструктурирующие объявления (Destructuring Declarations)


Некоторые объекты могут быть деструктурированы, что бывает полезно, к примеру, для итерирования map:


for ((key, value) in map) {
    print("Key: $key")
    print("Value: $value")
}

13# Диапазоны (Ranges)


Для улучшения читабельности:


for (i in 1..100) { ... } 
for (i in 0 until 100) { ... }
for (i in 2..10 step 2) { ... } 
for (i in 10 downTo 1) { ... } 
if (x in 1..10) { ... }

14# Функции-расширения (Extension Functions)


Помните свой первый раз, когда пришлось сортировать List в Java? Вам не удалось найти функцию sort(), и пришлось изучать Collections.sort(). Позднее, когда нужно было в строковом значении заменить все буквы строчными, вам пришлось писать собственную вспомогательную функцию, потому что вы не знали о StringUtils.capitalize().


Если бы существовал способ добавления новых функций в старые классы, тогда ваш IDE помог бы найти правильную функцию при завершении кода. Именно это можно делать в Kotlin:


fun String.format(): String {
    return this.replace(' ', '_')
}

val formatted = str.format()

Стандартная библиотека расширяет функциональность оригинальных Java-типов, что особенно полезно для String:


str.removeSuffix(".txt")
str.capitalize()
str.substringAfterLast("/")
str.replaceAfter(":", "classified")

15# Безопасность Null


Java следует называть почти статично типизированным языком. Внутри него переменная типа String не гарантированно ссылается на String — она может ссылаться на null. И хотя мы к этому привыкли, это снижает безопасность проверки на статичное типизирование, и в результате Java-разработчики вынуждены жить в постоянном страхе перед NPE.


В Kotlin эта проблема решена посредством разделения на типы, допускающие и не допускающие значение null. По умолчанию типы не допускают null, но их можно преобразовать в допускающие, если добавить ?:


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

var b: String? = "xyz"
b = null                // no problem

Kotlin заставляет вас бороться с NPE, когда вы обращаетесь к типу, допускающему null:


val x = b.length        // compile error: b might be null

Возможно, выглядит громоздко, но благодаря нескольким своим возможностям действительно полезно. У нас всё ещё есть умные приведения типов, когда типы, допускающие null, преобразуются в не допускающие:


if (b == null) return
val x = b.length        // no problem

Также можно использовать безопасный вызов ?., он возвращает значение null вместо бросания NPE:


val x = b?.length       // type of x is nullable Int

Можно объединять безопасные вызовы в цепочки, чтобы избегать вложенных проверок если-не-null, которые иногда мы пишем в других языках. А если нам по умолчанию нужно не null-значение, то воспользуемся elvis-оператором ?::


val name = ship?.captain?.name ?: "unknown"

Если всё это вам не подходит и вам совершенно точно нужны NPE, то скажите об этом явно:


val x = b?.length ?: throw NullPointerException()  // same as below
val x = b!!.length                                 // same as above

16# Улучшенные лямбды


Это хорошая система лямбд — идеальный баланс между читабельностью и лаконичностью благодаря нескольким толковым решениям. Синтаксис прост:


val sum = { x: Int, y: Int -> x + y }   // type: (Int, Int) -> Int
val res = sum(4,7)                      // res == 11

А вот и толковые решения:


  1. Можно переместить или опустить круглые скобки в методе, если лямбда идёт последней либо является единственным аргументом метода.
  2. Если вы решили не объявлять аргумент одноаргументной лямбды, то он будет неявно объявлен под именем it.

Комбинация этих факторов делает эквивалентными эти три строки:


numbers.filter({ x -> x.isPrime() })
numbers.filter { x -> x.isPrime() }
numbers.filter { it.isPrime() }

Это позволяет нам писать лаконичный функциональный код, вы только посмотрите на эту красоту:


persons
    .filter { it.age >= 18 }
    .sortedBy { it.name }
    .map { it.email }
    .forEach { print(it) }

Система лямбд, объединённая с функциями-расширениями, делает Kotlin идеальным инструментом для создания DSL. Anko — пример DSL, предназначенного для расширения возможностей Android-разработки:


verticalLayout {
    padding = dip(30)
    editText {
        hint = “Name”
        textSize = 24f
    }
    editText {
        hint = “Password”
        textSize = 24f
    }
    button(“Login”) {
        textSize = 26f
    }
}

17# Поддержка IDE


У вас есть целый ряд вариантов, как можно начать работать с Kotlin, но я крайне рекомендую использовать IntelliJ, идущий в комплекте поставки Kotlin — его возможности демонстрируют преимущество ситуации, когда одни и те же люди разрабатывают как язык, так и IDE.
Небольшой пример: это сообщение всплыло, когда я впервые попытался скопипастить Java-код со Stack Overflow:


image
IntelliJ заметит, что вы вставляете Java-код в файл Kotlin




На этом всё, спасибо за чтение! Если мне пока не удалось убедить вас насчёт Kotlin, то рекомендую почитать дополнительные материалы:


Метки:
Mail.Ru Group 959,95
Строим Интернет
Поделиться публикацией
Похожие публикации
Комментарии 282
  • +12
    Интересно. Местами выглядит как родной для меня c#
    • –18
      Скорее жабоскрипт чем C# (вырвиглазное объявление переменных)
      • +4
        Мне больше TypeScript напоминает.
        • +8
          И не только вам kotlin-is-like-typescript
          • +1
            Это не удивительно, Kotlin много заимствовал синтаксиса из Pascal (Delphi), а идеолог TypeScript разрабатывал Delphi в Borland.
            • 0
              Собственно говоря, и С# тоже проектировал этот же господин.
          • –17
            И не удивительно, ведь typescript имеет самый совершенный синтаксис на сегодня.
            Было бы здорово если бы и он компилировался в java.
            • +4
              typescript имеет самый совершенный синтаксис на сегодня.


              Не согласен. Но это дело вкуса.
              • +8

                У бэйсика или ассемблера гораздо более приятный синтаксис.

                • +8
                  Вы просто не пробовали писать сразу в опкодах.
                • +3
                  лучше чем у лиспа не будет синтаксиса
                  • +8
                    возьми ещё этих мягких лисповых скобок
                  • –5
                    Самый совершенный синтаксис — у Parser Студии Лебедева )
            • +2

              Так и есть. Иногда, глядя на фрагмент кода, сложно понять, на каком языке он написан: C# или Java.
              Изначально C# создавался как конкурент Java, но с более богатыми языковыми возможностями. И это сохраняется и до сих пор.


              Дело в том, что ввод новых фишек в Java — процесс медленный и конфликтный, тогда как у C# разработчик один. И можно легко проследить, что сначала новые языковые возможности появляются сначала в C#, а затем через пару лет перекочёвывают в Java. Это, кстати, одна из причин, почему я и пишу на C#, а не Java.


              Вот умные люди решили, что лучше создать новый язык, чем бодаться с корпорациями. И велика вероятность, что этот язык не станет мёртвым.


              А самое крутое было бы, если бы JVM и CLR допилили до такого состояния, чтобы они стали эквивалентны по своим возможностям. Писать на C# под JVM было бы весьма заманчиво.

              • 0
                Писать на C# под JVM было бы весьма заманчиво.

                Xamarin же.
                • 0
                  Xamarin работает на CLR, которая встраивается в основное приложение.
                  • 0

                    Ждем переезда на Core и все станет хорошо.

                • 0

                  Создание альтернативных языков для JVM и .NET уже превращается в специальную дисциплину. Их уже много наклепали в надежде прославиться, но при этом не напрягаться с созданием собственной библиотеки классов.

                  • 0

                    Как раз с библиотеками классов проблем нет ну совсем никаких. Их в принципе не нужно разрабатывать, потому что они есть изначально.


                    Проблемы таких языков исключительно в IDE. Вы можете изобрести супер язык, но без полноценной IDE он будет бесполезен. Здесь же отличие в том, что язык разрабатывают сами создатели IDE.

                    • 0

                      В качестве IDE обычно используется заточенный Eclipse, или плагин для Eclipse.

                      • +1

                        Спасибо, не надо.

                        • 0

                          Ну можно и плагин для IDEA написать или найти, дело вкуса. Под Eclipse их гораздо больше.

              • +2

                Осталось понять на сколько хорош его транслятор.

                • 0
                  Он не умеет транслировать код из типичной Java в идиоматичный Kotlin во многих случаях, однако на выходе всегда рабочий код (и визуально он не хуже Java :))
                  • 0

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

                    • 0
                      Какой там транслятор из Java??

                      Меня интересует как вся эта магия с динамическими кастами транслируется в систему типов Java. И как это сказывается на памяти и производительности.
                      • 0

                        А где вы увидели динамические касты? О_о

                        • –1
                          Smart Casts
                          • +3

                            Но ведь нет никакой магии в Smart Casts.
                            Просто если компилятор может вывести, что переменная на данном участке программы имеет более "узкий" тип, то компилятор позволяет использовать особенности этого типа, автоматически расставляя касты, если это нужно.
                            С точки зрения java/байткода это либо простой каст к подтипу, который бы в java пришлось ручками писать, либо же это каст от nullable типа к not nullable, что отражается только в том, что в коде можно писать . вместо ?. и никак не отражается в сгенерированном байткоде.
                            Соответственно это никак не отражается на памяти и производительности по сравнению с java.

                  • +29
                    Еще одна, 100500-я по счету статья ни о чем… простое перечисление фич.
                    Думал, хоть что-то из практики применения будет.
                    А тут очередная копипаста документации.
                    • +2
                      Так она еще и перевод
                      • 0

                        Так ещё и неправильный местами.


                        т. е. вам больше не нужны проверки instanceof после явных приведений:
                      • +1

                        Не соглашусь. Да, перечисление фич, но это те фичи, которые реально вырастают из практики. Многие из них мне, как прикладному программисту на С++, очень хотелось бы использовать для повышения читаемости и надежности кода команды (или это уже есть в C++ и активно используется).


                        Например, именованные аргументы исключают ошибки, когда путаются местами параметры одинакового типа, и повышают читабельность функций с многими аргументами. Цена такой ошибки — от 2 минут до многих часов отладки. Читабельнось экономит кучу времени при анализе чужого и позапрошлогоднего своего кода.


                        Аналогично:


                        • when (иначе — длинные ошибкоемкие цепочки if-else для небанальных случаев)
                        • декомпозиция (удобный возврат нескольких аргументов из функции, иначе приходится создавать на каждый чих структуру либо нарушать RAII)
                        • not nullable (в С++ можно использовать &, но это не всегда достаточно гибко и трудно переучить народ),
                        • перегрузка операторов (читаемость математики)

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

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

                          А чем tuple/tie не подходят?
                          • 0

                            Для tie надо заранее заводить переменные, к которым привязываешь значение (т.е. нарушение RAII). Есть в 17-м стандарте Structured Bindings (https://skebanga.github.io/structured-bindings/) — ровно то, что нужно, но пока они еще далеко не везде реализованы.

                            • +1

                              Тем, что параметры получаются неименованные.

                        • +2

                          Очень похоже на скалу, отличия просто минимальные, в чем была необходимость создавать новый язык?

                          • +6
                            Система типов слабее, джавистам не надо ни чего нового осваивать.
                            • +3

                              коммерция


                              Когда Kotlin станет мейнстрим-языком, значение компании JetBrains для рынка Software Engineering, на котором она работает, будет совершенно другим. То есть, про нас будут говорить, что мы не какие-то ребята, которые делают удобные, но в любой момент заменяемые инструменты, а как про тех, кто делает некоторую корневую фичу экосистемы, на которой всё строится. Это другой вес, другой информационный поток, и деньги, я думаю, тоже другие.

                              https://habrahabr.ru/company/jugru/blog/318842/

                              • +1
                                Мне нравится их уверенность. Не «если станет...», а прямо-таки «когда станет...».
                                А станет ли?
                                • +6
                                  Ну если гугл анонсировал котлин для андройда, то это, уже серьезное достижение.
                                  • +7

                                    Почему бы и не анонсировать, ведь студия то на базе IntellijIdea в которой естественно добавили поддержку Kotlin. Гугл тут вообще никак не напрягался.

                                    • 0
                                      Если поддержка есть, то видимо им придется всю документацию иметь для Kotlinа тоже. А это очень и очень надо напрягаться.
                                      • 0

                                        Одна страничка, на которой рассказывается, как создать новый проект на котлине — действительно, очень сильно надо напрягаться)

                                  • +1

                                    Пока что на hh.ru есть 320 резюме, где указано слово Kotlin. Либо всё ещё впереди, либо...

                                    • 0

                                      Всё впереди, раз гугл руку приложил. Хайп обеспечен теперь. Блоги уже восторженно истерят о "новом русском языке программирования, на который переходит гугл".


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

                                      • +2
                                        Google ничего не прикладывал, JetBrains сами подсуетились.
                                        • 0

                                          Вы так говорите, будто гугл вообще не при делах. На developer.android.com сами джетбрейновцы пишут?

                                  • +4

                                    То есть предлагается выучить новый язык чисто во славу JetBrains. Называется "not invented here".

                                    • 0

                                      Интересно, переводит ли JetBrains свои проекты на Kotlin.

                                      • 0
                                        Если не ошибаюсь, Rider использует Kotlin.
                                      • 0
                                        Как минимум сервис авторизации полностью написан на Kotlin. На счет остальных продуктов может кто из JetBrains скажет точнее.
                                        • 0
                                          Если верить статьям от Jetbrains — именно для этого они его и делали.
                                          Судя по собственному опыту изучения исходников IDEA — часть новой функциональности/тестов они пишут на Kotlin. Пример: бага, коммит.
                                    • +9
                                      #1 Kotlin — не какой-то там странный язык, рождённый в академических кругах.
                                      Это должно быть мотиватором для тех, кто не осилил Scala?
                                      • +8
                                        очевидно, что это отсылка к Haskell, причем тут Scala?
                                        • 0

                                          Может и к Скале

                                          • +1

                                            Про скалу вечно пишут что Мартин сошел с ума и пренебрегает Enterprise в пользу своих академических интересов. Я с этим решительно не согласен.

                                            • 0
                                              Сошел-не сошел не понятно, но вот вам страшный пропозал который сломает обратную совместимость исходников:
                                              https://github.com/lampepfl/dotty/issues/2491

                                              Парни, которые понаписали много кода на скале уже думают, что им делать — переписывать все или вечно сидеть на устаревшей версии.
                                              • 0
                                                Это не скальное предложение, как бы. В дотти новая система типов, что и без того сломает исходники. Но до неё дожить бы еще.
                                                • +1
                                                  до сих пор там не было предложений, которые бы нельзя было решить в рамках scalafix. насчет того, что и это тоже можно покрыть scalafixом у меня есть сомнения
                                                • +1

                                                  Пропозал есть пропозал, тем более что особого энтузиазма по его поводу не видно.

                                                  • +1
                                                    Спокойствие, его закрыли.
                                                    https://github.com/lampepfl/dotty/issues/2491#issuecomment-304212551
                                                    В обсуждении восторги явно не доминировали и решили, что оно того не стоит.
                                            • +13
                                              Хорошая попытка но нет!
                                              • 0

                                                Зачем миру еще один язык с паскалеподобным синтаксисом объявления переменных? Почему не бейсиковский Let? Это тоже модно!

                                              • +9
                                                Форсинг Kotlin на каждом углу уже начинает надоедать.
                                                Зачем это всё когда есть Scala? Зачем это всё когда на этом языке не написано ничего сравнимого к Akka, Play, Spark, etc.?
                                                • +4
                                                  Зачем все это писать на Kotlin, когда ты берешь и используешь все что есть на Java? вы упустили пункт номер 0.

                                                  Akka, Spark можно легко использовать в Kotlin и их не нужно переписывать если они вам нужны.

                                                  Хотя оригинальные штуки на Kotlin уже появляются, вот например очень интересный проект https://github.com/corda/corda
                                                  • –1
                                                    Хм. Посмотрел минут пять. Знаете, я такое уже много лет пишу на груви. И можно привести почти такой же список, почему груви лучше Java (с версии 8 этот список чуть сократился). Почти 1 в 1 будет. А ведь кложу еще не начали вспоминать :)
                                                    • +2
                                                      Так и есть, но все же Groovy & Clojure это языки с динамической типизацией (опустим compileStatic и core.typed) и нацелены несколько на иную аудиторию, в данной статье же сигнал в основном направлен на Java разработчиков.

                                                      Кроме того JVM тем и хороша — если давать удобный Java Interface, то можно свободно мешать языки в проекте.
                                                      • –3
                                                        Какую такую другую? Груви — вполне рабочий язык для бизнеса, не требующего реал-тайм или квази-рт. Это широчайшая аудитория, по большому счету. Если честно сравнивать, что разве что javascript как целевая платформа не покрывается. Совместимость с Java на высоком уровне — если случайно груви классы в API не выставить, проблем почти не бывает.

                                                        >(опустим compileStatic и core.typed

                                                        Почему опустим-то? Практической разницы — почти никакой.
                                                        • +4

                                                          Очень низкое быстродействие по сравнению с джавой, непонятные перспективы из-за отсутствия финансирования. groovy-eclipse заброшен и только благодаря jetbrains этот язык еще на плаву.

                                                          • 0
                                                            А можете подтвердить слова про быстродействие? Я вот ни разу пожалуй не сталкивался с серьезными проблемами. Ну т.е. оно ниже, чем у просто Java, да и то — JIT с этим борется более-менее успешно.
                                                            • 0
                                                              Ну и кстати про перспективы. Apache Groovy. Помрет, думаете?

                                                              >только благодаря jetbrains

                                                              да что вы говорите? А я думал благодаря gradle…
                                                      • +3

                                                        Во-первых "легко использовать" это миф. Для Java, Clojure есть отдельные API у Spark которые утилизируют сильные стороны соотв. языка. Для Kotlin ничего такого зрелого нет и чуть более-менее сложные вещи сразу будут болью.
                                                        Думаю это справедливо и для Akka, но в меньшей степени и в другой плоскости.


                                                        И второе и самое главное, так зачем в итоге переходить на Kotlin, если все то же самое можно делать и на Scala, а в случае фреймворков написанных на Scala — ещё и с меньшей болью.


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

                                                      • +1
                                                        Это все правда, про акку и пр, но объективности ради, у скалы далеко не все хорошо, например с бинарной совместимостью. И мне вот лично пока не ясно, что будет например после внедрения dotty — очередная ломка? Или наконец наоборот, некоторая стабильность?

                                                        Так что понять авторов котлина вполне можно — они пытаются создать очередной компромисс.

                                                        P.S. Я вовсе не хочу сказать, что у котлина все хорошо. Тут еще посмотреть надо будет.
                                                        • +1
                                                          Ну серьезно… уже надоело это передергивание про бинарную совместимость слушать.
                                                          Ну какая ломка? О чем вы?
                                                          У скалы с этим нормально все. Поддерживается совместимость в рамках мажорной версии.
                                                          Для 11-й версии это порядка 5 лет. Ну вот нафига нужны библиотеки которые 5 лет не поддерживаются?
                                                          Кейсы получения проблем в этом месте настолько малы, что не стоит заморачиваться.
                                                          А даже если прижмет где-то, можно пересобрать под актуальную версию…
                                                          • +1
                                                            Собственно, я и не говорю, что это критичная проблема. Я ее просто как пример привел — неудачные характеристики можно найти у любого языка. Этакий небольшой но лишний геморрой на пустом месте.

                                                            >Ну вот нафига нужны библиотеки которые 5 лет не поддерживаются?

                                                            Ну скажем так — работая на java, я вам таких покажу сотни. То есть тут этой проблемы нет вообще, исключения редчайшие.
                                                            • +1

                                                              У всех библиотек обязательно есть версии _2.10, _2.11, потому что иначе не работает, одни уже дропнули поддержку какой-то там версии, а другие еще не смигрировали… и такая веселуха постоянно. Все отлично в Скале с совместимостью.

                                                              • 0
                                                                Это редко, когда создает проблему. Крупные либы обновляются быстро. Остальные, написанные одним человеком когда-то, в большинстве случаев лучше выкинуть. Зачем тащить труп, который не пересобирается под новую мажорную версию языка при том, что обычно даже код править не надо, только поправить одну строчку в сборке.

                                                                Проблемы есть с тем что множество социально-безответственных авторов из всего jvm мира любят прибивать гвоздями определенные версии и включать их в поставку. Типичная ситуация — вязанка netty, сериализатор древней версии и т.д.
                                                                • +3

                                                                  По поводу "крупные либы обновляются быстро" — Apache Samza только-только добавила поддержку 2.11.


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


                                                                  Экосистемы, где библиотека=живая библиотека, будут оставаться уделом увлеченных энтузиастов и мейнстримом не станут никогда

                                                                  • –1
                                                                    Посыл правильный. Поддержка нужна.
                                                                    Но вот опять сильно передергиваете…
                                                                    Эти ваши говно энтерпрайзы так и останутся на Java. Им не нужны эти хипстерские замашки с новыми языками.
                                                                    Те проекты, кому это надо, будут использовать актуальные версии библиотек. Все, что имеет смыл — обновляется регулярно. И с этим нет никаких жутких проблем, описываемых всеми…

                                                                    Подавляющее большинство древних легаси библиотек никогда не будут переписаны даже под новую Java, не говоря уже про новые языки. И для них так же как и сейчас, будут писать обертки, для удобства.
                                                                    Все будет происходить ровно так же как сейчас на Java. Многие конторы только сейчас переходят на Java8, много еще сидит на Java6.
                                                                    То же самое будет и со скалой. Люди будут долго сидеть на мажорной версии. А это все атаки несколько лет поддержки. Потом захотят перейти, обовиться, и либо найдут замену древним легаси библиотекам, либо пересоберут их сами. Ну или, как тоже делают, переосмыслят проект. Возможно и на другом языке. Слишком быстро сейчас все движется, что бы 20 лет сидеть на древних библиотеках…
                                                                    Еще раз повторюсь, конечно такие конторы есть и будут. Которым надо 20 лет поддержки. Для них есть Java. Все остальные никаких особых проблем с обратной бинарной совместимостью библиотек для Scala не почувствуют…
                                                                    • 0
                                                                      Знаете, все вменяемые обновляются быстро и легко. А те кто сидит на Java 6… ну я знаю одну такую контору. Как почитаешь их требования — сразу хочется забыть, что видел эти вакансии. И Java 6 тут самое меньшее из зол обычно.
                                                                      • +1

                                                                        У меня java6 в 10 магазинах на дебиане пятилетней свежести работает на местах кассира — я не вижу смысла в обновлении ради обновления. У меня есть масса более интересных занятий чем раз месяц кататься по магазинам с обновлениями дебиана на флэшке )


                                                                        В прошлом годе даунгрейдил библиотеку для печати qr-кодов с java8 на java6, потому что это быстрее и проще. Я невменяемый )

                                                                        • 0
                                                                          Я вообще-то в данном случае имел в виду, что миграция на другую версию Java — это наименьшая из трудностей. Решаемая при минимальном уровне вменяемости.

                                                                          Если вам это не нужно — это немножко другой случай. Особено если вы это приложение не разрабатываете.

                                                                          У меня другая ситуация — пришли безопасники, и принудительно потребовали обновиться на поддерживаемую Java 8. Возражения принимаются, но не охотно.
                                                                    • 0
                                                                      Не могу назвать опыт с «живым» софтом на коболе или java <=1.4 правильным. Это выливается в еще большие проблемы с поддержкой или миграцией, которые усугубляются с каждым годом. Имхо, принудительное стимулирование двигаться вперед полезно всем.

                                                                      По поводу «крупные либы обновляются быстро» — Apache Samza только-только добавила поддержку 2.11.
                                                                      Могу еще спарк привести в пример, но это не значит что это поголовная проблема.
                                                                      • +3

                                                                        У вас может быть библиотка с какой-то сложной математикой написанной под Java 1.4. И при переходе на Java 8 она все еще будет корректно рабоать (и почти наверняка станет работать быстрее).


                                                                        Вопрос: зачем хоть что-то делать с библиотекой, если за пятнадцать лет математика и формулы не поменялись? Это очень хорошо и важно, когда можно использовать старые библиотеки без изменений. Если этого нет — то экосистема убивает сама себя.

                                                                        • –1
                                                                          [mode=troll]Мат либу, реализованную без дженериков, поддерживать само собой не особо захочется. Конечно она застряла без развития.[/mode]

                                                                          Как ни странно, но математика меняется. И алгоритмы и оптимизации, которые могут быть применены тоже. Не говоря уже про blas библиотеки, которые стоят у многих java либ под капотом. Поэтому про перформанс, который улучшается с годами как вино, не надо говорить.

                                                                          Понимаю, что это пример был, но он неудачный (опыт собственно был с этим).
                                                            • +9
                                                              Потому что 95% программистов никогда Scala не осилит. Она реально экстремально сложная. Одно и то же делается десятками путей, по-умолчанию в стандартной библиотеке дофига всяких знаков вместо нормальных ключевых слов. И не надо говорить «никто вас не заставляет все пути использовать» — открываешь какой-нибудь пример из гугла и сразу видишь жуткие конструкции с "++=" и прочим.
                                                              Я сам очень люблю Scala, прошёл пару курсов на Coursera, писал программы «для себя» на ней, но как только попробовал Kotlin, так возвращаться к Scala совсем не хочется.
                                                              • +4

                                                                Про 95% это вы так же с потолка взяли, так же как и JetBrains про 100% интероп?


                                                                жуткие конструкции с "++=" и прочим

                                                                Т.е. в java/kotlin x += 1 понятная конструкция, а вот xs ++= List(1,2,3,4) уже жуткая, если учесть конкатенация двух списков это ++
                                                                В Котлин придостаточно жутких конструкция по типу


                                                                thing?.thing1?.thing2 ?: 10

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

                                                                • 0

                                                                  Насколько я помню, Scala позволяет определелять новые "жуткие" конструкции (даже <|*|>), а вот Kotlin нет. С точки зрения простоты языка это действительно преимущество.


                                                                  или сложных конструкций по типу делегатов, которые Джавистам не знакомы.

                                                                  Они появились как раз потому что знакомы, вызывают боль и ошибки из-за копипасты и вполне могут быть сгенерированы компилятором. Ещё один шаблон на уровне языка и это отлично.

                                                                  • –1
                                                                    А если ещё добавить магию statements, получаем

                                                                    fun test()
                                                                    {
                                                                      for
                                                                      {
                                                                        val a = someVariable?.test ?: return
                                                                       
                                                                       ....
                                                                      }
                                                                    }
                                                                    


                                                                    И если мы добавляем ещё лямбды, то можно ногу сломать.

                                                                    что? где? когда?
                                                                  • +1
                                                                    Scala многоуровневая. Требования к разработчику библиотек на порядок отличаются от требований к использующему их программисту. На уровне рядового программиста она не сложнее java. Даже проще, за счет меньшего объема шаблонного кода и поддержки системы типов в IDE.
                                                                    • +1
                                                                      В любой более-менее взрослой компании есть внутренний набор библиотек и общего кода. Да даже внутри серьёзных проектов такое постоянно.
                                                                      Да и с чего Вы взяли, что рядовой программист не читает исходники использованных библиотек? А если это внутрикорпоративные библиотеки, то и правит.
                                                                  • +8
                                                                    Kotlin, на мой взгляд, находит баланс между функциональностью и простотой. Scala мощная и красивая, но за ней необходим очень-очень тщательный уход, чтобы избежать появления «i >>#$<<+=$ j col **%%# k», нужны очень дорогие разработчики и лид из-за высокого порога вхождения, дорого передавать проект другой команде.

                                                                    Kotlin почти не сложнее Java, он не про «сделать новый сложный, мощный и красивый язык», а про «убрать болевые точки, упростить стандартные паттерны, не делая дороже совокупную стоимость владения и переиспользуя текущих людей». Поэтому, например, у Kotlin есть кросс-трансляция в Java и обратно, поэтому гарантируется полная интероперабельность с Java-кодом, а не как в Scala, когда Scala-классы из-под Java использовать зачастую нереально больно, если только они изначально не проектировались с расчетом на этом.

                                                                    Для личных проектов for fun я бы выбрал Scala — она интересная; для бизнес-проектов — Kotlin — это стабильно, удобно и лучше в плане цена/качество.

                                                                    Не претендую на истину, конечно, но для меня это выглядит так.
                                                                    • +3
                                                                      Scala мощная и красивая, но за ней необходим очень-очень тщательный уход, чтобы избежать появления «i >>#$<<+=$ j col **%%# k», нужны очень дорогие разработчики и лид из-за высокого порога вхождения, дорого передавать проект другой команде.

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

                                                                      То сложное, что скала позволяет делать, завязано на работу с типами. Нужно в реализации приложений редко и можно обойтись. Как раз для таких финтов и нужны более дорогие разрабы.
                                                                      • –1
                                                                        К каждому разработчику на планете тимлида с кодревью не поставишь. А читать код придётся разный.
                                                                      • +1
                                                                        А вот это, так же как комментарий semmaxim выше — чистейшая правда.
                                                                        Вот это действительный минус Scala и Одерски прекрасно это понимает:

                                                                        My second resolution is to take a larger effort to promote simplicity in Scala. I believe the recent blog post by Jim Plush should be a wakeup call for our community. Scala is a very powerful and un-opinionated language. This means we have a large spectrum of choice how to write a Scala application or library. It’s very important for all of us to use this power wisely, and to promote simplicity of usage wherever possible.


                                                                        И это действительно сильная сторона Kotlin — относительная простота, на это и стоило бы им делать упор.
                                                                        • +1
                                                                          По моему опыту, код вида «i >>#$<<+=$ j col **%%# k» возникает очень редко. Если возникают сложные конструкции, то они почти всегда заменяют много строк, которые пришлось бы вместо них написать на java, и которые бы, за счет их количества, читать было бы не проще.
                                                                      • +7
                                                                        «не какой-то там странный язык, рождённый в академических кругах» — ну а это просто смешно, учитывая что за почти каждой перечисленной здесь фичей мерещится аналогичная из Scala
                                                                        • +20
                                                                          YAPL — yet another programming language.

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

                                                                          Если у меня новый проект, то я буду смотреть на:
                                                                          • наличие специалистов в команде
                                                                          • лицензионные ограничения
                                                                          • требования к рабочему окружению
                                                                          • среду разработки
                                                                          • возможности стандартной библиотеки
                                                                          • наличие сторонних библиотек
                                                                          • поддержку параллелизма
                                                                          • перспективу развития
                                                                          • интеграцию с инструментами документирования, багтрекинга, управления ЖЦ, Continuos Integration и т. п.

                                                                          и где-то там, пунктов на 10 ниже, будет синтаксис.

                                                                          Поэтому описание особенностей синтаксиса не отвечает на вопрос из заголовка: «Почему следует полностью переходить на Kotlin».
                                                                          • +3
                                                                            Ну, синтаксический сахар тут явно не экономили, так что тупо заметно меньше придётся печатать.
                                                                            • 0

                                                                              В плане меньше печатать — это к фреймворкам типа Spring. Интересно, есть ли подробные гайды по использованию Spring в Kotlin...

                                                                              • +3
                                                                                https://spring.io/blog/2016/02/15/developing-spring-boot-applications-with-kotlin
                                                                                https://kotlinlang.org/docs/tutorials/spring-boot-restful.html
                                                                                не сказал бы что это прям гайды, просто несколько фактов, которые полезно знать. А в целом гайды нужны именно для использования Spring, а уж использование его в Kotlin ничем не отличается от использования апи других библиотек/фрэймворков
                                                                                если же интересуют именно подобные посты на хабре, то да, тут были несколько:
                                                                                https://habrahabr.ru/post/274997/
                                                                                https://habrahabr.ru/post/274713/
                                                                            • 0
                                                                              Согласен.
                                                                              Из опыта работы был долгоиграющий проект на FORTH, и писали…
                                                                              • 0

                                                                                Старина Форт еще жив?
                                                                                сам когда то на нем баловался, интересный язык был

                                                                              • +2
                                                                                интеграцию с инструментами документирования, багтрекинга, управления ЖЦ, Continuos Integration и т. п.

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

                                                                                • 0
                                                                                  Язык точно этого не должен. Это для багтрекера желательно уметь использовать особенности языка. Я не говорю, что это обязательно, но при выборе языка для нового проекта я на это посмотрю

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

                                                                                  В части багтрекинга мне было бы достаточно, если бы в багтрекере была подсветка синаксиса, а в IDE работали бы ссылки из комментариев вида // Also see Issue 166;.
                                                                                  • 0

                                                                                    Тем не менее, это больше про возможности вашего редактора кода. Если он умеет делать кликабельными ссылки в комментариях к коду, то он сделает это в любом языке с коммеетариями.


                                                                                    Почему вы считаете это более приоритетным, чем собственно синтакис языка, мне непонятно.

                                                                                • 0
                                                                                  ЯП это не только синтаксис, но и как часто он не позволяет отстреливать себе ноги.
                                                                                • +10

                                                                                  Почему… почему в каждой статье пишут про 100% интероп? Откуда взялась эта цифра, она взята с потолка? Почему не 90%, 95% или 148%?
                                                                                  Уже появляются доклады в которых рассказывать что даже Java код иногда сложно вызывать (https://youtu.be/CABN2r4GPpQ?t=45m9s), а этот язык только недавно релизнулся.
                                                                                  Я молу про то, что большую часть kotlin фишек нельзя вызвать из java кода. Вот что у меня получилось при попытке вызвать suspend method из java:


                                                                                  Sequence<Integer> seq = SequenceBuilderKt.buildSequence(new Function2<SequenceBuilder<? super Integer>, Continuation<? super Unit>, Object>() {
                                                                                              public Object invoke(SequenceBuilder<? super Integer> sequenceBuilder, Continuation<? super Unit> continuation) {
                                                                                  
                                                                                                  return null;
                                                                                              }
                                                                                          });

                                                                                  и это только начало списка, ещё есть extension methods, object companion и т.д.
                                                                                  В итоге получается, если хотите java interop не используйте kotlin фишки, пишите на такой же java только с сахаром.

                                                                                  • +6
                                                                                    Эта цифра взялась из маркетинга очевидно.
                                                                                    Если почаще кричать, то толпа не будет задумываться, а хайп покроет все.
                                                                                    Когда пыль рассеется, поздно будет давать заднюю…
                                                                                    • +4
                                                                                      Я бы не советовал как пример приводить вызов suspend методов. Все-таки suspend методы это очень специфичный механизм работы корутин (экспериментальной фичи) из 1.1, который настолько интегрирована в язык и инфраструктуру что вызов из Java и будет выглядеть абсолютно чужеродно.

                                                                                      А по поводу интеграции в Джаву вообще вопрос интересный. Вот реально субъективно возникает меньше ощущения «другой» платформы, чем от Скалы, хотя на Скале промышленно писать не доводилось.

                                                                                      Банальный пример, Скала:
                                                                                      collection.mutable.Map[String, String]().isInstanceOf[java.util.Map[String, String]] // false
                                                                                      

                                                                                      и Котлин
                                                                                      emptyMap<String, String>() is java.util.Map<*, *> // true
                                                                                      


                                                                                      И хотя у Скалы есть asJava, но все равно не используя полностью всю мощь коллекций Скалы наверное жить в мире Скала не очень весело.

                                                                                      Еще Котлин хорошо интегрируется во все системы байт-код «хакинга» (типа Мокито, хотя и не без проблем), анализа и т.п. Поэтому с ним работают Спринг (официально) и даже магические библиотеки типа Quasar (которые от поддержки Скалы отказались как раз по причине заморочек с байт-кодом). Т.е. Котлин чувствуется именно что «лучшей Java-ой», а Скала все таки другим языком и иногда даже другой платформой. Что в целом не плохо само по себе.

                                                                                      На какой-то конференции была фраза, что Котлин и Джава достаточно похожи, чтобы можно было легко перейти с одного языка на другой, но достаточно разные, чтобы этот переход того стоил.
                                                                                      • +2
                                                                                        А по поводу интеграции в Джаву вообще вопрос интересный. Вот реально субъективно возникает меньше ощущения «другой» платформы, чем от Скалы

                                                                                        Безусловно интеграция с джавой у Котлина лучше (и наверное лучше чем у любого другого JVM языка), по поводу этого не спорю. Но лучше, это относительное понятие, а не величина. Если мы говорим про цифры, то эти цифры должны быть подтверждены (а если нет подтверждения, то какой смысл в конкретных величинах?), тем более если мы говорим про громогласное заявленное на офф сайте 100%. 100% — значит что мы должны иметь возможность без костылей вызвать это в Java, не смотря на сколько это "чужеродно". И такие "чужеродности" не только с suspend method их ещё много, все это придется пережить и узнать кто будет использовать Котлин, выполняя роль тестировщика языка.


                                                                                        Я бы не советовал как пример приводить вызов suspend методов.

                                                                                        Осталось сделать такой список на офф сайте Котлина: "Мы не советуем вам использовать эти фичи Kotlin'а т.к. вы потеряйте интероп" и я бы даже слова не сказал. Или ещё лучше какой-нибудь флаг компилятора, который выключал все эти фичи и позволял бы писать на каком-нибудь подмножестве Котлина, который бы имел интероп. Потому что уже сейчас появляются библиотеки на Котлине, которые используют спицифичные для Котлина фичи, и которые сложно вызывать из Java, но создатели этих либ особо об этом не парятся. В результате получается своя экосистема, такая же как в Clojure или Scala.


                                                                                        Еще Котлин хорошо интегрируется во все системы байт-код «хакинга» (типа Мокито, хотя и не без проблем), анализа и т.п. Поэтому с ним работают Спринг (официально) и даже магические библиотеки типа Quasar

                                                                                        Если вы посмотрите issues лист Quasar, то увидите что там достаточно специфичных багов связанных с использованием Котлина.

                                                                                      • 0
                                                                                        ещё есть extension methods, object companion и т.д.

                                                                                        А с ними что не так?


                                                                                        На самом деле лично меня раздражает только одна проблема с вызовом котлина из джавы: вызов методов принимающих колбэки с void (Unit в котлине)… Приходится писать return Unit.instance. Это из за этого что параметры имеют тип FunctionX<..., Unit>. Поэтому если предполагаются ява пользователи кода котлина, приходится делать утилитные методы.


                                                                                        suspend методы в принципе не могут быть вызваны из джавы, ведь все кто их вызывают также должны уметь засыпать в месте вызова этой самой функции. Без поддержки со стороны какого бы то ни было компилятора делать это бессмысленно.


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

                                                                                        • +2
                                                                                          А с ними что не так?

                                                                                          с extension methods все отлично, вот только проблема в том в Java их нет. Приходится вызывать статические методы. Особенно это уродски выглядит когда либа на Котлине их использует повсеместно.


                                                                                          companion object приходится анноторивать @JvmStatic, что бы можно было нормально из Java вызывать, вот только к сожалению часто их не аннотируют почему-то.


                                                                                          на скале вызывать почти невозможно

                                                                                          Да уж невозможно конечно. Поэтому большинство мейн-стримовых скаловских фреймворках доступны из java.


                                                                                          В котлине таких проблем нет

                                                                                          Есть с тем же suspend methods. Или вы собрались использовать некое подмножество языка? Ну так это можно так с X где X любой JVM язык.


                                                                                          К слову, большенство кода написанного на скале вызывать почти невозможно.

                                                                                          Дело не в выигрышах или проигрышах, а дело в заявленных 100%, смотрите я ответил выше. Особенно это актуально для Джавистов, если они собрались потом использовать Котлиновский код.

                                                                                      • 0
                                                                                        … делает Kotlin идеальным инструментом для создания [DSL](C:\Users\Desktop\Cloud Mail.Ru\Mail — Почему нужно полностью переходить на Kotlin\в Kotlin). Anko — пример DSL...

                                                                                        Мне кажется, что что-то не дописано...

                                                                                        • +1
                                                                                          Пора статью написать «Почему следует полностью оставаться на Java», а заголовки настолько вызывающе написаны, можно было сразу,java умерла.До сих пор не догоняю зачем это Kotlin? Есть же Scala…
                                                                                          • –2
                                                                                            Kotlin много проще. Тут скорее стоит сравнить с xtend или чем-то подобным — рафинированная java. С учетом теоретической возможности Kotlin транслироваться в native (ага, опять привет Scala!) — есть возможность красиво отвязаться от jdk/oracle/суды/…

                                                                                            А вообще, конечно, «это уже было в Симпсонах» (с)

                                                                                            • 0

                                                                                              Под native же ещё native-библиотека понадобится, язык на этом фоне будет незначительной проблемой.

                                                                                              • 0
                                                                                                Затянуть LLVM на Android, думаю, не проблема. Scala-native, насколько мне не изменяет память, аккурат на LLVM заточена. Уверен, что Kotlin-native, тоже LLVM.

                                                                                                К чему это я? Стараюсь, упорно стараюсь найти use-case для Kotlin, и native звучит как некоторый возможный задел на будущее. Однако в данный момент — не нужно.
                                                                                                • 0

                                                                                                  Под LLVM нет стандартной библиотеки классов, в отличии от JVM или .NET. Хорошо написать такую библиотеку, а потом ещё и убедить разработчиков её освоить — та ещё задача.

                                                                                              • +1
                                                                                                Для Scala трансляция в native тоже вполне возможна. К тому же она меньше завязана на стандартную библиотеку Java (так как система типов диктует другой подход к разработке библиотек).
                                                                                                • 0
                                                                                                  Я же с этим совершенно не спорю :-)
                                                                                                  Просто пытаюсь найти хотя бы какие-то плюсы в Kotlin. Но как не находил раньше, так и не нахожу сейчас.
                                                                                            • +2

                                                                                              А вот мне понравился Fantom, давайте переходить на него. Приятный синтаксис с сахарком, плюс совместим с JVM и .NET, плюс существует дольше — проверен временем.

                                                                                              • –1

                                                                                                Что это вообще?
                                                                                                Поддержка IDE?
                                                                                                Поддержа крупных компаний?

                                                                                              • +1
                                                                                                Им надо не програмистам объяснять достоинства котлин, а манагерам. К примеру «Если вы внедрите котлин, то за счет более лаконичного синтаксиса, вы сможете сэкономть столько-то человеко-строк-кода-денег». Может прокатит.
                                                                                                • 0
                                                                                                  ) и тактично умолчать об убытках понесённых в процессе перехода с одного языка, на другой…
                                                                                                • 0

                                                                                                  Чем-то напомнило — https://www.parser.ru/

                                                                                                  • –2
                                                                                                    Улыбнуло. «Swift is like Kotlin».
                                                                                                    А не наоборот ли? Или Kotlin первый появился?
                                                                                                    • +5
                                                                                                      Kotlin — 2011, Swift — 2014.
                                                                                                      Просто Swift сразу зарелизился, и ломали совместимость уже по ходу выпуска новых версий.
                                                                                                      А Kotlin разрабатывался много лет открыто вместе с сообществом, и зарелизился только в 2016.
                                                                                                    • +1
                                                                                                      Хочется рассказать впечатлениях от боевого использования.
                                                                                                      Проекту, где я тружусь, уже больше 3-х лет. Мы последовательно попробовали Java, Groovy, Scala, Kotlin (последние полтора года).
                                                                                                      Итого: победил Kotlin, Java и Groovy остались только в виде legacy, причем Groovy только в тестах (из-за Spock Framework), Scala не прижилась совсем.
                                                                                                      Все разработчики смогли относительно безболезненно перейти на Kotlin, а лично я после Groovy и Scala просто сел и начал писать.
                                                                                                      Действительно, не все фичи Kotlin удобно использовать из Java, в обратную сторону таких проблем не наблюдается.
                                                                                                      Итого: если legacy вас не сдерживает — пробовать можно, нужно и приятно. Если сдерживает — просто немножко подумайте над API ваших компонентов.
                                                                                                      • +4

                                                                                                        Астрологи объявили год поклонения Котлину. )) Как это знакомо все… Года не проходит, начинаются посты Почему вас стоит… А через год, может и от этого же автора про другой язык и что Х, оказался не так хорош и бла бла. Прямо как с javascript, но там итерации короче — где-то полгода, до очередного просветления.

                                                                                                        • –7

                                                                                                          А что, всем на самом деле так нравится синтаксис Котлина?
                                                                                                          Меня он местами выбешивает.


                                                                                                          • вместо var, val зачастую полезнее видеть тип
                                                                                                          • аналогично fun — лишний визуальный мусор
                                                                                                          • companion object для статических методов и констант выглядит прилепленным сбоку
                                                                                                          • постоянно приходится использовать !!
                                                                                                          • не протикся идеей одного конструктора и впихиванием его и нформации о наследовании в одну строчку
                                                                                                          • синтаксис значения по умолчанию для аргумента функции off: Int = 0 явно разрабатывался в Мюнхенском офисе (как по-немецки говорят "сто четые и двадцать", а не "сто двадцать четыре").
                                                                                                          • ключевое слово override для метода — лишний мусор по сравнению с @Override.
                                                                                                          • по умолчанию класс не наследуется (так взяли и задушили всю прелесть OOП)
                                                                                                          • т.д.
                                                                                                            Cинтаксис Java ИМХО значительно гармоничнее, а киллер-фич, значительно повышающих производительность, не обнаружил. Зато намного проще написать в одну строчку код, который потом сложно понять.
                                                                                                          • +4

                                                                                                            1) Одно другого не исключает. Нужен тип — пишите.
                                                                                                            2) В котлине вы можете объявить функцию в теле метода, вне класса, в классе. И везде такое объявление выглядит одинаково.
                                                                                                            3) Объявляйте константы вне класса, если companion object не нравится.
                                                                                                            4) "!!" aka оператор "костыли" — не самая изящная часть kotlin, однако, его почти всегда можно избежать.
                                                                                                            5) Не со всем понимаю, о чем речь. Конструкторов может быть больше одного.
                                                                                                            6) Сначала выглядит странно, но привыкнуть не сложно.
                                                                                                            7) Ключевое слово override гораздо строже, чем аннотация (которой может не быть), и это скорее хорошо.
                                                                                                            8) Отсутствие наследования по умолчанию — это явный плюс. Я и в java класс не предназначенный для расширения объявлял final, и таковых всегда было большинство. Вообще в большом проекте запрещение всего, что явно не разрешено, чаще сказывается благотворно.

                                                                                                            • +4
                                                                                                              1. Давайте proof of concept, хватит BNF. Из очевидных плюсов вывода типов можно выделить более простую работу со вложенными дженериками.
                                                                                                              2. См. 1.
                                                                                                              3. Статические члены, в свою очередь, прилеплены сбоку к классам и объектам.
                                                                                                              4. Так вы от NPE не спасетесь.
                                                                                                              5. Вы же в курсе что можете сделать по другому? Ещё Дейкстра говорил что поведением по умолчанию должен быть частоиспользуемый вариант, в Kotlin это так.
                                                                                                              6. А вот тут соглашусь, могли бы и сюда вывод типов завести.
                                                                                                              7. Почему? То, что раньше было просто правилом хорошего тона, стало обязательной конструкцией языка, по-моему вполне естественная и полезная метаморфоза.
                                                                                                              8. См. 5 про Дейкстру. (И вообще пользуйтесь интерфейсами, JIT придет — порядок наведет!)
                                                                                                              9. И т. д.
                                                                                                              • 0
                                                                                                                по умолчанию класс не наследуется (так взяли и задушили всю прелесть OOП)

                                                                                                                Читайте Effective Java

                                                                                                                • +2

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

                                                                                                                  • +2
                                                                                                                    > синтаксис значения по умолчанию для аргумента функции off: Int = 0 явно разрабатывался в Мюнхенском офисе (как по-немецки говорят «сто четые и двадцать», а не «сто двадцать четыре»).

                                                                                                                    Это спорно. Да, есть традиция (которую сохраняет C и потомки), что формат определения переменной — «тип переменная [=начальное]», в противоположность традиции, известной по Pascal и прочим — «var переменная: тип [=начальное]». Но сишная традиция заметно усложняет парсинг (уже лексер должен отдавать, чем является идентификатор — типом, переменной, чем-то иным; или парсер должен справляться с неоднозначностями уже после построения конструкций), формат записи (все эти foo (*fptr)(bar) долго учатся новичками)…
                                                                                                                    Для сравнения, Go использует паскалевский вариант (только ':' убрали — «var переменная тип») — в нём много спорных моментов, но этот явно выглядит как результат идеи прекратить топтаться заново по этим граблям. Swift использует паскалевский вариант. По сравнению же с вот такими чудесами — неудивительно, что пытаются упрощать.

                                                                                                                    Это же касается и второго замечания:

                                                                                                                    > аналогично fun — лишний визуальный мусор

                                                                                                                    та же тема — упрощение грамматики приводит к понятности всем. Дополнительно, такой fun позволяет сделать простой и ясный синтаксис замыканий/лямбд (что показал хотя бы Javascript).

                                                                                                                    > по умолчанию класс не наследуется (так взяли и задушили всю прелесть OOП)

                                                                                                                    Это показывает определённый настрой, но не выглядит фатальным — ведь всегда можно умолчание изменить? В C++ умолчание для метода — не виртуальный, в Java/C# — виртуальный, от этого в C++ стало меньше возможности перекрыть метод?

                                                                                                                    > ключевое слово override для метода — лишний мусор по сравнению с Override.

                                                                                                                    Ну, тут лучше было бы поступить радикально — как по требованию .NET CLR — метод сделать любой идентификатор, даже совпадающий с ключевым словом. Если это есть — несколько лишних ключевых слов не проблема.
                                                                                                                  • +3

                                                                                                                    При всем уважении к ребятам из jetbrains, я так и не понял зачем мне на очересной java-спутник переходить из-за синтактического сахара. Тем более что к лету обещали 9-ю джаву с алокацией на стеке и АОТ-компиляцией?

                                                                                                                    • +2

                                                                                                                      Ну за этим языком не будет Oracle стоять, и вилять своими адвокатами перед носом

                                                                                                                      • 0

                                                                                                                        Там ещё адвокаты Microsoft есть — это уже к Android как к системе в целом.

                                                                                                                      • +6

                                                                                                                        С аллокацией на стеке? Вы про что и кто это обещал? Что-то из разряда "слышал звон".

                                                                                                                        • 0

                                                                                                                          Вы правы, я фигню сказал. не знаю откуда я это выкопал, но сейчас погуглил, и ничего похожего не могу найдти.

                                                                                                                          • +2

                                                                                                                            Подозреваю, что вы value types за аллокацию на стеке приняли. В девятке их всё равно не будет. И аллокация на стеке ортогональна value-типам. Джава уже давно умеет не то что на стеке аллоцировать, а в регистры раскидывать объект вообще без аллокации. Или в принципе избавиться от объекта, если позволяет ситуация.