company_banner

Kotlin 1.2: общий код для JVM и JavaScript

    Вчера компания JetBrains выпустила релиз Kotlin 1.2. Новая версия — большой шаг на пути к тому, чтобы сделать Kotlin наиболее удобным инструментом для разработки всех компонентов современного приложения.


    В версии Kotlin 1.1 мы официально выпустили поддержку JavaScript — возможность транслировать код на Kotlin в JS и выполнять его в браузере. В этой версии мы добавляем к этому возможность переиспользования кода между JVM и JavaScript. Теперь вы можете использовать одну и ту же реализацию бизнес-логики во всех компонентах вашего приложения — бэкэнде, фронтэнде в браузере и мобильном приложении под Android. Мы также работаем над библиотеками, которые в этом помогают — в частности, над кросс-платформенной библиотекой для сериализации.



    Kotlin 1.2 доступен из коробки в IntelliJ IDEA 2017.3, которая также выходит на этой неделе. Если вы используете Android Studio или более старую версию IntelliJ IDEA, вы можете обновиться при помощи диалога Tools | Kotlin | Configure Kotlin Plugin Updates.


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


    Мультиплатформенные проекты


    Мультиплатформенные проекты позволяют вам собрать все компоненты вашего приложения — бэкэнд, фронтэнд и Android-приложение — из общей базы кода. Такой проект состоит из общих модулей, которые содержат не зависящий от платформы код, а также платформенно-зависимых модулей, которые содержат код для конкретной платформы (JVM или JS) и могут использовать библиотеки этой платформы. Для того, чтобы вызывать платформенно-зависимый код из общего модуля, вы можете указывать ожидаемые (expect) декларации — декларации, для которых все платформенно-зависимые модули должны предоставить фактические (actual) реализации.



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


    Как уже упоминалось, мы также работаем над библиотеками, которые помогают переносить код в общие модули:


    • kotlin.test, которая входит в поставку Kotlin 1.2, позволяет вам запускать одни и те же тестовые классы под JVM и JS;
    • kotlinx.html поддерживает изоморфный рендеринг — использование одного и того же кода для генерации HTML на бэкэнде и в браузере;
    • kotlinx.serialization позволяет вам легко передавать объекты Kotlin между разными слоями вашего приложения, используя JSON или Protobuf в качестве форматов сериализации.

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


    Производительность компиляции


    В ходе работы над версией 1.2 мы вложили много усилий в то, чтобы сделать компиляцию быстрее. Мы уже достигли ускорения около 25% по сравнению с версией 1.1, и мы видим большой потенциал для дальнейших оптимизаций, которые мы планируем выпускать в обновлениях 1.2.x.


    На графике показана разница во времени компиляции двух больших проектов в JetBrains, использующих Kotlin:


    Другие улучшения языка и библиотеки


    Новая версия также включает менее существенные улучшения в языке и стандартной библиотеке:


    • Компактный синтаксис для передачи нескольких аргументов в аннотацию (литералы для массивов);
    • Поддержка модификатора lateinit для свойств верхнего уровня и локальных переменных, а также проверки того, было ли lateinit-свойство инициализировано;
    • Более умные смарт-касты и улучшение вывода типов в некоторых случаях;
    • Совместимость стандартной библиотеки с ограничениями на разбиение пакетов между jar-файлами, введёнными в Java 9;
    • Новый пакет kotlin.math в стандартной библиотеке;
    • Новые функции в стандартной библиотеке для работы с последовательностями и коллекциями, в том числе набор функций для разбиения коллекции или последовательности на (возможно перекрывающиеся) группы фиксированного размера.

    Более полную информацию об изменениях в языке и стандарной библиотеке можно найти в документе What's new in Kotlin 1.2.


    Kotlin во всём мире


    Со времени релиза Kotlin 1.1 в марте этого года распространение его использования по всему миру сильно расширилось. Кульминацией стала KotlinConf, наша первая конференция, которую мы провели в Сан-Франциско 2-3 ноября, и на которую приехало около 1200 наших пользователей. Вы можете посмотреть записи всех докладов на сайте конференциии.


    Kotlin также стал официально поддерживаемым языком для разработки под Android. Kotlin-плагин входит в комплект поставки Android Studio начиная с версии 3.0, а на сайте Android можно найти официальные примеры и стайл-гайд. Уже сейчас Kotlin используют более 17% проектов в Android Studio, в том числе многие приложения как самых ярких стартапов, так и компаний из списка Fortune 500.



    На стороне сервера состоялся релиз Spring Framework 5.0 с большим количеством фич по поддержке Kotlin, а vert.x официально поддерживает Kotlin начиная с релиза 3.4.0. Кроме того, поддержка билд-скриптов на Kotlin уже входит в комплект поставки Gradle, и проект Gradle Kotlin DSL уже близок к релизу 1.0.


    Количество строк кода в open-source репозиториях на GitHub превысило 25 миллионов. А на Stack Overflow Kotlin является одновременно одним из самых быстрорастущих и наименее нелюбимых языков.



    Рост сообществ вокруг Kotlin также производит впечатление. По всему миру существует более 100 групп пользователей Kotlin, а докладов про Kotlin столько, что мы с трудом справляемся их все отслеживать — но для тех, про которые мы знаем, карта даёт хорошее представление о том, насколько распространено использование Kotlin.



    Для тех, кто только начинает использовать Kotlin, доступно всё больше книг (в том числе наша собственная “Kotlin in Action”, которая уже переведена на русский, японский, китайский и португальский), онлайн-курсов, самоучителей и других ресурсов.


    Пообщаться с командой: вебинар и Ask Me Anything на реддите


    Чтобы рассказать вам больше о новом релизе, мы проведём вебинар о разработке мультиплатформенных проектов при помощи Kotlin 1.2 7 декабря, в 8 вечера по Москве. Не забудьте зарегистироваться; количество участников ограничено!


    Кроме того, наша команда проведёт AMA (Ask Me Anything, открытое интервью) на Kotlin Reddit 5 декабря. Мы начнём в 2 часа дня по Москве и будем отвечать на ваши вопросы в течение суток.


    Как обновиться


    Как всегда, попробовать Kotlin можно прямо в браузере, на сайте try.kotlinlang.org


    • В Maven, Gradle и npm: Укажите номер версии 1.2.0 для компилятора и стандартной библиотеки
    • В IntelliJ IDEA: Версия 2017.3 уже включает новый плагин; в более старых версиях обновите плагин до версии 1.2
    • В Android Studio: Установите плагин из диалога Settings | Plugins или обновитесь через Tools | Kotlin | Configure Kotlin Plugin Updates
    • Компилятор командной строки можно скачать со страницы релиза на GitHub.

    Совместимость: В Kotlin 1.2 язык и стандартная библиотека обратно совместимы (по модулю багов): код, который компилировался и работал в версиях 1.0 и 1.1, будет также работать в версии 1.2. Для того, чтобы большие команды могли переходить на новую версию постепенно, мы добавили опцию компилятора, которая отключает возможность использования новых фич языка и библиотеки. Информацию о возможных трудностях можно найти в документации.


    Хорошего вам Kotlin!

    JetBrains 389,34
    Компания
    Поделиться публикацией
    Похожие публикации
    Комментарии 26
    • 0
      Для проведения четкой грани, хотел бы спросить. Предлагается ли какое-то решение для сборки iOS-бандлов? Или подразумевается, что можно компилировать в JS, а дальше собирать через phonegap, cordova и т.п., для последующей работы через webview.
      • +2

        См. kotlin native.


        Как:


        It comprises a LLVM-based backend for the Kotlin compiler and a native implementation of the Kotlin runtime library

        И где:


        Kotlin/Native currently supports the following platforms:

        Windows (x86_64 only at the moment)
        Linux (x86_64, arm32, MIPS, MIPS little endian)
        MacOS (x86_64)
        iOS (arm64 only)
        Android (arm32 and arm64)
        WebAssembly (wasm32 only)
      • 0

        Кто-нибудь использует kotlin как заиену js в проде? Поделитесь опытом, как оно там? Js получается адекватный?

        • 0
          Тыкал несколько месяцев назад — адекватность в плане раздувания кода где-то на уровне babel. То есть ООП инициализируется максимально корректно со всякими defineProperty и т. д., есть немного специального кода для поддержки пакетов. Но сам алгоритм более-менее дословно преобразуется.

          Однако, у Kotlin есть пара особенностей:
          1) Что символы, что строки часто используют обёртки от Kotlin.
          2) Нет switch на уровне языка, when же всегда преобразуется в набор if. Не знаю, плохо ли это.
          • +2
            есть немного специального кода для поддержки пакетов

            Уже давно нет. Пакет — просто пустой объект JS, куда накидываются свойства.


            Что символы, что строки часто используют обёртки от Kotlin

            Не совсем. Строки точно никогда вообще не оборачиваются. Символы в ряде случаев оборачиваются, но тут есть нюанс: в JavaScript вообще нет понятия "символ", можно его представлять как строку из одного символа, можно как число. Но и в том и в другом случае нельзя отличить на рантайме символ от строки или числа. А если всё же хочется, приходится оборачивать.


            Нет switch на уровне языка, when же всегда преобразуется в набор if. Не знаю, плохо ли это.

            Как раз недавно пофиксили, см. KT-21160.

          • +2
            Тоже пробовали Kotlin. Код как после сборщика. По скорости немного медленнее, но это только на тестах и незаметно для пользователей. В принципе уже сейчас можно использовать для проектов. В планах попробовать Kotlin для nodejs на более серьезном проекте
          • 0
            Очень хотеть длинные числа в стандартной библиотеке… Ибо привязка к java.math.BigInteger и отсутствие условной компиляции в языке не позволяет держать одну кодовую базу для двух платформ. А между тем в JS я так и не встретил ни одной полной библиотеки для длинной арифметики — да, все умеют сложение-вычитание-умножение-деление, но как насчёт битовых операций? (конечно, их реализовывать очень легко, но хочется целостного решения, а не копаться в потрохах объектов)
            • +4

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


              Заводите тикет в баг-трекере, формулируйте спецификацию, пишите прототип. Котлин очень близко работает с сообществом, и многие фичи появиличь именно таким способом.


              PS Скорее всего длинная арифметика будет не в стандартной библиотеке, а в соопутствующей библиотеке kotlinx, так что имеет смысл писать сразу туда. Или вообще делать свою биюлиотеку.

              • +1

                Ещё вы можете компилировать Kotlin в JS не через Kotlin/JS, а через вот это, и использовать хоть BigInteger, хоть всякие локали, форматы, даты и т.п.

              • –2

                Вот мне интересно зачем? Отличных языков под JS полно, с точки зрения скорости разработки и надежности написанного ПО, ClojureScript, TypeScript, и т.д. если у вас очень большой SPA. В други случая зачем менять JS, имхо отличный язык — потому что простой.
                Под JVM для server side есть так же куча отличных языков Clojure, Scala, Groovy и т.д. которые несут новые концепции а не просто немного синтаксического сахара.
                Может кто-то объяснить, приведя хотя бы несколько существенных преимуществ над Java? Только без Null Safety, пожалуйста. А что-то действительно существенное.
                А так же что Kotlin дает для разработки front-end'a? Кроме возни и гемора с классами и как следствие тонн всяких конверторов JSON->Object и обратно?

                • +1
                  А так же что Kotlin дает для разработки front-end'a

                  То же, что node.js даёт для разработки бэкэнда, а именно — возможность писать всё на одном языке. Дальше обсуждать бессмысленно, потому что есть 1000 мнений на этот счёт. Но уже одно то, что node.js есть и собирает большое коммьюнити, говорит о том, что идея иметь один язык для всего, не так уж маргинальна.


                  Кроме возни и гемора с классами и как следствие тонн всяких конверторов JSON->Object и обратно

                  kotlinx.serialization всю возню берёт на себя, это должно упростить жизнь.

                  • 0

                    Вы вырвали фразу из контекста и прилепили к ней кажущееся очевидным, но по сути некорректный контраргумент.
                    Тот что однороднось font-end и back-end с точки зреция общего языка, Может Быт хорошей идеей это факт беспорный т.к. нужно знать только 1-н язык и можно использовать абстракции не доступные в JS но доступные в другом языке и т.д…
                    Но язык этот должен подходить и для front-end и для backend. Если вы будете использовать C++ или Go для фронта, то ничего кроме раздутых сроков и бюджета не получите, для подавляющего числа проектов, надесь понятно почему?
                    А тут получается что котлин и для бэка не очень, т.к. есть другие альтернативы и получше. Так и для фронта не очень, т.к. придется писать кучу ООП шного кода, вместо простого JS или аналогов.


                    Для начала вы ответьте на вопрос зачем использовать колтин для разработки back-end'a, если есть другие альтернативы и они полуше, на мой взгляд, т.к. не являются незначительным улучшеним ситаксиса Java, а потому вопрос с фронтом сам отпадет, хотя я его уже обосновал, через резульат который вы получите — кучу ООП гемора и увеличение сроков, как следствие.


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

                    • +2
                      Вы вырвали фразу из контекста и прилепили к ней кажущееся очевидным, но по сути некорректный контраргумент.

                      Контраргументов я не приводил. Ответил на вопрос "зачем Kotlin/JS", который является подмножеством заданного вопроса (по остальной части вопроса позиции не имею, поэтому оставил ответ другим комментаторам). Ответ таков: если кто-то считает Kotlin уместным на бэкэнде, то ему приятнее будет писать на Kotlin на фронтэнде (как раз аргументы в пользу этого я привёл).


                      Но язык этот должен подходить и для front-end и для backend. Если вы будете использовать C++ или Go для фронта, то ничего кроме раздутых сроков и бюджета не получите, для подавляющего числа проектов, надесь понятно почему

                      Нет, мне вовсе не понятно, почему. Особенно, если мы говорим об абстрактной задаче в вакууме. Для каких-то задач C++ или Go не подходят, очевидно, для каких-то подходят. На фронте задач разных хватает. Держу пари, что у ребят из какого-нибудь ONLYOFFICE задачи такие, для которой 90% существующей JS-экосистемы, с вебпаками и ангулярами не подходит. А ещё ведь есть игровые движки (ради которых, как я понял, и затевалась вся движуха с WebAssembly).


                      и для фронта не очень, т.к. придется писать кучу ООП шного кода, вместо простого JS или аналогов.

                      Ну тут я сильной позиции не имею. Можете ваши аргументы высказать, не стесняюсь. Сам имею опыт написания больших приложений на GWT и лично придерживаюсь непопулярной точки зрения, что GWT хорош, а Kotlin/JS — это своего рода GWT для Kotlin.


                      Для начала вы ответьте на вопрос зачем использовать колтин для разработки back-end'a, если есть другие альтернативы и они полуше

                      Я не могу ответить на этот вопрос. Кто использует Kotlin для бэка, тот на него уже, видимо, имеет какой-то ответ.


                      Возможно вы просто кроме Java ни на чем и не программировали

                      Программировал. На ABAP, 1С, C#, немного C — в прод, и на Nemerle, Scala, Haskell, Scheme — в стол.


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

                      Я так не считаю, где я про это сказал? Я вообще лично не против продолжать писать на Java, если надо. Не во всех задачах Kotlin, Scala или какой-нибудь Haskell добавляют существенной продуктивности разработчикам (а иногда, наоборот, лишь убивают её), так что надо прежде всего смотреть на задачу, которую вы решаете, на ваши реалии.

                      • –1
                        А тут получается что котлин и для бэка не очень, т.к. есть другие альтернативы и получше

                        С чего вы взяли что он для backend «не очень»? Про другие альтернативы, которые, как вы утверждаете, получше, можно долго спорить. Все сильно субъективно. Могу лишь посоветовать вам попробовать самому написать что-нибудь на Kotlin и решить для себя, плох он или хорош.
                        • –1
                          Так и для фронта не очень, т.к. придется писать кучу ООП шного кода, вместо простого JS или аналогов.

                          Вы не путаете Kotlin с Java 6? В Kotlin есть много других сущностей помимо классов и интерфейсов, на нем можно писать без всякого ООП.

                      • +6
                        Ну я даже не знаю… задавать вопрос «зачем» в комментариях к посту, в котором мы рассказываем о том, какое распространение получил Kotlin? Зачем же, интересно, люди из Google, Pivotal, Gradle и многих других компаний вкладывают столько ресурсов в поддержку технологии, которая несёт так мало новых концепций? Возможно, потому, что продуктивность работы программиста определяется не только тем, сколько новых концепций несёт в себе язык, которым он пользуется?

                        Про возможности Kotlin вы можете узнать в очень многих местах, начиная с официального сайта языка, и дальше вам уже решать, какие из этих возможностей вы считаете существенными.
                        • +3
                          Ну я даже не знаю… задавать вопрос «зачем» в комментариях к посту, в котором мы рассказываем о том, какое распространение получил Kotlin?

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


                          Я прочел всю спеку котлина, но ничего интересного не нашел, в Scala, Clojure больше возможностей и они позволяют намного проще писать ПО и надежнее. У них есть как минимум тоже что в котлине на 99%. Что тогда дает котлин? По вашим словам новые концепции это не важно, может быть в языке какие то старые концепции реализованы лучше? Я хочу понять, т.к. не нашел не одного преимущества.


                          У Google поддержка ограничивается Android, это и понятно, только здесь у котлина есть преимущество и только одно — Scala и Clojure имеют свой не маленький по размерам рантайм, что не позволяет их использовать в разработке под Андроид.

                          • +1
                            проще писать ПО

                            может быть короче? на Scala точно не проще
                            Что тогда дает котлин?

                            Простой и с Java-like синтаксисом код
                            • +2
                              Нет, вопрос-то задавать можно, конечно, просто я не знаю, как на него отвечать. Особенно трудно с утверждениями про то, что в Clojure есть на 99% то же, что в котлине — учитывая, насколько эти языки друг на друга не похожи.

                              Вот, например, поддержка nullability. Мы считаем, что это преимущество. Очень многие люди, которые используют Kotlin, тоже так считают. С вашей точки зрения, это преимуществом не является. Какого продолжения разговора вы ожидаете? Я мог бы называть вам другие фичи, которые на наш взгляд являются преимуществами, но не очень понимаю, зачем это делать, если вы уже с ними со всеми ознакомились и ничего хорошего в них не нашли.
                        • 0
                          Подскажите, пожалуйста, я ничего не путаю, текущее положение дел — до сих пор нужно подключать руками к проекту kotlin.js?

                          Ну, то есть, суммарно проект выглядит как-то так:

                          package org.jetbrains.foo
                          
                          expect class Foo(bar: String) {
                              fun frob()
                          }
                          
                          //////////////////////////////////////
                          import org.jetbrains.foo.Foo
                          
                          actual class Foo actual constructor(val bar: String) {
                              actual fun frob() {
                                  println("Frobbing the $bar")
                              }
                          }
                          
                          fun main(args: Array<String>) {
                              Foo("Hello").frob()
                          }
                          
                          //////////////////////////////
                          
                          <!DOCTYPE html>
                          <html lang="en">
                          <head>
                              <meta charset="UTF-8">
                              <title>Title</title>
                          </head>
                          <body>
                          
                          
                          <script type="text/javascript" src="kotlin.js"></script>
                          <script type="text/javascript" src="untitled-js.js"></script>
                          <script type="text/javascript" src="untitled-js.meta.js"></script>
                          </body>
                          </html>
                          • –1

                            Да. На всякий случай, чтобы предупредить возможные возмущения, что kotlin.js — огромная библиотека, дам эту ссылку. И третий элемент script не нужен — meta.js используется только компилятором. Кстати, это уже является во многом вашим выбором, но насколько мне известно, люди предпочитают проект на Kotlin/JS паковать с помощью webpack, с котором Kotlin совместим.

                            • 0
                              Никаких возмущений, я пишу бэкенды и радуюсь жизни :)

                              Извините, ещё один вопрос (не смог найти на kotlinlang.org/docs/tutorials/javascript/kotlin-to-javascript/kotlin-to-javascript.html ), а где вообще предполагается брать файл kotlin.js?

                              Я лично взял его из \.gradle\caches\modules-2\files-2.1\org.jetbrains.kotlin\kotlin-stdlib-js\1.2.0\bd74054944b9f4e8a8b290248ecb591dcf1810f4\kotlin-stdlib-js-1.2.0.jar!\kotlin.js, но уверен есть какой-то более простой путь.
                              • 0

                                Проще всего, пожалуй, включить DCE — он сам распакует и порежет kotlin.js. А так, можно всегда написать copy task в gradle, который вытащит kotlin.js из нужного артефакта. Где-то в документации была (устаревшее) руководство по этому поводу.

                                • 0

                                  Нашёл конкретную ссылку


                                  Правда, условие path.startsWith("META-INF/resources/") || !path.startsWith("META-INF/") надо убрать.

                              • –1
                                Нормально так DCE поудалял ненужного (в 10 раз) — с 1500 КБ до 140 КБ. Правда это пустой проект, но всё равно выглядит круто.

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

                            Самое читаемое