company_banner
1 марта в 18:46

Встречайте Kotlin 1.1: JavaScript, корутины и многое другое перевод

Мы рады представить вам Kotlin 1.1, новую версию языка программирования Kotlin.


Kotlin 1.1

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



Во-первых, поддержка JavaScript перестала быть экспериментальной. Доступны все возможности языка, значительная часть стандартной библиотеки и, конечно, возможность взаимодействовать с кодом на JavaScript. Теперь клиентскую часть приложения тоже можно мигрировать на Kotlin, причем нет необходимости отказываться от привычных библиотек и фреймворков, таких как React.


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


Подробнее об этих изменениях мы расскажем ниже. Среди других новшеств хочется отметить type aliases, bound callable references, destructuring in lambdas. Полный список интересных изменений можно найти на нашей страничке What's new (обратите внимание на запускаемые примеры!).


Корутины (Сопрограммы)


Корутины в Kotlin позволяют писать асинхронный код так же просто, как обычный — синхронный.


Асинхронного кода становится все больше, а писать его зачастую довольно сложно. Чтобы облегчить эту работу, мы добавили в Kotlin поддержку корутин на уровне языка с помощью всего одного примитива — suspending functions. Исполнение такихфункций может быть приостановлено без блокировки какого-либо потока и возобновлено позже. Причем контроль над логикой приостановки и возобновления исполнения полностью принадлежит автору библиотеки, что позволяет использовать корутины как легковесную замену потоков. Теперь вместо дорогой блокировки потока можно использовать почти бесплатную приостановку корутины.


В синтаксис языка добавилось очень мало (один модификатор), но библиотекам предоставляется огромный простор для деятельности. Например, в проекте kotlinx.coroutines мы уже реализовали поддержку Rx, CompletableFuture, NIO, JavaFx и Swing. Подобные библиотеки можно (и планируется) написать для Android и JavaScript. Даже конструкции, которые являются встроенными в других языках программирования, в Kotlin можно реализовать в библиотеке: например, generators/yield из Python, channels/select из Go или async/await из C#:


// runs the code in the background thread pool
fun asyncOverlay() = async(CommonPool) {
    // start two async operations
    val original = asyncLoadImage("original")
    val overlay = asyncLoadImage("overlay")
    // and then apply overlay to both results
    applyOverlay(original.await(), overlay.await())
}

// launches new coroutine in UI context
launch(UI) {
    // wait for async overlay to complete
    val image = asyncOverlay().await()
    // and then show it in UI
    showImage(image)
}

Подробности в документации


Важное замечание. Несмотря на все преимущества, которые дают корутины, их дизайн еще сравнительно молод. Поэтому требуется интенсивная проверка его на практике, чтобы появилась уверенность, что мы все сделали правильно. Поэтому в 1.1 корутины выходят под “экспериментальным” флажком. Мы предполагаем, что языковые конструкции вряд ли изменятся, однако в Kotlin 1.2 возможны изменения в API, связанном с корутинами.


Поддержка JavaScript


Как мы говорили выше, все возможности Kotlin теперь одинаково доступны как для JVM/Android, так и для JavaScript (кроме reflection, но мы работаем над этим). Это позволяет разрабатывать веб-приложение целиком на Kotlin, что мы успешно и делаем в некоторых продуктах внутри JetBrains. Мы планируем опубликовать соответствующую документацию и инструкции в ближайшее время.


В Kotlin для JavaScript поддерживаются динамические типы для взаимодействия с кодом на JavaScript. Для типизированного доступа к популярным библиотекам можно использовать ts2kt converter с заголовками из DefinitelyTyped.


Подробности в документации


Инструментарий


Мы стараемся выпускать новую функциональность, не касающуюся синтаксиса языка, в промежуточных релизах. Вот самое яркое, что появилось со времен Kotlin 1.0:


  • Плагины для всех основных IDE: IntelliJ IDEA, Android Studio, Eclipse и NetBeans
  • Инкрементальная компиляция в IntelliJ IDEA и Gradle
  • Плагины к компилятору для лучшей интеграции с Spring, JPA и Mockito (расширяемые классы по умолчанию и автоматическая генерация пустых конструкторов)
  • kapt — инструмент для обработки аннотаций
  • Проверки кода, специфичные для Android-проектов
  • И конечно в IDE добавилось много-много новых диагностик, проверок, квикфиксов, рефакторингов и улучшений в автодополнении

Но мы не останавливаемся и уже сейчас готовим улучшения в инструментарии для версий 1.1.х.


Первый год Kotlin: сообщество и распространение


Если коротко, то мы растем! Более 160 тысяч программистов использовали Kotlin за прошедший год. Число строк на Kotlin в опенсорсных проектах на Github выросло с 2.4 до 10 миллионов. В slack-канале Kotlin на момент релиза 1.0 было 1’400 человек — теперь 5'900. Каждую неделю по всему миру появляются новые митапы и юзер-группы, организованные активными членами сообщества. Публикуется всё больше новых книг и онлайн-курсов.


image


Kotlin примерно одинаково популярен среди server-side и Android разработчиков. В Spring Framework 5.0 появилась поддержка Kotlin, равно как и в vert.x 3.4. Gradle и TeamCity используют DSL на базе Kotlin для программирования сценариев сборки. Cписок всех основных Kotlin проектов и библиотек можно посмотреть на kotlin.link.


Большое количество всемирно известных компаний стали использовать Kotlin в продуктовом коде: Amazon Web Services, Pinterest, Coursera, Netflix, Uber, Square, Trello, Basecamp и многие-многие другие. Corda — распределенная система документооборота разработанная консорциумом известных банков (таких как Goldman Sachs, Wells Fargo, J.P. Morgan, Deutsche Bank, UBS, HSBC, BNP Paribas, Société Générale), с самого начала разрабатывалась на Kotlin. Kotlin используют и в российских компаниях — например, Avito, Рокетбанк и Aviasales.


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


Соберите свой Kotlin 1.1 Event


Релиз — хороший повод встретиться с другими пользователями Kotlin. Мы подготовили набор материалов, который поможет вам организовать такую встречу в своем городе: 23 марта мы будем транслировать живую встречу с представителями команды Kotlin, плюс вы можете получить сувениры и набор для Future Features Survey. Больше информации и форма регистрации здесь.


Что дальше


Для того, чтобы сделать Kotlin по-настоящему универсальным full-stack языком, мы продолжаем работать над языковой и инструментальной поддержкой компиляции общего кода сразу для нескольких платформ. Это позволит писать модули, код которых используется как на стороне клиента, так и на стороне сервера. Также мы продолжаем улучшать инструментарий и поддержку сторонних библиотек на JavaScript. Инкрементальная компиляция для JavaScript уже на подходе, мы ее выпустим в одной из версий 1.1.х.


Поддержка Java 9 появится к выходу официальной версии этой платформы (этим летом).


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


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


P.S. Распространение Kotlin на все основные платформы является для нас стратегическим направлением. Мы уже можем запускаться на серверах, десктопах, Android-устройствах и в браузерах. В обозримом будущем мы планируем охватить и “мир без виртуальных машин” и поддержать такие платформы как, например, iOS и встраиваемые системы. Сейчас в JetBrains над этим трудится прекрасная команда Kotlin Native, и мы надеемся показать что-то интересное в относительно скором времени.


Как попробовать


Как и всегда, можно попробовать Kotlin онлайн прямо в браузере: try.kotlinlang.org.
Maven/Gradle: Используйте 1.1.0 в качестве номера версии компилятора и стандартной библиотеки.
IntelliJ IDEA: в 2017.1 уже встроена поддержка Kotlin 1.1, в более ранних версии нужно просто обновить плагин до версии 1.1.
Android Studio: Установите или обновите плагин с помощью Plugin Manager.
Eclipse: новый плагин доступен в Marketplace.
Сommand-line компилятор можно взять с релизной странички на Github


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

Автор: @belovrv Andrey Breslav
JetBrains
рейтинг 257,17

Комментарии (81)

  • +3

    Ура! Отличный релиз, спасибо разработчикам и всей команде Kotlin!

  • +4
    Решил попробовать. http://try.kotlinlang.org/#/Examples/Canvas/Hello,%20Kotlin/Hello,%20Kotlin.kt
    Нажимаю запуск. Ни для какого типа сборки не работает. Выдает портянку ошибок.
    • 0
      Аналогично.
    • +1

      Конкретно этот пример работает для версии компилятора 1.0.6 (можно выбрать внизу вместо 1.1). Вероятная причина в том что Kotlin APIs для JavaScript слегка поменялись между 1.0 и 1.1. Примеры с переносимым кодом запускаются как на JVM, так и на JS под любой версией.

    • +3
      Примеры починили, спасибо что сообщили.
      • 0
        Перепроверил. Все окей.
  • +1

    Отдельное спасибо что добавляете фичи для любителей функционального программирования.

  • +1
    Мне не понятно, как вы собираетесь обеспечивать совместимость с Java новых версий, если там будут появляться аналогичные механизмы вашим нововведениям?
    • +5
      Мы очень внимательно следим за планами Java, и на данный момент нам неизвестно о том, чтобы там планировались бы какие-то фичи, которые бы как-то конфликтовали с существующими или новыми фичами котлина. В том, что появляются фичи, которые предоставляют синтаксический сахар, аналогичный существующим фичам Kotlin (например, слово var), проблемы нет никакой вообще — .class-файлы остаются такими же, как были, и мы остаёмся с ними совместимыми так же, как раньше.
  • 0
    Никто не подскажет, есть ли где-нибудь годная статья/видео о основах kotlin + android (в плане «что ставить/куда смотреть»)?
    • +1
      Вбейте на YouTube канал Devcolibri, у них видел
    • 0
      Getting started with Android and Kotlin: http://kotlinlang.org/docs/tutorials/kotlin-android.html
      Ещё есть канал на youtube, называется devcolibri
    • +1

      Недавно на хабре опубликовали серию видео уроков
      https://habrahabr.ru/post/321600/

  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      coroutines — ИМХО, намного лучше чем в .Net
      Я бы сам так же сделал =)

      А можете пояснить этот момент для несведующих? Я из документации не очень понял в чем, по сути, отличие между async\await из .NET

      • +1

        В документации не раскрыта вся суть. А суть в том, что корутины в Kotlin не привязаны ни к конкретным библиотеками, ни к конкретным типам. async/await из примера — это просто библиотечные функции, можно писать свои для различных фреймворков. И ещё — generate/yield — это тоже библиотечные функции, реализованные поверх того же механизма корутин. Подчеркну, что там нет никакой внутренней магии специально для разработчиков stdlib, кто угодно может написать свои реализации generate/yield и async/await.

      • НЛО прилетело и опубликовало эту надпись здесь
        • +1

          Судя по документации — нельзя вызвать suspendable из не suspendable (что в общем-то вполне очевидно). В своих примерах они вызывают все сначала через runBlocking, а внутри уже все suspendale. Вообще выглядит как абсолютно то же самое с другим синтаксисом — пулы и диспатчеры соответствуют пулам и шедулерам в .net. Deferred< T > -> Task< T >, но как раз из-за синтаксиса разница существенная.


          В целом выглядит так что с точки зрения синтаксиса в котлине асинхронщина будет в большинстве случаев удобнее в использовании (чему я как C# разработчик завидую). Плюс в C# есть одна проблема — асинхронные геттеры и сеттеры — ибо они в данный момент попросту невозможны, при этом есть entity framework у которого в lazy-loading активно используется блокирование.


          Но и у дотнета есть преимущество — все нужное лежит в базовой библиотеке, ну и разработчики асинхронщины могут изменить базовую библиотеку (т.к. это почти что одни и те же люди) чтобы эта самая асинхронщина нормально поддерживалась. То есть в дотнете есть Task и его используют все — как сами ms, так и разрабы сторонних библиотек. Также в дотнете к базовому классу Stream они приделали — Read/WriteAsync, а как будут менять стандартную библиотеку jetbrains?

          • НЛО прилетело и опубликовало эту надпись здесь
            • 0

              Похоже вы меня не поняли. Асинхронщина была и в дотнете еще до async/await. И когда в дотнете запилили новый паттерн асинхронности — таски, async/await то базовую библиотеку изменили — добавили методы которые возвращают Task. То есть пользоваться базовой библиотекой стало в кайф.
              В яве тоже есть non-blocking io. Но вот получается что новый асинхронный паттерн разрабатывают jetbrains, вследствие чего вопрос — как новый паттерн (suspendable) будет кореллировать с классами стандартной библиотеки?

              • 0

                Как раз одним из главных приоритетов при разработке корутин и была бесшовная интеграция с существующими библиотеками. В отличие от .NET, Kotlin не привязывает реализацию корутин к конкретным классам вроде Task. suspend-функцию можно написать для любой имеющейся библиотеки.

                • 0
                  Ну таск не таск, а кастомные Awaitable то же есть: await anything
    • 0
      Когда вы запилите LINQ и уже можно будет мигрировать .Net -> Kotlin не расставаясь с привычными фичами?

      Разрешите поинтересоваться, а для чего вы используете LINQ в C# и с каким именно его фичами вы не хотели бы расставаться?


      Работа с коллекциями в Kotlin на полную катушку через уже традиционные map/filter, по-моему даже удобнее чем любой SQL. Для доступа к базам данных и статическому формированию SQL-запросов есть пара активных библиотек, например Exposed одна из более экспериментальных.

      • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        Возможно имелся не просто LINQ, а деревья выражений?
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Без них как-то грустно :) Хотя с деструктурированием и кортежами в C#7 как-то уже и не сильно чешется на другие ЯП смотреть :D
    • –1
      2) Идем сюда — https://github.com/Microsoft/vs-threading. Потом смотрим JoinableTaskFactory — профит.
  • 0
    Уважаемые разработчики Kotlin-а, прошу ответить на следующие вопросы:

    Можно ли будет в обозримом будущем получать краткое описание методов прямо в IDEA без гугления.
    К примеру описание функций let, apply, also из сорцов не получить, а очень хочется.

    Откуда ts2kt сейчас (либо в будущем) будет брать nullability информацию из дескрипторов, которые этой информации лишены? Есть ли какая-то механика, либо будет организована работа только для дескрипторов с оной?

    Есть ли публичном доступе roadmap для KotlinJS?
    Чего можно ждать в обозримом будущем от KotlinJS?
    В частности интересует момент с Mixin-ами.
    Будет ли возможность помечать методы интерфейса как уже реализованные?

    Библиотека kotlin.js — 1Mb, планируется ли существенно сократить его размер?
    Возможен ли будет вариант, когда только нужная функциональность будет реализована напрямую в финальном js-файле? К примеру, чтобы Hello World не тянул за собой метровую зависимость, а все нужное содержал уже внутри.

    Спасибо.
    • +2
      Чего можно ждать в обозримом будущем от KotlinJS?

      Инкрементальной компиляции, минификации aka dead code elimination (так же известный под названием tree shaking, которое меня немного выбешивает), куча примеров кода, работающего с современными фреймворками (такими, как React) и документации. Это совсем ближайшее время, буквально несколько месяцев. Дальше пока не планировали (или по крайней мере, я не в курсе). Так же надеюсь, что будет время немного улучшить интероп, например, завести правильные external enum. Ещё есть пользователи, которые очень хотят генерацию микромодулей и ES6, мы держим это в голове, и активно обсуждаем, но конкретных сроков у нас сейчас нет.


      Ещё в Kotlin есть такой минус, что достаточно неудобно разрабатывать проект, в котором есть общая кодовая база между JS и JVM. Этот момент непосредственно к JS не относится, там больше по части общекомпиляторной работы и всякого тулинга. Я так понимаю, что мы над этим будем работать в ближайшее время, но по срокам пока непонятно, скорее всего, в обозримом будущем удастся выпустить common-модули в экспериментальном режиме.


      Будет ли возможность помечать методы интерфейса как уже реализованные?

      Не вполне понятно, что вы понимаете под этим. Можете пример из мира JS (и по возможности, пример деклараций в TS)?


      Библиотека kotlin.js — 1Mb, планируется ли существенно сократить его размер?

      Сократить — нет, подружить вывод компилятора с различными минификаторами или разбить на кусочки поменьше — возможно. Конечно, мы понимаем, что такая здоровенная библиотека — это плохо. Кстати, после uglify она где-то в 2 раза ужимается, а после gzip и того более.


      Возможен ли будет вариант, когда только нужная функциональность будет реализована напрямую в финальном js-файле? К примеру, чтобы Hello World не тянул за собой метровую зависимость, а все нужное содержал уже внутри.

      Зачем, если для этого есть стандартные инструменты? У нас в JetBrains для внутренних разработок успешно используют Kotlin в связке с webpack, Kotlin компилирует, webpack — пакует. Как-то нелогично тянуть в компилятор линковку. Есть какая-то небольшая вероятность, что мы захотим написать свой бандлер, но в ближайших обозримых планах ничего такого нет.

      • +2
        Не вполне понятно, что вы понимаете под этим. Можете пример из мира JS (и по возможности, пример деклараций в TS)?

        TS — https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/yfiles

        http://docs.yworks.com/yfileshtml/#/api/yfiles.collections.IEnumerable у которого всего один абстрактый метод, а все остальные реализованы, сейчас его можно только как абстракный класс, иначе с наследованием беда.

        И пример с http://docs.yworks.com/yfileshtml/#/api/yfiles.geometry.OrientedRectangle, у которого в дескрипторе всего 2 интерфейса, но оба из них частично реализованы.
      • 0
        подружить вывод компилятора с различными минификаторами или разбить на кусочки поменьше — возможно

        Есть ли в планах генерирование jsdoc для google closure compiller? Сейчас, без них, даже в режиме advanced gcc много не может выкинуть, видимо как раз из за того что не хватает информации о типах.

        • 0

          Да, такие планы есть.


          видимо как раз из за того что не хватает информации о типах.

          В том-то и беда, что "видимо". GCC достаточно плохо работает на stdlib Kotlin, и пока не вполне очевидно почему. Возможно, дело в типах, возможно, в чём-то другом. Это вопрос требует исследования, и мы планируем потратить на них какое-то время.

          • 0

            Приятно слышать :)


            Спасибо вам за вашу работу! Надеюсь что скоро увидим нормальные решения для разработки фронтэнда. Сейчас приходится запускать nodejs в виде подключаемой библиотеке к процессу явы, и запускать серверный рендеринг ангулара 2 (а со вчерашнего дня 4) в ней. Других решений для полноценных изоморфных приложений не смогли найти...


            Если появится full stack решение на котлине, это будет просто сказка.

    • +1
      Можно ли будет в обозримом будущем получать краткое описание методов прямо в IDEA без гугления.
      К примеру описание функций let, apply, also из сорцов не получить, а очень хочется.

      А в чем пробоема? "Quick Documentation" должен работать.


      Откуда ts2kt сейчас (либо в будущем) будет брать nullability информацию из дескрипторов, которые этой информации лишены?

      В декларациях на TypeScript такая информация может присутстовать, аля Type | null и конвертор это пользуется.

      • 0
        В декларациях на TypeScript такая информация может присутстовать, аля Type | null и конвертор это пользуется.

        Без такой информации в обычном случае получаем по сути неактуальные враперы?
      • +1
        А в чем пробоема? «Quick Documentation» должен работать.

        Кроме самой декларации там ничего не наблюдаю
        image
        • 0

          Не могли бы Вы создать issue с проектом на котором это повторяется и указанием версий IDEA и плагина.


          Спасибо!

          • 0
            KT-16609 — заработало, но с ошибкой
            • 0

              Спасибо

  • 0
    Извиняюсь, возможно оффтоп — в Киеве будет кто-то устраивать релиз-ивент?
  • 0
    *.gradle.kts файлы только с приходом нового gradle будут без проблем отображаться?
    На текущий момент плагин 1.1.0-beta-38-IJ2016.3-1 — последний кто kts файлы без проблем отображает.
    Все следующие жалуются на функции стандартных типов.
    • 0
      Да, это заработает в Gradle 3.5.
  • +1

    Какие преимущества есть у Kotlin по сравнению с TypeScript, чтобы ради них идти на такие жертвы?

    • +1
      А можете чуть подробнее сказать, под «жертвами» что вы подразумеваете?
      • 0

        (промахнулся)

      • +5

        Жертвы действительно есть:


        1. Компилятор (пока) работает на JVM, соответственно, чтобы полноценно компилироваться в JS, не хватит только node.js/webpack, нужно ещё ставить JVM. Для JS-разработчика, у которого стоит нода, но не стоит JVM, это может стать препятствием.
        2. У нас (пока) нет лоадера для webpack. Т.е. нужно настраивать gradle для компиляции Kotlin и webpack для всего остального. Это, конечно же, не касается пользователей какого-нибудь google closure compiler.
        3. Система типов Kotlin изначально проектировалась с прицелом на JVM, система типов TypeScript — с прицелом на JS. В итоге, не всегда Kotlin так же хорошо ложится на JS, как TypeScript. Например, в Kotlin поддерживается перегрузка функций по типу параметров, чего нет в JS (и следовательно, в TS). Таким образом, по умолчанию Kotlin при компиляции функций с параметрами дописывает к их названию некий суффикс, полученный страшным алгоритмом. Конечно, есть аннотация @JsName, которая позволяет явно задать имя функции в JS. Другой пример — отсутствие union types в нашей системе типов.
        4. Мы тащим с собой жирный рантайм (1,2 мб), и (пока) не умеем из него вырезать неиспользуемые части.
        5. Мы (пока) не умеем компилироваться инкрементально.

        Как видите, часть проблем здесь из разряда "пока не успели сделать" (в основном по тулингу, у нас 1.2 как раз будет на нём фокусироваться), а часть "ничего нельзя поделать". В первом случае надо подождать, во втором — мы пытаемся минимизировать боль от последствий.


        Если у кого-то есть что-то ещё добавить к списку — пожалуйста, отписывайтесь к комментам, мы будем рады перечисленные недостатки устранить.

        • НЛО прилетело и опубликовало эту надпись здесь
          • +1

            Разумеется, так сделать можно, и на первых порах мы возможно так и поступим. И тут придут апологеты TypeScript и начнут сравнивать размеры npm-пакетов. В перспективе, возможно, удастся скомпилировать kotlinc с помощью какого-нибудь AOT-компилятора или полностью вырезать из компилятора все зависимости от Java.

    • +2

      Я так понимаю, возможность писать на одном языке бэкэнд и фронт-энд для Android, iOS (скоро) и веба. TS компилируется только в JS. Конечно, можно TS на ноде гонять, но не всем подходит нода. Опять же, можно TS гонять на Cordova/React Native, но нативное приложение должно шустрее работать. Плюс синтаксические вкусности, которых нет в TS:


      • declaration site/use site variance;
      • нелокальные return-ы (например, можно взять и сделать return из вызывающей функции прямо из лямбды, переданной в функцию map);
      • смарткасты;
      • богатые возможности для построения DSL;
      • навороченные корутины

      Ну и не забывайте про тех пользователей, которые уже используют Kotlin на JVM, и хотят на нём же писать и веб-клиент (либо с нуля, либо переписать на нём имеющийся JS-клиент).


      В принципе, тот факт, что мы не сможем поспеть за TS в плане лёгкости интеропа и тулинга (да и TS уже банально прочно занял нишу), лично мне понятен. Мой персональный приоритет — это создание именно такого языка, который позволял бы легко бы писать fullstack-приложения. К сожалению, это пока не совсем так, но я надеюсь, мы движемся в правильном направлении и скоро Kotlin станет полноценным языком для fullstack-разработки.


      С другой стороны, мы не сможем перегнать TS, но нам есть, куда расти. Задачей к 1.1 было стабилизироваться, т.е. задизайнить минимальный набор необходимых фич, причём так, чтобы потом не ломать совместимость. Ну и конечно, пофиксить баги и реализовать недостающие языковые фичи, доступные в Kotlin JVM. Некоторыми вещами в интеропе пришлось пожертвовать (например, теми же строковыми enum-ами), но никто не мешает их сделать к следующим версиям языка.

      • 0
        Разработчики, разработчики никогда не меняются… GWT, Silverlight… :D
        • 0

          Насчёт Silverlight не знаю, а вот GWT я успешно использовал в production на протяжении трёх лет и очень был доволен. Но у GWT есть фатальный недостаток — он не понимает Kotlin. Хочу пояснить — я хорошо знаю JavaScript и вполне способен писать приложения на каком-нибудь Angular. Проблема в том, что я этого делать не хочу:


          1. Мне JavaScript банально меньше нравится.
          2. Язык — это не только сам язык, но и ещё целая куча технологий вокруг него — библиотеки, системы сборки, IDE, линтеры и т.п. Лично мне неприятно всё время переключать в голове контекст с одного на другое. Да и объём знаний там немаленький, пришлось кучу времени потратить, чтобы переключиться с Java на JavaScript. И собственно язык — это пара дней работы, вся остальная куча времени пришлась на ту самую пресловутую экосистему.
          • 0
            Просто история повторяется :)
            JavaScript без своей экосистемы — не очень вкусен. Постоянно поддерживать интеграцию с ней то же мало приятного. Позавчера Grunt, вчера Gulp, сейчас Webpack. Как быть с новыми фичами языка? Это все ограничивающие факторы. Для JS разве что TypeScript, ибо он хитрое надмножество. Но это в любом случае еще один уровень абстракции, за который надо платить.

            Я то же не любил JS. Потом смирился :) И с удовольствием использую его на фронте и C# в бэке. Поэтому если мне прижмет использовать redux-observable, я не буду ломать себе голову как мне это и интегрировать с какой-то абстракцией.

            Со стороны это похоже на попытку сделать универсальный инструмент для всего и всех. На текущем этапе жизни я уже в такое не верю :)
            • 0
              JavaScript без своей экосистемы — не очень вкусен.

              GWT прекрасно живёт в своей экосистеме. Сборка — Maven, хранилище артефактов — тот же maven central или jcenter, линтеры — checkstyle и PMD, библиотеки и фреймворки — специально написанные для GWT или портированные с "большой" Java, либо обёртки вокруг JS-ных библиотек. Минификацию делает сам (причём сильно лучше новомодных webpack-ов), модульность на уровне модулей Maven.


              Постоянно поддерживать интеграцию с ней то же мало приятного.

              Мне кажется, это утверждение из разряда "у страха глаза велики". Там достаточно много всего, но интегрироваться с этим не так сложно, есть вещи более-менее устоявшиеся. Ну и да, всё "быстро меняется" в восторженных статьях на Хабре, а весь мир по-прежнему сидит на jQuery.


              Со стороны это похоже на попытку сделать универсальный инструмент для всего и всех.

              Нет, это попытка сделать инструмент для тех, кто хочет fullstack на Kotlin. Кому нормально писать фронтэнд на JS, тот и дальше будет писать на JS.

              • 0
                Я не спорю, что сам в себе GWT хорошо живет для специфических проектов. WebForms в аспнете то же живут у кого-то. Проблема в том, что это изолированная часть веба и не всегда развивается вместе с ним.
                Тут все просто — Frontent разработчики используют React/NG2/Vue и тд. Зачем им GWT и подобные абстракции? Все и так отлично. Еще и WebAssembly завезли :D

                Вообще все давно изменилось :) И таки да, это геморой еще тот. Сам сталкивался с тайпингами в TS, когда он еще не развился до текущего уровня. И это с учетом, что он все таки близок к JS.

                Зачем? Если это будет сколько нибудь сложный UI — ну его в пень такой fullstack ;) Народ запаритесь искать и будете бороться с corner-case'ами.

                • 0
                  Тут все просто — Frontent разработчики используют React/NG2/Vue и тд. Зачем им GWT и подобные абстракции? Все и так отлично.

                  Во-первых, я же уже сказал — ИМХО, компилятор из Kotlin в JavaScript больше нужен Kotlin-разработчикам, которые захотели ещё писать фронтэнд, а не фронтэнд-разработчикам, которые уже счастливы с JS.


                  Во-вторых, если так мыслить, то вообще никогда ничего нового не будет появляться. В 80-е разработчики прекрасно жили с Cobol. А сейчас люди прекрасно сидят на Java, так что, теперь из этого следует, что Kotlin не нужен? Нет, оказалось, что на это есть какой-то спрос, нашлась ниша. Возможно, найдётся ниша для компилятора в JavaScript. Пока самая очевидная — это та, которую я назвал, но реальность как всегда такова, что выстрелить язык может там, где никто этого не ожидал. Глупо не попытаться использовать шанс, если он есть. Ведь хуже будет, если Scala.js выстрелит, в этом случае Kotlin придётся запрыгивать в уходящий поезд.


                  Еще и WebAssembly завезли

                  А это вообще мимо кассы. WebAssembly — это средство для бородатых дяденек, пишущих на C и C++ запускать свои шустрые программы в браузере. Мне кажется, пересечение с "традиционным" фронтэндом и всей его экосистемой — минимальное. Вот это отличный шанс туда запрыгнуть новым многообещающим языкам.

                  • 0
                    Очень специфичный кейс.

                    Компиляторы в JS отнюдь не новинка ;) Никто не говорит про то, что не надо развиваться. Вопрос в скоупе и необходимости тратить ресурсы на него. Если у Kotlin что-то получится — будет хорошо. Scala пусть со своим sbt разберется, перед тем как на js взлетать :)

                    https://github.com/kg/ilwasm :D
                  • +1
                    Мне кажется, пересечение с "традиционным" фронтэндом и всей его экосистемой — минимальное.

                    А мне кажется, что очень быстро зайдёт в "традиционный". Хотя бы просто как замена и(или) дополнение к минификаторам.

                    • 0

                      WebAssembly ещё очень далеко до того, чтобы на нём сделать полноценную реализацию движка JS. Сейчас там нет ни GC (и сложно сделать свой, т.к. нет доступа к стеку), ни вообще какого-либо способа пропатчить код в рантайме или повыставлять защиту страниц памяти.


                      По поводу эффективности бинарного формата в плане размера. Если интересно, у меня есть свой экспериментальный транслятор байт-кода Java в WebAssembly, вот работающий пример приложения. Так вот, размер JavaScript — 274 кб, размер WebAssembly — 488 кб.

                • –1
                  Если серверная часть написана на Java, то GWT вполне себе хороший выбор для клиентской части. Зачем тянуть React или Angular, тем более, что общего между ними почти что ничего?
    • +3
      По моему опыту никаких преимуществ нет. TS генерирует код, мало отличающийся от исходников, из внешних зависимостей — пара функций на 10 строк в сумме. Kotlin же тянет с собой мегабайтную библиотеку и в генерированном коде черт ногу сломит. Кроме того, TS на порядок проще. Так что пока выбор очевиден.
      • –1
        Kotlin же тянет с собой мегабайтную библиотеку

        Я же уже писал — мы постепенно решим эту проблему


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

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


        Далее, а зачем генерируемый год должен быть читаемым? Вы часто смотрите на машинный код, сгенерированный каким-нибудь gcc?


        Кроме того, TS на порядок проще.

        И про это можно подробнее? Опять же, хотя бы несколько пунктов.

        • 0
          Далее, а зачем генерируемый год должен быть читаемым?

          Для отладки непосредственно в среде исполнения (читай — браузере). Среда бросает исключение, например, и ссылается, как ни странно, на сгенерированный код, разве что source map есть и нормально подключился.

          • 0

            Вот мне кажется, что лучше уметь порождать точный source map, чем стремиться к 100% читаемости сгенерированного кода. А для тех случаев, если всё же пришлось подебажить сам сгенерированный код, мне кажется, Kotlin порождает достаточно читаемый код.

  • +3
    Почему методы Iterable (map/filter/drop/take и пр.) возвращают уже материализованный List? Почему не сделано как в C#? Получается, при написании цепочки действий, скажем map->filter->drop->take будет выделение памяти на каждом этапе?
    • +1
      В kotlin можно на любой коллекции вызвать asSequence и перейти к lazy вычислениям в map->filter и т.п.
    • +1

      Это было сделано из соображений удобства и производительности. Удобство в том что не нужно дополнительно звать коллектор в конце. Производительность проявляется в том что на маленьких коллекциях (до 10`000), которых большинство, локальность операций по памяти важнее чем выделение-освобождение списков.


      И как уже упомяналось, в любой момент можно перейти к ленивой семантике с asSequence() или даже к Java8-streams с asStream()

      • 0
        Ну теперь вместо одного коллектора нужно всегда дёргать asSequence+коллектор. 99% вызовов не единичны, а сразу пачка. Да и просто это не логично — Iterable предполагает, что это просто перечисление — и практически все методы у него материализующие. В C# IEnumerable возвращает IEnumerable.
        Что такое «локальность операций по памяти»?
    • 0
      Чтобы не было выделения памяти при промежуточных операциях можно/нужно использовать Sequence (однопоточный аналог Stream). Для него есть те же методы, но возвращают они тоже Sequence.
  • 0
    Книгу будете апдейтить?
    • 0
      Пока никаких договорённостей с издательством на этот счёт нет.
  • 0
    Это позволяет разрабатывать веб-приложение целиком на Kotlin

    В смысле фронт будет компилироваться в JS, а бэк в JVM? Или можно и бэк скомпилировать для запуска под нодой, чтобы JVM в продакшене не было?

    • 0

      Предполагается, что можно будет и так и так

  • +2
    Планируются ли какие-нибудь обучающие материалы для людей не из java мира? К примеру для тех, кто знает только js. Так сказать, с нуля и сразу Kotlin…
  • –2
    «Новый» тернарный оператор увидит свет в ближайших релизах?
    Либо if будет его заменой еще долго?

    P.S. Режут глаз места, где тернарник просится, а приходится писать if.
    • –1
      Поясню вопрос.

      Летом прошлого года вопрос о тернарном операторе был открыт.
      Андрей Бреслав на одной из встреч говорил о том, что в классическом виде (? и :) он в Котлин уже не попадет, а в каком виде он может войти и вообще войдет ли — вопрос открытый.

      Собственно хочется знать не закрыт ли этот вопрос окончательно.
  • –2
    Господи, что трудного я не понимаю в разработке дизайна потоков/корутин/фиберов?
    Что вы вокруг этой темы все скачете, развели тут бардак XD

    Неужели так сложно писать код вида:

    $base = new ThreadBase();
    $thread = new Thread(function () { ...some_code… });
    $base->run(thread, thread2,… threadn);
    $base->when(thread, thread2,… threadn)->done(function (req, res) {
    // some code
    });

    Ну то есть вот в такой нотации что не ясно то?

    То future() какой-то придумают, чтобы повесить событие и только потом сделать обычный синхронный запрос.
    То превратят синхронный в асинхронный, а потом наоборот, запутают всех и сидят типа гении, раз никто не понимает. То какие-то корутины, то еще что-то…

    В PHP симуляция потоков все ставит на свои места…
    Неужто так сложно относится к процессу многопоточности, как к чтению например данных с сервака?

    Кинули запрос, получили ответ, считали ответ, перевели из json-а в данные, работаем с полученными данными.

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

    Согласен, всегда писать на деферах — можно уехать крышей, но сообразить для них обертку и не велосипедить — это мужество нужно.
    Как по мне — цирк, блин.
    • +2

      Зря вы так...


      Проблемы с колбэками начинаются как минимум когда нужно сделать асинхронный цикл. На колбэках это будет выглядеть монструозно, посмотрите например сюда http://stackoverflow.com/a/4288992/3518724


      Разработчики котлина проделали огромную работу. Если я правильно понял, ничего подобного для корутин пока нет ни в одном другом языке. Их дизайн позволяет, например, не создавать объекты Future в середине асинхронных вычеслений (CompletableFuture в яве довольно тяжел). Если управление передается из одного suspend метода в другой, то CompletableFuture создаваться не будет, будет работать https://github.com/Kotlin/kotlin-coroutines/blob/master/kotlin-coroutines-informal.md#continuation-passing-style.


      Другой бонус — частиное решение проблемы красно/черных методов. Для того чтобы переписать какой то метод на асинхронный, в c#, dart и тд, нужно, по сути, переписать все методы которые его будут вызывать. В котлине их тоже придется доработать, но, насколько я понял, достаточно просто дописать модификатор suspend перед fun, и никаких async/await. https://github.com/Kotlin/kotlin-coroutines/blob/master/kotlin-coroutines-informal.md#asynchronous-programming-styles


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


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

      • +1

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

  • 0

    Здравствуйте, могли бы рассказать как вы сохраняйте интероп с java вводя корутины?
    Есть ли возможность вызвать suspend function из java?
    Как бы например выглядело использование buildSequence в java?
    В какой kotlin код транслирует ts2kt такие ts конструкции (intersection types, union types)?


    function extend<T, U>(first: T, second: U): T & U {...}
    function padLeft(value: string, padding: string | number) {...}
    • 0
      Для padLeft вероятно функция будет определена 2 раза с разным типом для параметра padding.

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

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