company_banner
24 мая в 19:01

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


Хочу рассказать вам о новом языке программирования, который называется 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, то рекомендую почитать дополнительные материалы:


Автор: @AloneCoder Magnus Vinther
Mail.Ru Group
рейтинг 614,33
Строим Интернет

Комментарии (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
            deleted
        • 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-типам. Джава уже давно умеет не то что на стеке аллоцировать, а в регистры раскидывать объект вообще без аллокации. Или в принципе избавиться от объекта, если позволяет ситуация.

    • +2

      AOT компиляцию и в Котлин быстро завезут, после того как Java 9 выйдет, а синтаксических улучшений в Java 9 примерно ноль

    • +2
      На андроиде java полузастряла на 1.7, так что котлин для гугля это очередная хипстерская мина при плохой игре.
  • +1
    Система лямбд, объединённая с функциями-расширениями, делает Kotlin идеальным инструментом для создания [DSL](C:\Users\Desktop\Cloud Mail.Ru\Mail — Почему нужно полностью переходить на Kotlin\в Kotlin).
  • +2

    Такое чувство, будто обзор на Swift прочитал. Хаха

    • 0

      Тсс, не пали кантору.

  • +4
    «Жизнеспособность и практическая пригодность языка программирования в современном мире прямо пропорциональна количеству материала по нему на Stackoverflow.» © Я.
  • +1
    кстати, сам mail.ru не планирует перейти полностью на kotlin в своём android-приложении «Юла»?
  • +2

    А вот почему не стоит переходить. Компилятор до ума довели, вопросов нет. Но поддержка в IDE страдает. Каждый раз, когда я влезаю в Котлин, напарываюсь на какую-нибудь неприятность вроде этой. Тонна Java-инспекций в Котлине не работает, хотя имеет смысл, если активно используешь всякие Java API.

    • 0

      А нельзя делать инспекции сразу для двух языков, на каком-нибудь упрощенном синтактическом уровне, общем для Java и Kotlin? Конечно не для все инспекции будут так работать, но по ощущению примерно половина — должна

      • 0

        Можно, но пока довольно ограниченно и без квик-фиксов (см. uast). Да и придётся переписывать кучу существующих инспекций.

  • 0
    Как же быстро всё меняется… Это конечно и здорово — постоянно учить что то новое, развиваться. Спасибо за полезный материал :)
  • +1
    Java-разработчики вынуждены жить в постоянном страхе перед NPE

    Это какая-то профанация?!

    переменная типа String не гарантированно ссылается на String — она может ссылаться на null

    Абсолютное непонимание того что такое null, и зачем он «нужен», тем более что приведенный далее код и пояснения не объясняют что же в 'котле' такого инновационного и избавляющего от страха NPE…

    • +3
      и пояснения не объясняют что же в 'котле' такого инновационного и избавляющего от страха NPE

      Насколько я понял, kotlin не скомпилирует код, в котором не сделана проверка на null для типа, который может быть нулабл. Эдакая защита от дурака на уровне комплилятора.

      • +2
        Это не столько защита от дурака, сколько возможность использовать опциональность типов. Большая часть использований Optional (Option в Scala) заменяется на nullable тип в Kotlin. Так и их использование становится проще, и в коде не создается лишних инстансов.
        • 0
          Но теряется возможность использовать монадический синтаксис и унифицированный код, работающий с разными типами коллекций. Да и я бы не сказал, что большое количество '?' делает код сильно проще.
          • +2
            Но теряется возможность использовать монадический синтаксис и унифицированный код, работающий с разными типами коллекций

            Просто один подход заменяется на другой. Да и для nullable типов в Kotlin есть специальные расширения для коллекций (типа filterNonNull и т.п.)
            Да и я бы не сказал, что большое количество '?' делает код сильно проще.

            Спорное утверждение, кому что ближе =)
            Из своего опыта могу сказать что мне подход Kotlin ближе. К примеру код на Scala: fun1().flatMap( _.fun2).flatMap( _.fun3) заменяется на fun1()?.fun2()?.fun3()
          • 0
            Да и, в принципе, тот же монадический синтаксис можно использовать и в Kotlin, где нужно.
          • –2

            Монадический синтаксис — это средство, а не самоцель.

        • 0

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

          • 0
            Если вы в таких местах используете Option, то у вас будет либо Some с объектом, либо None. В случае None вы так же теряете информацию о том что пошло не так. (в таких случае целесообразней использовать другой механизм, может тот же Either)

            Там же где Option подходит, он заменяется успешно на nullable тип. (не везде, да бывают места где лучше оставить Option, но все же в большинстве случаев его можно заменить)
            • 0

              В Rust Option тип может быть любым. Т.е. обычно у тебя возвращает String, а в случае проблема некий Error тип с произвольным содержимым. Это довольно удобно. Здесь по всей видимости другая логика.

              • 0
                Ну я больше про Java, Scala, Kotlin… В Rust да, это немного другое.
              • 0
                В Rust Option тип может быть любым. Т.е. обычно у тебя возвращает String, а в случае проблема некий Error тип с произвольным содержимым.

                Нет, в раст Option<T> — это или конкретное значение T или ничего. Значение или ошибка — это Result<T, E>.

          • 0
            Но nullable типы в котлине не создавались для замены исключений, и использование их так, как описано в вашем примере, действительно плохо с точки зрения api метода, если информация о ошибке важна для пользователя.
            Nullable типы введены в язык, чтобы на уровне компилятора обнаруживать потенциальные NPE и выводить ошибку компиляции там, где в джаве это было бы NPE в рантайме. То есть использование nullable типов это тоже самое, что использование Optional, только на уровне синстаксиса языка.

            *нужно не забывать обновлять страницу перед отправкой коммента*
  • +1
    Чем больше таких статей, тем больше будет отталкивать этот новый язык. Такое, складывается, ощущение что он разработан лишь для коммерции и громкой рекламы.
    Если есть много, хорошо работающих проектов, врядли кто будет баловаться с ними ради моды и в угоду рекламы.
  • +11
    Гений дизайна тот, кто решил, что противоположные по смыслу модификаторы unmodifiable и modifiable должны определяться визуально сходными ключевыми словами var и val. Читабельность на высоте.
    • +1

      Противоположные по смыслу + и -, << и >>,… и да, это источник багов во всех современных ЯП.

    • +1
      Ну не знаю.
      var — variable
      val — value
      Интуитивно как-то понятно, что я для чего.

      пы Интуицию стоит проверить, но делать этого я, конечно, не буду=)
      • +9
        var — variable
        val — value

        Не, оно конечно понятно, почему названо так, но разница в 1 букву достаточно сильно снижает читаемость выражения.
        Например мне больше нравится вариант как в Swift, где let / var. Смысл не меняется, но отличить одно от другого несколько проще)
        • +2
          Это правда.
          Но, по крайней мере программируя на Scala, писать var приходится на столько редко, что можно считать что его просто нет.
    • +1
      Тут интереснее. Это для нас r и l различаются. Для китайцев, японцев, представителей многих других соседних народов — нет. Даже обучившись европейским языкам, они сохраняют эти проблемы ещё долго.
      Соответственно, использование языка будет давать им серьёзные проблемы там, где надо озвучивать код — при обучении, в рабочих дискуссиях… А так как тех же китайцев в США несть числа — ожидаю активное неприятие языка.
    • 0

      Вот это плюсану. l/r бесят

    • +2
      противоположные по смыслу модификаторы должны определяться визуально сходными ключевыми словами

      Вам поможет Skala, там точно не перепутаешь :)


      val -> unveränderliche
      var -> opportunistisch
      def -> verfahrensweise
      
      • +1
        Прочитал пост по ссылке, прифигел. А потом увидел дату публикации и расслабился :)
  • –3
    Компиляция в машинный код! Я так и думал, что виртуальную машину кронштадцы пустят под откос за вслед за паровозом. (В смысле кпд)
    Холивар явовцев зашкаливает :)
    • 0

      Эх, сколько уже таких "более лучших" Java/C# было...

      • –3
        А сколько было гуру Кобола и Алгола… И вот явовцы оказались в их положении. Что остается, как не злобствовать? Тем более, что бандерлогов греет мысль о том, что их стая велика.
        • –3

          Не оказались. JVM жила, живет и будет жить, и вместе с ней будет жить Java как "нативный" язык программирования JVM.


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

          • +1

            Go, CLR тоже качественные и эффективные рантаймы сборкой мусора

            • 0

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

              • –1

                А какие у .Net Core проблемы с быстродействием?

                  • 0

                    Там значения близкие во всех тестах кроме первых трех. Причем в первом тестируются возможности системных регулярок, которые разные по функциональности; во втором в коде на шарпе распаралелили не тот уровень вычислений (обратите внимание: в коде на Java создается отдельная задача для каждой комбинации offset/fragmentLength, а в коде на C# — только для каждого fragmentLength).


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

        • –2

          Java по сравнению с COBOL и Algol имеет много значимых улучшений, какие столь же значимые улучшения имеют все эти Kotlin, Groovy, Ceylon по сравнению с Java?

  • 0
    Удивил способ создания массивов — через builtines:
    intArrayOf(), longArrayOf(), arrayOf()
    Как то непривычно, интересно, почему именно так сделали?
    • +1
      Можно почитать здесь: https://discuss.kotlinlang.org/t/arrayof-unnatural/1637/41
      Основная мотивация в том, что если и вводить специальный синтаксис, то сразу для всех коллекций (array, list, map, set), а не только для массивов.
      Однажды добавив синтаксис его уже будет невозможно изменить не ломая обратную совместимость, поэтому не спешат.

      Насколько я понимаю, от специального синтаксиса не отказались, но пока не приняли окончательное решение.
      • 0
        Большое спасибо! Разумно так то…
  • –2
    Чем больше форсят что-либо, тем меньше мне хочется на это обращать внимание. Назойливость этого языка переходит вообще все границы.
  • 0
    По поводу Data Class, в оригинале было вот что:
    It’s a POJO complete with toString(), equals(),…
    А в переводе что-то пошло не так:
    Он наполнен POJO-объектами toString(), equals(),…
  • 0
    Плохую статью выбрали mail.ru для перевода…
    Про делегаты вообще не слова, как и про вариативность. Про coroutines так же ничего не сказано…

    Да и просто описание синтаксиса Kotlin сейчас уже не очень актуально, до этого и так было много статей по этому поводу.
  • 0
    На самом деле ограниченый лучший пример, приблизительно тоже самое можно и на Java написать, но без range.

    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")
    }
    


    Стоит для еще большей наглядности добавить например приведение типа.

    ...
    is Double -> print("x is Double")
    null -> print("x is null")
    "dummy" -> print("x is $x")
    


    BTW, добавьте в статью @JvmOverloads, ну и что операторы можно передавать в функции.

    В дополнение, мне кажется, что скоро с данного ресурса можно будет собрать стопку статей на перевод Kotlin Reference.
    • 0
      BTW, добавьте в статью @JvmOverloads, ну и что операторы можно передавать в функции.

      это перевод…

      В дополнение, мне кажется, что скоро с данного ресурса можно будет собрать стопку статей на перевод Kotlin Reference.

      Документация по Kotlin на русском
  • +1
    Я бы добавил ещё один небольшой плюсик Котлину, который, однако, скорее не его заслуга :)
    С Kotlin легко перейти на Swift и наоборот, что в теории может упростить для некоторых разработку под разные мобильные платформы.
  • –6
    Всё-таки смущает, что за языком стоит JetBrains. Это как если бы поставщик обедов для самолётов объявил о запуске своей линии самолётов на том основании, что давно связан с отраслью и хорошо её понимает. За C# стоит Microsoft, за джавой — оракл и понятно, что эти компании пилят компиляторы уже десятилетиями и никуда не денутся и через 20 лет. JetBrains, при всём уважении, пилит красивый текстовый редактор с рюшечками и откуда у них вдруг опыт разработки промышленного компилятора уровня «давайте выкинем Java нафиг» — не ясно. Вон даже Google вписывается в это всё очень осторожно, типа «да, есть такое, но это делаем не мы, а они, мы пока постоим в стороне и посмотрим как оно будет».
    • +5

      Как-то вы странно сравнили IDE для языка с обедом в самолете. В "самолетной" аналогии IDE — скорее корпус.

      • 0

        Скорее как терминал аэропорта — удобная и полезная фича, но не обязательная.

        • +1

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

          • 0

            Если IDE протупит с автодополнением — разработчик всегда может написать это руками, а вот если компилятор что-то не то накомпилирует, то тут уже туши свет.

          • 0
            > Так вот, разработчики IDE должны разбираться в языке едва ли не больше чем разработчики компилятора.

            Справедливости ради, это касается только фронтэнда компиляции — парсинга. Глубины оптимизации, JIT… — это уже не его части.
            Kotlin вполне соответствует этому — бэкэнды разные, но эта ниша занята собственно исполняющей VM в JRE, в Javascript машине… И поэтому я сомневаюсь в собственной native реализации — наверняка спихнут на LLVM :)
            • +3

              Так а зачем гадать? можно же просто взять и посмотреть в офф репозиторий. Там первым предложением в readme написано:


              Kotlin/Native is a LLVM backend for the Kotlin compiler, runtime implementation and native code generation facility using LLVM toolchain.

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

  • +1
    Это как если бы поставщик обедов для самолётов объявил о запуске своей линии самолётов на том основании, что давно связан с отраслью и хорошо её понимает

    Все же не очень корректное сравнение. Ближе будет что-то вроде этого: Создатели промышленных роботов для производства хорошо знакомы со многими отраслями, и решили открыть свою фабрику со своими роботами…

    У JetBrains большая экспертиза, есть огромное количество студий под самые разные языки. Им известны проблемы, которые есть в языках, а также все проблемы создания IDE под них. Очень показателен тут пример Scala, где под популярные макросы пишутся плагины для IDE, чтобы она их нормально понимала. Для Kotlin же планируется в будущем добавить метапрограммирование, которое будет позволять делать практически тоже самое что и макросы Scala, но только чтобы оно одновременно легко встраивалось в поддержку IDE.
    Поэтому они взяли лучшее что есть в других языках, добавили своих нововведений и получился Kotlin.

    За C# стоит Microsoft, за джавой — оракл и понятно, что эти компании пилят компиляторы уже десятилетиями и никуда не денутся и через 20 лет. JetBrains, при всём уважении, пилит красивый текстовый редактор с рюшечками и откуда у них вдруг опыт разработки промышленного компилятора уровня «давайте выкинем Java нафиг» — не ясно

    Kotlin запускается поверх JVM, Dalvik VM, и есть транслятор в Javascript (native также есть, но пока не в релизе). Java c JVM точно никуда не денется в обозримом будущем (уж очень много написано на ней и работает сейчас), а значит и Kotlin будет работать поверх JVM. Все новые версии почти сразу будут поддерживаться Kotlin, в том числе и скорая Java 9. Для Android Kotlin теперь поддерживается официально.
    Ну а web слишком быстро меняется =). Андрей Бреслав на одном из выступлений сказал, что они рассматривают возможность компилироваться в WebAssembly, как технология дозреет. Это так же дает уверенность что в web можно будет с уверенностью писать на Kotlin.
  • –1
    Всё супер! Очень привлекательно и скорее мы попробуем kotlin на новом/новых проектах. Но вот зачем надо было делать:
    fun build(title: String, width: Int = 800, height: Int = 600) {
        Frame(title, width, height)
    }
    

    вместо более привычного:
    fun build(String title, Int width = 800, Int height = 600) {
        Frame(title, width, height)
    }
    
    • +3

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


      А в объявлении переменных тип поставили вторым потому что это — необязательная часть. Необязательная часть объявления не может идти первой.

      • –2
        Необязательная часть объявления не может идти первой.

        Почему?
        • 0

          Потому что парсеры таких вещей писать не очень приятно.

          • –4
            По-моему это не очень аргумент. Мне как разработчику по идее должно быть до лампочки насколько сложно было писать парсер языка который я использую.
            И в чем сложность парсинга заключается, честно говоря, мне тоже не очень понятно.
            • +2

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

    • +1

      Kotlin весьма похож на упрощенную Scala:


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

      Наверное, оттуда и взяли.

      • 0
        поменяли def на fun :-)
    • +1

      Так удобнее парсить, так что почти во всех новых языках такой порядок объявления.

      • –1
        А раньше парсить было удобнее иначе? Или Томпсон, Ричи и их последователи — мазохисты?)
        • +3

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

    • +2
  • +4
    В русском переводе «полностью» звучит так, будто нужно вообще выкинуть Java и переписать всё на Kotlin. Слово «totally», особенно в выражении «you should totally...», чаще всего означает «определённо», «обязательно», а вовсе не «полностью».
    • 0
      Тоже бросилось в глаза. «определенно стоит», я бы так перевел.
  • 0

    Скажите, а с переходом на Kotlin придётся постоянно платить JetBrains'ам, или планируются альтернативные IDE?

    • +1
      Плагин так же есть под Eclipse и Netbeans. Да и не обязательно покупать Ultimate версию Intellij Idea, подойдет и Community.
      • 0

        Спасибо :)

  • 0
    Согласен с комментаторами про NIH. Не взлетит. Не нужен.
  • +2
    Хочу IDEA скомпилированную под LLVM написанную на Kotlin.
  • 0
    Почему следует полностью переходить на Kotlin

    потому что вам скучно и у вас полно свободного времени

    остальные пролистали статью, задались вопросами о рисках для бизнеса не найти разработчика или рисках для разработчика не найти работу, закрыли и забыли
    • 0
      Ну а многие уже давно пишут на Kotlin или только начинают писать.
  • –7
    Очень уважаю IntelliJ, но все эти надстройки над Java ( Scala, Kotlin ....)
    Пошла какая-то мода колхозить сверху языка какие-то скрипто-языки, которые транслируются в Java.
    Временное явление.
    Предпочитаю чистую Java.
    • +5
      Scala и Kotlin не транслируются в Java, а компилируются в байткод, собственно, как и сама Java. Т. е. они не «сверху», а «рядом»
  • 0
    Не много не по теме: с Java то более менее понятно, а на фронтенде кто то пробовал уже?
  • –3
    Мне кажется, что на современном этапе PR (хайп) и поддержка важных игроков рынка (Google, Pivotal) прежде всего для успеха очередного яызка. Scala это прекрасно, но тот факт, что ни IDEA ни Eclipse не могут корректно поправить импорты в проекте, когда один пакет перемещаешь в другой — реально отталкивает от использования Scala за пределами «домашних» проектов (этим плагинам уже много лет и так и не нашлось силы, которая бы развивала инструменты разработки для Scala). Все-таки для Kotlin ситуация выглядит более радужной (JetBrains, Android, Spring, Gradle — эти товарищи закомитились на поддержку Kotlin уже сейчас).
  • 0

    Native существует публично уже третий месяц, недавно мы выпустили v0.2. https://blog.jetbrains.com/kotlin/2017/05/kotlinnative-v0-2-is-out/

  • 0
    Я тоже подумал, кто если хочешь написать обзор на язык — напиши туториал. А хайпить язык простым перечислением его синтаксиса — не работает. От этого такое впечатление, что человек сам не разобрался, сам ничего на нем никогда не написал, а другим советует. Ну не катит такое, и все.

    (Никоим образом, конечно, это замечание не отностится к переводчику. Ему за труд спасибо.)
  • –2
    Возможно проглядел, и кто-то упомянул, но еще помимо всего прочего котлин может еще в и жабаскрипт фигачить =)
    https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-javascript/kotlin-to-javascript.html
    Так что он идеально подходить не только в андроиде, где он прост бесподобен, но и в веб-отрасли.
  • –6

    Это не новый язык программирования — это новая ява.

  • +5
    Только вот зачем этот неуместный мемчик с Дружко?
  • –5

    Похоже на какую-то помесь C# и Python


    Спойлер

  • –1
    Как Kotlin 100% совместим с Java, если оператор сравнения работает по разному?
    Пример из статьи:
    val john1 = Person("John")
    val john2 = Person("John")
    john1 == john2    // true  (structural equality)
    john1 === john2   // false (referential equality)
    
    • 0

      if и try-catch тоже по разному работают, а try-catch-finally вообще как конструкции языка нет. В данном контексте 100% совместимость с Java означает что в Kotlin нету таких конструкций, которые нельзя использовать из Java. В Scala такие конструкции есть, например path dependent types.

      • 0
        Продолжения и inline методы к таким конструкциям не относятся?
        • 0

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

          • 0
            Утверждается, что продолжения из java использовать не получится: https://stackoverflow.com/a/41561165.
            И inline не получится: https://stackoverflow.com/a/42742119. Что логично, учитывая реификацию.
            Мне импонирует ваша вера в то, что все так, как предполагается наиболее логичным, но, к сожалению, авторы Kotlin столкнулись с объективными трудностями, некоторые из которых разрешили ценой потери совместимости с java, в чем я их поддерживаю.
            Еще когда-то они считали, что nullable типы покрывают все аспекты взаимодействия с java кодом в плане nullability, но пришлось вводить «сырые» типы. Это не хорошо и не плохо, это объективная реальность с которой приходится считаться.
            Все на этом пути пожертвовали чем-то. И ceylon, и kolin, и scala. Стоит помнить чем именно они пожертвовали и ради чего.
            • 0

              Про овеществленные дженерик-параметры вы ничего не говорили, такие функции вызвать не получится.
              I want to believe как говорится :)

              • 0
                Это не единственная фича inline методов, требующая поддержки компилятором на вызывающей стороне. Насколько я помню inline методы из java не видны вообще.
                • 0

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

                  • +2
                    В любом случае тезис о 100% совместимости оказался не верен.
                    • 0

                      Жги, Господь, мы все про…
                      Может это модель такая — сначала быть совместимым, а потом добавлять плюшки ценой потери совместимости?

                      • –3
                        Это не модель даже, а путь джедаев. Встать на место могиканина. И повести за собой всё Java племя. Для начала: «я такой же как вы, только без хвоста». Я версия Явы. Но там уже забрезжил отказ от JVM и переход на нативный производительный код. Не совместимость, а сместимость. То есть взамен.
                        Не в белиберду jvm-кода, а нормально, как папа учил.
                        • +3

                          И кому нужна такая Java без библиотек, простите? В этой нише и так тесно: есть Rust, есть C++, есть Swift в конце-концов. Причем они все без GC.

                          • +1
                            Действительно, Rust популярен в последние годы. Это как раз показатель внутренней неудовлетворенности программистов как собственно жавой, так и распиаренного ООП. И язык Go от гугла в ту же степь. Возрождение процедурного подхода, обрезание наследования, борьба за производительность. Ну и удобный параллелизм — железо требует.
                            Наступление Котлин даже слишком быстрое и напористое по пиару. Это и пугает жабоводов. Ну как же — подошли к их тёпленькой кормушке!
                            • –1

                              Что-то лучше ООП пока что не придумали.


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

                              • +1

                                Придумали. Помните трех китов ООП? Котрые инкапсуляция, наследование и полиморфизм? Так вот, они устарели. Уже давно эксперты голосуют за агрегацию как основной инструмент повторного использования кода в ООП. Потом начали отказываться от концепции JavaBean — иммутабельные классы и чистые функции оказались выгодней.


                                Современный тренд — это композиция. Т.е. создание операторов, позволяющих естественным образом объединить два и более объектов или функций в один объект. Простейший пример — Stream API в джава, собирающий коллекцию и набор функций в новую коллекцию.


                                А Java, как язык, к сожалению, не очень хорошо подходит для композиции. Но я уверен, что в Java10 что-нибудь придумают.

                                • –1

                                  Насколько я вижу функциональное программирование дополняет ООП в некоторых местах (например удобно для обработки списков), если же мы хотим что-то моделировать, то тут ООП замены нет, поскольку оно ближе всего к реальному миру. Например наследование позволяет избавиться от копипейста и обеспечить абстракцию и SOLID — что его заменяет в функциональном программировании?

                                  • 0
                                    ФП — это слишком громко сказано :-). Чистое ФП достаточно сложно и в массы навряд ли пойдет.

                                    Насчет объектов и реального мира, вот цитата из классика:

                                    О проектировании иерархии классов говорили все, кому не лень — одни по делу, другие болтали «об имитации объектов реального мира».
                                    Jeff Alger, «C++ for real programmers»

                                    Проблемы копипаста в большинстве своем лучше решаются агрегацией.

                                    В чистом ФП нет наследования и поэтому понятие полиморфизма к нему неприменимо. Вместо него использутся лямбды и абстрактные типы. Например, если в классическом ООП у нас есть interface Colored { Color getColor(); }, то в ФП это будет выглядеть так:

                                    void drawColored <T>(T object, Function<T, Color> getColor) //getColor получает экземпляр T и возвращает его цвет
                                    • 0

                                      Не сказал бы, что это упрощает программирование с практической стороны.

                                    • +2
                                      В чистом ФП нет наследования и поэтому понятие полиморфизма к нему неприменимо.

                                      Применимо.


                                      в ФП это будет выглядеть так:

                                      class Colored a where
                                          getColor :: a -> Color
                              • –2
                                ООП — вообще не технология. Это коммерческий пиар в голом виде. Инкапсуляция — чисто для сокрытия кода. Поэтому появилась инкапсуляция без сокрытия. Какой в здравом уме программист предпочтёт скрывать код и использовать что-либо в виде черного ящика? Damn DLL Hell! А вот проблемы копирайта он замечательно решает. Именно с сокрытием.
                                С наследованием всё ясно — всё более и более обрезается и обрезается по факту с каждым свежим языком.
                                Полиморфизм никогда и не работал, как было заявлено в начале.
                                Объекты к объектам реального мира отношения не имеют никакого, а являются лишь структурой данных с присобаченным интерфейсом. Синтаксический обман.
                                И главное. Все объекты собраны в иерархии. Топологически -дерево. Это самая простая топология, которую можно вообразить для графа. Количество связей минимально — на 1 больше, чем элементов.
                                Элементы объектов реального мира связаны практически всегда намного большим количеством связей. Наличие обратных связей — колец основа кибернетики, о которой кодеры забыли от слова «совсем».
                                А почему так произошло? О потому, что царство ООП заменило алгоритмы, модели объектов реального мира на иерархии деревьев классов, нанизанных искуственным наследованием.

                                Да, Котлин «один из». Но уже помазанник Гугла.
                                • +2

                                  Ну так и какая же альтернатива? Обвешиваться "открытым кодом"-копипейстом? Код большинства библиотек и так открыт — всё равно никто не захочет использовать библиотеки, в которых придётся смотреть код. Черные ящики в мире на каждом шагу — никто не пользовался бы мобильным телефоном, если бы нужно было знать детали реализации команд процессора.


                                  помазанник Гугла

                                  А сколько даже своих собственных проектов Гугл уже закопал…

                                  • –2
                                    Пользоваться мобилкой — это про программистов или про пальцетычеров? Аргумент просто убийственный.
                                    Копипейст это как раз про нашёл в инете и скопипастил решение из библиотеки без включения головы.
                                    • +1
                                      программистов или про пальцетычеров

                                      Да хоть про разработчиков интегральных схем: один разрабатывает AC/DC, другой ALU, третий — RAM, четвёртый — IO, а потом всё это интегрируется. Без крайней необходимости никто не вникает в детали реализации чужих блоков.

    • +2

      От совместим точно так же, как совместимы C# и Visual Basic — на уровне сборок / библиотек классов.

  • 0
    А еще можно задавать многострочные строки, без плясок с бубном :)
    val string = """This is
    multiline
    string"""
    • 0

      На самом деле все-таки не совсем без плясок.
      Если важны отступы в строчках и одновременно хочется видеть красиво отформатированный код, то, насколько мне известно, сейчас нет способа это сделать в compile time. Вместо этого есть несколько костылей типого такого.
      Также, одновременное отключения экранирования в многострочных строках (на самом деле они не многострочные, а просто сырые) и поддержка интерполяции в них приводят к конструкции ${'$'}, когда нужно чтобы строка содержала $.

      • 0
        Но согласитесь, что всяко удобнее нежели чем как в Java. С интерполяцией, думается мне, можно попробовать попедалировать тему на предмет добавления, например, синтаксиса '''text''', а-ля HEREDOC/NOWDOC.
        Что же касается красивого форматирования при необходимости соблюдения отступов, то я слабо себе представляю, как такое можно по человечески реализовать. Если же вы вдруг знаете, где это реализовано, то поделитесь ссылочкой — с удовольствием поизучаю.
        • 0

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

        • –1

          Бесспорно, это в разы удобнее, чем в Java.
          Подобное поведение реализовано в Rust. Конечно, там тоже не все так гладко, так как \ в конце строки так же убирает и сам перевод строки, и если он нужен, приходится вручную добавлять \n. Но лично для меня такая реализация выглядит несколько более приятной.

  • 0
    Ох же эти изобретатели велосипедов. Каждый мечтает сделать своё.
    Вместо объединения усилий и создания действительно единого пространства для разработки всего и вся.
    • +3
      причина совсем не в этом. Даже если бы все сели вместе разрабатывать единый язык программирования в каменном веке, дискуссия длилась бы до сих пор. Потому проще сделать свое чем заставить кого-то поменять точку зрения.Это раз. И два, это то что не всегда измененение существующего продукта целесообразно. Некоторые вещи лучше оставлять как они есть.
  • +2

    Язык, может, и хорош.
    Но останавливает JetBrains.
    Нет ни одного релиза IDEA, где не было бы что-то сломано. Некоторые баги не фиксят годами.


    При этом я не вижу, чтобы они сами писали на Котлине. Отдельные проекты есть, тесты в IDEA, но это капля в море.

    • 0
      А что не капля в море?
      • 0

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

        • –2

          IDEA уже как бы давно написана

          • 0
            Как это противоречит моему комменту?

            Вот в 2013 году, например, я высказывал те же опасения
            https://habrahabr.ru/company/JetBrains/blog/168265/#comment_5825955

            За 4 года ничего не изменилось — язык сырой и сама IDEA его не использует.
        • 0
          Ну на самом деле они у себя его вовсю используют. Код на Kotlin в продакшене начал использоваться еще с начала его создания (вроде 2011) и у них же проходил боевую обкатку. Сейчас полностью на Kotlin написан сервис авторизации. В Rider фронтенд также полностью написан на Kotlin. Как минимум еще тесты пишутся также на Kotlin. В своем новом проекте они также используют Kotlin.

          Сам язык постепенно проникает в их проекты. Нет смысла все сразу переписывать на Kotlin, они для того и делали язык с осознанием того, чтобы он прекрасно дружил с большой кодовой базой на Java.
          • 0
            Заголовок статьи: «следует полностью переходить на Kotlin»
            Перейдем, как только все новые фичи в IDEA будут писать полностью на Kotlin :)
            • –1
              Вам бы пообщаться в живую с Андреем Бреславым, ну или посмотреть его выступления… зарядиться Kotlin'ом…

              А по поводу этой статьи, она мягко говоря не очень удачная, вместе с картинкой сверху. Больше смахивает на троллинг перехода на Kotlin.

              В Kotlin есть одно неоспоримое преимущество, с ним будет больше ежедневного «фана» (original: fun) чем в других языках =)
              • 0
                Да не смахивает, а прямо говорит: «хайподермик нидл фор фан».
              • 0
                «fun indended» (orig. pun indended)
                (сорри за каламбур про каламбур)
        • 0

          Говорят, что пишут GUI Rider-а на Kotlin.

  • 0
    Пишу на Java и Python, первая нереально радует производительностью, инструментами и бесконечным набором библиотек. Но в Джаве есть адский нереальный треш, который практически весь подлечен в Kotlin.

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

    Потом дата-классы. Поскольку возвращать множественные значения нельзя — приходится делать классы пачками. К каждому напиши геттеры/сеттеры/туСтринг/экваваленцию и т.д. Просто беда.

    Третья боль — это нулл-значения. Весь код утыкан просто бесконечными проверками, а если цепочка идёт a.b.c.d, то хоть на стенку лезь. И начинаются опять аннотации NotNull и т.д.

    Единственное, что не понравилось, Delphi-style объявления переменных — зачем оно так делать, непонятно. А в остальном прямо хочется попробовать Kotlin.
    • +3
      Delphi-style объявления переменных — зачем оно так делать, непонятно

      Это как раз понятно: так не будет неоднозначности, учитывая то, что указание типов не обязательно.


      Интересно есть ли какие-то аргументы против помимо "непривычности"...

    • 0
      Насчет возврата множественных значений — сущая правда. Есть еще альтернатива — передать в качестве параметров коллекцию, в которую запихнуть результат.
      • 0
        Во многих случаях я заворачиваю функцию в отдельный класс, она проставляет много-много полей, которые можно потом забрать геттером. Через коллекцию — на крайний случай, т.к. резко падает читаемость и удобство, ведь коллекцию нужно заранее создавать.

        Проблема во всём этом — множество ненужного мусора, который хоть и быстро собирается GC, но всё равно не бесплатный.

        По теме. Очень хочется лёгких классов в Java, наподобие структур в Си. Множество мелких классов с 40 байтам заголовка — Одна из самых прожорливых статей расходов по памяти.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка