company_banner

Kotlin 1.0. Задай вопрос команде

    На этой неделе случилось важное для нас событие — вышла первая версия языка программирования Kotlin! Так как почти вся разработка Kotlin велась в Питерском офисе компании JetBrains, многие хабровчане уже знают, что такое Kotlin и пробовали его на практике, поэтому этот пост больше для комментариев: задавайте любые вопросы и команда Kotlin ответит. Мы онлайн!

    image


    Для тех, кто слышит о Kotlin впервые, а так же для затравки разговора, несколько фактов о Kotlin:
    • Kotlin — это “прагматичный” язык для JVM и Android, который мы в JetBrains написали, для того чтобы нам было на чем программировать ;)
    • Kotlin имеет ту же облаcть применимости, что и Javа, и совместим со всеми современными технологиями и инструментами:

    • Kotlin полностью совместим с Java. В смешанных проектах код на Kotlin может легко вызывать код на Java и наоборот. Соответственно, все существующие Java-библиотеки доступны из Kotlin.
    • В Kotlin нелегко получить Null Pointer Exception, потому что система типов исключает это.
    • Kotlin позволяет создавать функции-расширения для существующих классов. Поэтому стандартная библиотека не определяет свои классы коллекций, но предоставляет кучу удобных функций для работы с JDK коллекциями
    • Начиная с версии 1.0 мы гарантируем бинарную совместимость. Так что теперь можно ;)
    • Нас много! За январь Kotlin использовало больше 11 тысяч человек, из них 5 тысяч за последнюю неделю. Почти 2 тысячи человек общаются в нашем Slack-канале и помогают друг другу. Сейчас в команде Kotlin больше двадцати человек. В JetBrains написано около 500К строчек кода на Kotlin, более чем в десяти проектах, а в открытых репозиториях на GitHub (исключая наши) число строчек растет экспоненциально, и на момент релиза их уже больше двух миллионов:
      image
    • Мы планируем вскоре зарелизить поддержку JavaScript и Java 8
    • У нас есть своя онлайн-песочница: http://try.kotl.in В ней есть серия задачек Kotlin Koans, которые помогают освоиться с языком буквально за несколько часов. Действительно за несколько часов! Также у нас отличная документация на официальном сайте.
    • Мы открыты! Kotlin разрабатывается на GitHub, под лицензией Apache 2.0. Но самое главное, мы всегда внимательно прислушиваемся ко всему входящему фидбеку, так что теперь слово вам:
    JetBrains
    178,00
    Делаем эффективные инструменты для разработчиков
    Поделиться публикацией

    Комментарии 176

      0
      Спасибо за открытие темы.

      И первый вопрос для затравки: какие планы по улучшению быстродействия работы плагина Kotlin в Idea?

      Дело в том, что если в большом проекте добавить .kt файл, то IDE начинает просто очень медленно работать. Реакция code intelligence может достигать 10-ти секунд и более. Подсветка то слетает, то опять появляется ну и т.п.
        +2
        Скорее всего, вы столкнулись с проблемой, специфичной для вашего проекта — у нас довольно много больших проектов, содержащих .kt файлы, и мы такого поведения не наблюдаем. Чтобы понять, что в точности у вас происходит, вы можете прислать нам CPU snapshot: https://intellij-support.jetbrains.com/hc/en-us/articles/207241235-Reporting-performance-problems
        +1
        Молодцы! Успехов Вам!
          0
          Спасибо!
          –7
          1) Как в плане быстродействия по сравнению с Java и с каким-то нативным языком? Например Go
          2) Планируется ли нативная компиляция в будущем для работы без VM?
            +8
            1) Новедь! Это такой же компилируемый в jvm-байткод язык, как и Java...
              +5
              1) Если писать код, эквивалентный аналогичному коду на Java, то производительность почти ровно такая же. На данный момент нам неизвестно никаких существенных проблем с перформансом. Единственное заметное отличие от байткода Java — для выражений и параметров non-null типов у нас генерируется приличное количество проверок на null, но, по нашему опыту, они не особо что-то замедляют (кроме того, они отключаемы).

              Другое дело, что если использовать идиомы и стандартные функции Котлина, производительность может быть даже лучше. Например, разные map/filter не только заинлайнятся вместе с передаваемой лямбдой, но и создадут правильные коллекции с оптимальной capacity.

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

              2) Планируется.
                0
                Вот нативная компиляция была бы очень интересна!
                  +5
                  чем, если не секрет?
                  –1
                  А вас не посещала идея сделать транспилер в Go вместо нативного таргета?
                  У него очень приятный рантайм, но так себе язык — как и у всех ваших таргет-платформ.
                    +3
                    Мысль, кстати, очень интересная, надо подумать. Мы думали в основном про варианты LLVM либо генерации кода на C, но и в том, и в другом случае ребром встает вопрос garbage collection, который в Go как раз решен.
                      0
                      Это было бы очень круто, хотя я не очень уверен, что это будет сильно проще LLVM+свой GC.
                        +1
                        С LLVM главная проблема в том, что его не очень понятно как из Java использовать. Ну и свой GC, годный для использования в production — ни разу не маленькая задача.
                +7
                1) Go не более нативный язык, чем Java (и соответсвенно Kotlin). Просто у Java рантайм несколько побольше. Встроенные издержки на производительность у этих языков примерно одинаковые (рантайм проверки на null, index, GC, вызовы от интерфейсов). Поэтому при прочих равных у этих языков производительность должна быть примерно одинаковая. Хотя отстутсвие в Go наследования, и как следствие обычных вирутальных методов, делает его немного менее производительным (издержки на интерфейсный вызов несколько больше, чем на виртуальный), для тех случаев когда задачу можно решить через класcическое наследование. Ну и компиляторы для Java развиваются с конца 90-х, а Go относительно молодой язык. Поэтому я думаю, что на данный момент производительность Java (средне-статистическая), больше чем у Go. Хотя подтвердить это утверждение не могу: сравнение по производительности разных сред исполнения — довольно серьезная и большая задача, если подходить к ней серьезно, а не дилетантски.

                2) Java компилируется нативно на лету (aka JIT), c 1998 года. Примерно с этого же времени существуют и статические компиляторы в нативный код (aka AOT). Более того, Oracle делает тоже сейчас AOT.

                Что касается без VM, я сильно сомневаюсь, что Kotlin когда нибудь откажется от GC, а как только в рантаме языка есть GC — такой язык уже нельзя называть языком без VM. VM — это по сути управляемая среда исполнения, то есть просто очень умный рантайм и не более того. Как только в вашем языке есть GC и рантайм проверки, ваш язык становится управляемым так или иначе. Будет ли Kotlin делать свою VM — тоже врядли. Могут мигрировать на какую-нибудь другую (в приниципе они уже сейчас поддерживают две VM — JavaScript и Java) — это возможно. Но один и тот же язык в двух совершенно разных средах исполнения — это по сути два разных языка, потому что одна и таже программа на Kotlin не может всегда работать одинаково в двух разных средах исполнения (или приходиться пользоваться очень ограниченным подмножестом возможностей языка). В этом смысле Kotlin для JVM и Kotlin для JavaScript — это два разных языка, несмоторя на то, что некоторые куски кода могут работать одинаково и там, и там.
                  +2
                  Да забыл, написать. Из выше написанного следует, что Kotlin компилируется нативно уже сейчас, ничего планировать в этом смысле не надо.
                    0
                    Ну ты же понимаешь, что это на самом деле не совсем так. То, как Kotlin компилируется сейчас, например, не позволяет писать на котлине полностью нативные iOS-приложения. Компилировать его так, чтобы это было можно — это вполне интересная цель, которую вполне имеет смысл планировать.
                      0
                      Ну подождите немного — сделаем мы вам Kotlin для iOS, в котором можно писать совсем нативные приложения без ущерба для возможностей
                        0
                        И кстати мы открыты к сотрудничеству в этом плане :)
                        0
                        Ну и вы уже сейчас, как я понимаю, интегрируетесь с RoboVM, что вас там не устраивает?
                          +1
                          Как минимум может не устраивать то, что проект RoboVM закрыли.
                            0
                            Теперь, да. Но исходники ядра остались, то что умерло в недрах M$ легко дописывается силами и компетенцией JetBrains. Правда ядро RoboVM — это тоже еще тот piece of software: «я тебя слепила из того, что было». На доработку его до внятного состояния у самого RoboVM ушел бы не один год. Я поэтому и спросил, что не устраивало, но ответа не получил
                      0
                      Go не более нативный язык, чем Java (и соответсвенно Kotlin).

                      Гм. Ну, то есть посыл про то, что "VM — это по сути управляемая среда исполнения, то есть просто очень умный рантайм и не более того. " ясен. Н о утверждение, что Go и Java в этом плане мало чем отличаются имеет мало общего с реальностью.
                      Взять хотя бы необходимость установки рантайма в систему. Это даже не говоря о скорости запуска этого рантайма.
                        +2
                        Никто не застваляет вас ставить рантайм. Можно его таскать с собой (соврешенно легально). К тому же с компактными профилями для Java 8 размер этого рантайма становится совсем небольшим, начиная с 11MB на диске.

                        Что касается скорости запуска, то в нашей JVM есть оптимизатор запуска, который делает старт Java приложений практически мгновенным (сравнимым с запуском нативных приложений).
                          0
                          Что касается скорости запуска, то в нашей JVM есть оптимизатор запуска, который делает старт Java приложений практически мгновенным

                          Хм, звучит интересно, вроде бы.
                          Но из представленных там графиков можно сделать вывод, что конкретное приложение на Java может стартавать 5 секунд (что, вообще то, не очень быстро), вместо 20 секунд (что вообще за гранью).
                          И что оптимизированное приложение стартует сравнимо с каким то другим нативным приложением. Это, конечно показатель.
                            +1
                            Не просто с каким-то другим, а с реальным приложением с точно такой же функциональностью (читалка и показывалка RSS) написанная на С++.
                              0
                              5 секунд (что, вообще то, не очень быстро)

                              Возможно бенчи прводились на HDD и значительная доля времени ушла чтение кода с диска, а на SSD разница будет меньше.

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

                              Так же я хз как это с АОТ компиляцией согласуется, но опять же благодаря богатому рантайму можно делать такие вещи: Quasar.
                                0
                                5 секунд — это немного для богатого ГУЕвого приложения даже с SSD. Сколько у вас Office стартует или какая-нибудь Visual Studio? Я только что проверил — у меня офис с моего Macbook Air стартовал с SSD за 10 секунд.

                                Такие вещи как Quasar согласуются c AOT точно также, как и большинство других Java API — то есть легко.
                      +1
                      Планируете ли Вы помимо языка создание и поддержку инициативы вроде Typesafe по формированию стека технологий для наиболее актуальных задач на базе языка Kotlin?
                        +4
                        Нет, потому что это не нужно — Kotlin прекрасно использует любой существующий Java-стек. Мы экспериментируем с созданием отдельных фреймворков, которые оптимальным образом используют фичи языка, но пока что у нас нет ощущения, что есть потребность в создании полного альтернативного стека.
                          0
                          Если тема с компиляцией в разные платформы (JVM, JS, [iOS]..) не заглохнет, то будет необходимость в библиотеках отвязанных от конкретной платформы, чтобы на них можно было опирать свой код.
                            0
                            Какое-то количество кросс-платформенных библиотек нужно, но это совсем не весь стек. Тащить в браузер аналоги Spring и Hibernate решительно ни к чему.
                        0
                        moving forward the compiler will be backwards compatible and future versions of Kotlin must not break existing code.

                        вопрос:

                        гарантия вечной обратной совместимости, т.е. тоже самое что и в самой Java. Так ли это необходимо? Последствия известны на примере ущербных generics, устаревшего дизайна коллекций и не всегда удобной реализации лямбд и тд. многие могут сами добавить из наболевшего. Так ли это будет критично если раз в 10-15 лет эта самая обратная совместимость будет не соблюдаться для изменения языка в лучшую сторону? У нас уже есть Java с вечной обратной совместимостью, так ли нужно это теперь еще в Котлине?

                        Голосование тут показывает что большинству достаточно было бы обратной совместимости в пределах мажорного релиза.
                          +2
                          Мы не предполагаем, что обратная совместимость Kotlin неизбежно будет вечной. Вполне возможен вариант, что в какой-то момент выйдет Kotlin 2.0, который не будет полностью обратно совместимым с 1.x, так же, как Python 3 не полностью обратно совместим с Python 2.
                            0
                            и не всегда удобной реализации лямбд

                            А что с ними не так?
                          +1
                          1. Есть ли что-то такое, что хотелось реализовать в языке, но по тем или иным причинам от этого пришлось отказаться?
                          2. [trololo_mode]Kotlin — всего-лишь Java с более компактным синтаксисом. Переубедите?[/trololo_mode]
                            +3
                            1) Вот, что смог вспомнить, но это далеко не всё:

                            • self type, отказались, т.к. вредит Java-интеропу;
                            • reified generics, не придумали хорошего решения, и тоже Java-интероп;
                            • хотели сделать, чтобы '==' был по конвенции, а не доступен на чём угодно (если есть в скоупе функция equals, возможно экстеншн, то '==' вызывает её), а также интерфейс Hashable с функцией hashCode, но это было давно и сейчас уже звучит несколько забавно;
                            • была идея сделать все модификаторы аннотациями, не получилось;
                            • хотели сделать полную защиту от NPE и считать всё, что из Java, nullable. Это была долгая и поучительная история
                            • НЛО прилетело и опубликовало эту надпись здесь
                                0
                                А будут ли подробности "поучительной истории?" Как я понял, проблемы там были с несколькими вещами:
                                Наследование fun (foo: String?) vs fun (foo: String)
                                Шаблоны Array vs Array<String?> при получении/передаче в Java
                                Цепочка Java — Kotlin — Java

                                И при таких сценариях приходилось делать много костылей, чтобы заработало. (Поправьте пожалуйста, если что не так сказал). И поэтому решили от идеи все Nullable отказаться. Но вроде как один из основных сценариев — свой код пишем на Kotlin, библиотели берем Java (как видится мне, простому крестьянину-кодеру ). И при таком раскладе, лучше безопасность в большей части кода и явные костыли в небольшой части кода, чем "красиво и удобно" + внезапные грабли в рантайме (или яма с кольями, как повезет).
                                  0
                                  Одна из основных причин была в том, что писать на таком языке было неудобно, а читать его — неприятно. Повсюду вопросительные и восклицательные знаки, которые не очень-то помогают из-за того, что расставляются в основном, чтобы удовлетворить компилятор, а не чтобы корректно обработать случаи, когда выражение вычисляется в null. Особенно больно в случае дженериков: например, Map<String?, String?>?.
                                +2
                                Если отвечать на второй вопрос, то, конечно же, Kotlin отличается от Java не только синтаксисом. Например, поддержка nullability — это различие на уровне системы типов, а не синтаксиса. Фичи типа reified type parameters и delegated properties — отличия на уровне семантики. И это не говоря уже о поддержке трансляции Kotlin в JavaScript.
                                0
                                Мы планируем вскоре зарелизить поддержку JavaScript
                                — немного не понял данный пункт… Можно поподробнее?
                                  +2
                                  Есть компилятор Kotlin в JS, который еще не зарелижен, планируем зарелизить :)
                                    0
                                    Спасибо за ответ. Думаю, будет нужная штука :)
                                      0
                                      а как это будет выглядеть примерно? т.е. пишем UI логику страницы на котлине используя встроенные в js-kotlin runtime DOM объекты (document, window и тд.) потом скармливаешь компилятору — получаешь как в gwt минимизированный js файлик на выходе, который потом вставляешь в <script… страницы?

                                      Будет ли какой-то отладочный режим в IDEA, чтобы сразу без полной перекомпиляции посмотреть как этот котлин код на существующей html странице отработает?
                                        0
                                        потом скармливаешь компилятору — получаешь как в gwt минимизированный js файлик на выходе, который потом вставляешь в <script… страницы?

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

                                        Будет ли какой-то отладочный режим в IDEA, чтобы сразу без полной перекомпиляции посмотреть как этот код на существующей html странице отработает?

                                        Будет инкриментальная компиляция, которая перекомпилирует только нужные файлы.
                                    0
                                    При разработке JS target'а нода учитывается?
                                      +1
                                      Да, но это в основном влияет на библиотечную часть, а JS что на ноде что в браузере один и тот же.
                                        0
                                        а ES6/ES7?
                                          0
                                          Сейчас таргет только один — ES5, но мы, конечно же, следим за развитием ECMAScript и других смежных технологий.
                                            0
                                            А JSONNET это не таргет?
                                              0
                                              JSONNET скорее про сереиализацию/десериализацию и у нас пока нет планов по его специальной поддержке.
                                            +4
                                            Ребята, которые разрабатывают Scala.js экспериментировали с компиляцией в ES6. На текущий момент эти эксперименты показали, что скомпилированный в ES5 код работает быстрее. Для Kotlin, скорее всего, ситуация будет аналогична. К тому же, если использовать JavaScript как compilation target, то особого смысла в ES6/ES7 нет, там большинство нововведений — синтаксический сахар.
                                              0
                                              Мапы, сеты, генераторы, лямбды, промисы, символы, let, string templates по вашему это все сахар?
                                                +6
                                                Я не говорил, что все нововведения в новых версиях JS — это сахар. Я сказал, что большинство — это синтаксический сахар. То есть это конструкции, которые можно выразить и в ES5, и в ES6. Яркий пример сахара — лямбды. Но, к примеру, символы — это не сахар, потому что в ES5 их не выразишь имеющимися средствами языка.
                                                Обычное использование JS, и использование JS как compilation target — это совершенно разные вещи. Какая разница для компилятора, скомпилировать колбэк в обычную функцию, или в лямбду? Если бы лямбды работали быстрее, смысл был бы. Но на текущий момент ES6 работает медленнее, и у него худшая поддержка браузерами. Именно эту мысль я хотел донести.
                                                  0
                                                  Не смотря на то что таргет ES5 мы стараемся воспользоваться фичами которые есть в рантайме, если это дает какой-то выигрыш. Это например Map, Set, Symbol, методы которые появились только в после ES5.
                                          +3
                                          Будет ли что-то похоже на async/await из C#? Видел Kovenant, но это всего лишь промизы с потенциальной лапшой из колбэков.
                                            +4
                                            Да, планируется. Мы даже зарезервировали ключевые слова async и await. Правда, по поводу сроков и деталей реализации пока что сказать ничего не можем — фича еще не задизайнена.
                                            0
                                            Планируется ли написание более обширной документации покрывающей все аспекты языка? То, что есть сейчас на сайте хорошо для старта, но есть вещи, которые там найти нельзя совсем или они раскрыты очень слабо. И если это планируется, то когда ждать?
                                              +2
                                              Да, будет спецификация языка.

                                              Если какие-то вещи в документации имеет смысл раскрыть подробнее, это повод сообщить нам или исправить самим :) Сайт с документацией лежит на гитхабе
                                                +1
                                                Собственных планов по переработке документации на сайте у нас на данный момент нет. Если вы не можете найти там какую-то конкретную информацию, то это, конечно же, баг, о котором нам нужно рассказать, и мы добавим туда информацию. Мы также следим за вопросами от пользователей и дополняем документацию на сайте, если видим, что ответа на вопрос на сайте не найти, а нужно.

                                                Еще у нас есть книжка, в которой многие вещи объясняются более развернуто и с большим количеством примеров, чем на сайте.
                                                +1
                                                В прошлом году Jake Wharton назвал невозможность компилятора Kotlin запускать annotation processors (и использовать их с Java 'as is') большим сдерживающим фактором в использовании Kotlin для разработки под андроид.

                                                Что-то изменилось в этом плане с того времени?
                                                  +2
                                                  Я не знаю точно, что он имел ввиду, но сейчас annotation processors работают — я играюсь с проектом на Kotlin и Moxy, где все строится на аннотациях, полет нормальный.
                                                    +1
                                                    если вы про внутренний документ Джейка про Котлин, то с момента его написания (начало 2015 г.) прошло довольно много времени, за которое успел появиться kapt — сейчас ничего не мешает использовать, например Dagger 2 с Kotlin. Если есть вопросы, могу помочь
                                                      0
                                                      Справедливости ради, kapt все еще толком не переваривает DataBindings: https://youtrack.jetbrains.com/issue/KT-8007
                                                        +1
                                                        Конкретно сейчас проблема с data bindings вызвана только тем, что компилятор data bindings собран пререлизной версией котлина и падает с проектами, которые используют релизную версию. В следующем апдейте это будет исправлено.
                                                    0
                                                    У меня 2 вопроса.

                                                    1. Для андроида существует экспериментальный тулчейн. http://tools.android.com/tech-docs/jackandjill
                                                      Что Вы про него думаете? Задумывались ли Вы о возможности какой-либо интеграции с ним?

                                                    2. Время компиляции при работе с андроид проектами всегда была большой проблемой.
                                                      Планируются ли какие-нибудь оптимизации в этом направлении?
                                                      +1
                                                      1) Jack и Jill решают задачу генерации Dalvik-байткода напрямую из Java, минуя Java-байткод. Насколько я понимаю, нам никто не мешает самим генерировать Dalvik-байткод, и интегрироваться с Jack и Jill для этого не нужно и не факт, что полезно.

                                                      2) Мы сейчас заканчиваем работу над поддержкой инкрементальной компиляции для Gradle, которая позволит компилировать ровно те классы, которые затронуты изменениями после предыдущей компиляции.
                                                      0
                                                      У меня вопрос по поводу использования kapt и Android Annotations.
                                                      Сколько не пытался, так и не удалось их подружить, будет ли поддержка AA в дальнейшем?
                                                        0
                                                        Android Annotations должны штатно работать с использованием kapt. Если что-то не в порядке, создайте, пожалуйста, баг в нашем трекере https://youtrack.jetbrains.com/issues/KT
                                                        +1
                                                        Есть такой вопрос: планируете что-нибудь для метапрограммирования, более мощное, чем annotation processing javac'а? Например, что-нибудь из разряда Groovy AST.
                                                          +2
                                                          Пока что более-менее серьезно обсуждались только expression trees как в C# 3.0. Конкретных решений пока никаких не принимали, будем смотреть на фидбэк и юзкейзы.
                                                          0
                                                          Замечательный язык, очень интересна история появления — чем вдохновлялись, почему реишили создать. Если встает необходимость покодить что-то под жвм — сразу расчехляю котлин.
                                                            +3
                                                            Решили создать по простой причине: заметили, что у нас есть IDE для такого количества прекрасных языков, а сами мы почему-то пишем все время на Java и не видим убедительной альтернативы. Ну и из предыдущего опыта было известно, что если нам самим не хватает какого-то инструмента, то с большой вероятностью он также окажется востребованным на рынке.

                                                            Вдохновлялись — да всем, что вокруг существует. C#, Groovy, Scala, в отдельных местах Python и Ruby, иногда более экзотические языки типа Gosu.
                                                            +3
                                                            У меня вопросы не по технической части:

                                                            • Google как-нибудь реагировал во время разработки языка и на его релиз?
                                                            • Планируется ли от них какая-нибудь официальная поддержка? У JetBrains, вроде как, имеется опыт работы с ними.
                                                              0
                                                              Сложно до конца честно ответить на этот вопрос. Предлагаю вернуться к нему где-то через год.
                                                                0
                                                                Про одну реакцию Google можно рассказать вполне честно: кусок компилятора data bindings в Android SDK написан на котлине.
                                                                Вот еще одна реакция: developer evangelist из гугла пишет про котлин с дисклеймером, что это не отражает мнение его работодателя. https://medium.com/@CodingDoug/kotlin-android-a-brass-tacks-experiment-part-1-3e5028491bcc#.dx2f41ebm

                                                                А вообще, прежде чем можно будет всерьез говорить об официальной поддержке, нужно проделать еще очень много работы с нашей стороны. Мы стараемся. :)
                                                                  +3
                                                                  Ну, бывает пишут о нем в своем твиттере.


                                                                  И даже увидели, что Google во внутрях кое-где использует.

                                                                  0
                                                                  Не сильно всматривался в Kotlin. Вопрос простой: почему стоит выбрать Kotlin, а не Scala?
                                                                  Будет ли в Kotlin компилятор встроенная фича как в Scala dotty по выпиливанию ненужного кода?
                                                                    +3
                                                                    На сайте Kotlin есть сравнение, где сказано, что если вы счастливы со Scala, то Kotlin вам не нужен. Основное различие состоит в том, что Kotlin позиционирует себя как better Java, а у Scala все же своя парадигма и идеология.

                                                                    В самом Scala dotty тулзы по выпиливанию кода не будет. Будет тулза linker поверх компилятора, разработкой которой занимается хабраюзер darkdimius. И выпиливание ненужного кода — это лишь часть работы, которую linker делает. Он также оптимизирует (ан)боксинг примитивных типов и value-классов. Кроме того ожидается оптимизация создания быстроумирающих объектов в off-heap.
                                                                      +2
                                                                      Реклама Scala в треде про Kotlin) Обожаю Scala сообщество.
                                                                    +2
                                                                    1) idea-плагин может брать версию и рантайм котлина из описания maven-плагина в pom файле? Сейчас котлин конфигурируется в двух местах — в pom и в библиотеках модуля в проекте?

                                                                    2) почему final val в object не транслируется в public static final field у ява-класса? приходится использовать «class.INSTANCE.val()» конструкцию.

                                                                    3) lombok @Slf4j не работает… должен ли? или жаловаться разработчику?

                                                                    4) dynamic — насколько он реально был востребован?
                                                                      0
                                                                      1) Если у вас Maven-проект, то отдельно настраивать версию библиотеки Kotlin в проекте не нужно, при импорте из Maven все само настроится. Но при этом очень желательно, чтобы версия Kotlin, на которую вы ссылаетесь в pom.xml, совпадала с версией плагина, который установлен в IDE — а эта версия не может быть разной для разных проектов.

                                                                      2) Транслируется, если пометить его аннотацией @JvmField.

                                                                      3) Скорее не должен. У нас есть механизм по поддержке annotation processors, через который в принципе может работать Lombok, но он пока интегрирован только в Gradle-билды и не интегрирован в Maven. Ну и казалось бы, что встроенные фичи Kotlin делают примерно весь Lombok ненужным.

                                                                      4) Очень сложно говорить о востребованности каких-то фич JS-таргета, пока он существует только в экспериментальном виде. Просто нет столько кода, который мог бы их использовать, чтобы можно было делать какие-то выводы.
                                                                        +1
                                                                        «Ну и казалось бы, что встроенные фичи Kotlin делают примерно весь Lombok ненужным.»

                                                                        3) а как развернуть @Slf4j в kotlin-way? у меня получается только через companion object c @JvmField полем, примерно так (по памяти):

                                                                        companion object {
                                                                        JvmField
                                                                        final val logger = LoggerFactory.getLogger(Klass::class.java)
                                                                        }

                                                                        и приходится следить, чтоб имя класса соответствовало. да и лишние 4 строчки. Несравнимо с @Slf4j из ломбока. Приходилось есть кактус.

                                                                        5) И ещё момент со спрингом. Если у поля есть Inject, то поле проинициализируется до начала работы бина. То есть оно точно будет не null. Но приходится делать его nullable и каждый раз писать "!." при обращении к методам. Можно ли как-то сделать красиво — чтоб поле было не nullable, но и инициализации его при объявлении не было? Вариант с Inject в конструкторе не всегда удобно. То же самое с Mock полями в тестах. Понятно, что это не по-котлиновски. Но вдруг есть workaround от авторов.
                                                                          0
                                                                          3) Я бы просто завел private val logger = LoggerFactory.getLogger(Klass::class.java) на уровне файла. Если сделать хелперную функцию, можно сократить это до private val logger = getLogger()

                                                                          5) Для решения этой проблемы у нас придуман модификатор lateinit.
                                                                            0
                                                                            Поправка форматирования: private val logger = getLogger<Klass>()
                                                                              0
                                                                              внутренний голос убеждает, что такому полю следует быть final static transient. этого и добивался.
                                                                              жаль, что никак. ну ок

                                                                                0
                                                                                Почему никак? final static оно будет само. Если вам вдруг зачем-то надо сериализовать фасадный класс (класс, в который помещаются декларации, находящиеся на уровне файла), вы можете повесить на него аннотацию Transient.
                                                                                  0
                                                                                  ясно, спасиб. есть ещё пара вопросов. спрошу отдельно
                                                                      +2
                                                                      1) Насколько вы думали про JavaScript при разработке стандартной библиотеки? На первый взгляд кажется, что вся стандартная библиотека Kotlin это обёртка вокруг стандартной библиотеки Java и её особенностей.

                                                                      2) Насколько сложно будет писать код, переносимый между JVM и JavaScript? Опять же вопрос касается в том числе библиотек, ведь легко явно или неявно притянуть JVM. Будет ли некое подмножество «pure-Kotlin», на котором будет желательно писать библиотеки, чтобы они были «кросс-платформенными»? В идеале статически проверяемое.

                                                                      3) Будет ли dynamic доступен в Java? На первый взгляд я не понимаю, почему он не доступен, через reflection ведь всё можно сделать и изредка это было бы очень удобно. Кажется в C# есть такая фича.

                                                                      4) Одно время у вас были string templates с возможностью передавать все аргументы в функцию. Потом вроде убрали (или оно и не было сделано, не помню). Планируете ли аналог Scala-синтаксиса: sql«insert into test (a, b) values ($a, $b)»? Чтобы аргументы и их типы передавались в функцию sql и тд?

                                                                      5) Есть ли некий список того, что вероятно будет добавлено в обозримом будущем?
                                                                        +1
                                                                        1) и 2) оставлю коллегам, которые занимаются JS и стандартной библиотекой. Со своей стороны скажу, что все будет хорошо. :)

                                                                        3) dynamic для Java сделать можно, но это очень дорогая фича: во-первых, она сама по себе требует довольно много работы по дизайну и реализации, и во-вторых, про нее нужно все время помнить при дизайне и реализации всех остальных фич ("а что если в этом месте стоит dynamic?"). Кроме того, мы знаем, что в C# dynamic оказался намного менее востребованным, чем ожидалось. Поэтому — да, возможно, в какой-то момент мы увидим востребованные юз-кейзы, которые с dynamic решаются намного лучше, чем без него, и-таки его добавим. Но это точно не приоритет на данный момент.

                                                                        4) Таких string templates у нас никогда не было, если я ничего не путаю. Ровно такой синтаксис, как в Scala, мы в 1.0 зарезервировали на будущее, и с большой вероятностью в какой-то момент поддержим.

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

                                                                          2) Политика сейчас такая, что практически все фичи языка должны работать на обоих платформах и иметь одинаковую семантику, по модулю некоторых особенностей платформы, например работа с примитивами или реализация регулярных выражений.
                                                                          0
                                                                          Будет ли поддержка подсветки синтаксиса языа в текстовом редакторе Atom?
                                                                            0
                                                                            Сделать такую подсветку — это несколько часов работы максимум, так что кто-нибудь когда-нибудь наверняка сделает. Мы сами этим заниматься не планируем.
                                                                              +1
                                                                              Кто-то уже постарался — https://atom.io/packages/language-kotlin
                                                                              0
                                                                              когда допишется книга Дмитрия и Светланы?
                                                                                0
                                                                                Опыт показывает, что обещать какие-то конкретные сроки — плохая идея. :) Как только, так сразу. 7 глава вот-вот появится в MEAP, две следующих уже почти готовы.
                                                                                0
                                                                                когда допишется книга Дмитрия и Светланы?
                                                                                  0
                                                                                  в ява-файле в контекстном меню была опция похожая на «suppress unused warning for class annotated with @тутимяаннотации », например для аннотации Controller. возможно в котлин-плагин такую фичу запилить для классов и методов?
                                                                                    0
                                                                                    Сделаем, да. Голосуйте за https://youtrack.jetbrains.com/issue/KT-9276
                                                                                      0
                                                                                      Пока что можно на unused классе нажать Alt+Enter -> Edit inspection profile setting -> Configure annotations и добавить туда нужную аннотацию, класс должен перестать быть unused
                                                                                      +2
                                                                                      Почему значение функции не определяется ее последним выражением как в Scala, а требуется специальный оператор return, как в старых языках?
                                                                                        +3
                                                                                        По-моему вы троллите.
                                                                                        Haskell появился где-то в середине восьмидесятых — начале девяностых прошлого века, а вы в две тысячи шестнадцатом говорите об отсутствии «return» как о признаке «новизны». Не говоря уже о том, что корни такой нотации растут из записи математических формул.

                                                                                        IMHO неиспользование return можно оправдать только нестерпимым желанием прострелить себе ногу.
                                                                                          +1
                                                                                          Haskell, *ML, Lisp все-таки редкие языки. Языки, не требующие специального оператора, стали получать распространение сравнительно недавно.
                                                                                          Неиспользование return способствует использованию коротких понятных функций и улудшает читабельность и провторное использование кода.

                                                                                          Как отказ от return помогает "прострелить себе ногу"? По моему наоборот, привычка его использовать может вести к неожиданным эффектам.
                                                                                            0
                                                                                            В котлине есть нотация для "коротких понятных функций" без использования return:

                                                                                            fun summ(a: Int, b: Int) = a + b

                                                                                            Присоединюсь к Maccimo во мнении что для всего что длиннее одной строки return нужен.
                                                                                              +2
                                                                                              Можете пример дать? У меня, честно говоря, фантазии не хватает придумать такой кейс, когда бы return понадобился во имя безопасности. По личному опыту с изучением и дальнейшей работой со scala адаптация прошла почти мгновенно и проблем не было за все время (скорее только вздох облегчения).
                                                                                                0
                                                                                                много точек выхода в разных местах усложняют анализ и поддержку кода:
                                                                                                http://stackoverflow.com/a/733858/365675

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

                                                                                                    ну а негатив все же небольшой можно упомянуть — если только при неправильных аргументах первой строчкой удобней через return выйти для улучшения читабельности, на SO там это обсуждается.
                                                                                                +3
                                                                                                Два разных синтаксиса для функций, IMHO, излишество.
                                                                                                А в чем польза от return? Лично мне он только мешает. Сталкивался со многими его адептами, но полезности мне так ни кто и не объяснил. Доходило до того, что допускали его только последним оператором функции, но само слово все равно считали необходимым. Мне интересно узнать почему, особенно от дизайнеров языка.
                                                                                          +2
                                                                                          1) Очень не хватает алиасов для типов. Хотя бы как в плюсах. И в скале алиасы есть ^__^
                                                                                          Для простых алиасов пока можно выкрутиться подобием правой руки – import kotlin.String as EntityKey, но это некий костыль костыля и не серьёзно ни разу.

                                                                                          Вроде видел в комментах к ранним версиям, что такая фича планируется после релиза. Какие причины/сложности были не делать сразу?

                                                                                          2) Можно как-то сделать крэши kotlin-plugin менее назойливыми? Я даже соглашусь с автоматической отправкой крэш-репорта :D

                                                                                          Спасибо вам, язык хорош!
                                                                                            +1
                                                                                            1) Алиасы для типов будут обязательно. Насколько я понимаю, сложностей там никаких не было — просто фича не казалась особенно приоритетной, а когда мы поняли, что казалась неправильно, нужно было уже стабилизироваться к релизу, а не добавлять новые фичи.

                                                                                            2) Пока никак, извините. Наверное, сделаем выключатель, чтобы все только в лог писалось.
                                                                                            0
                                                                                            -
                                                                                              +2
                                                                                              относительно методов коллекций filter и подобным ему (нетерминальным): сейчас все сгружается в ArrayList и возвращается как результат функции.
                                                                                              подобные вещи в Java8 делаются через стрим без промежуточных хранилищ.

                                                                                              про производительность спрашивать не стану, это дело конкретных кейсов. интересует были ли полемики на альтернативные подходы типа «возовращаем Iterable<> и пусть делают toList()»? если да, то какие были варианты и почему остановились на этом.
                                                                                                +2
                                                                                                У нас есть интерфейс Sequence, операции на котором имеют ленивую семантику. Преобразовать коллекцию в Sequence можно, вызвав asSequence, а обратно — toList/toSet. На Sequence определены практически все экстеншны, доступные и на обычных коллекциях: map, filter, drop, take и т.д.
                                                                                                0
                                                                                                Google предоставил крутую возможность работы с NDK прямо из студии. Такие проекты требуют определенного формата Gradle файла и еще ряда других приседаний. Будет ли возможность писать такие проекты на Kotlin? Сейчас при попытке подключить Kotlin-плагин к такому проекту показывается ошибка о невозможности найти "android {}" в Gradle файле.
                                                                                                +1
                                                                                                По началу исходники на Kotlin мне показались очень страшными непривычными, что пугало. Но повыполнял задания в песочнице и влюбился в этот язык. Это Java, только лучше! Как раз то, чего так сильно нехватало.

                                                                                                Кронштадт вперёд!))
                                                                                                  0
                                                                                                  (del)
                                                                                                    0
                                                                                                    А можно выделить какие-нибудь приемущества котлина перед груви?
                                                                                                    Знаю что в груви есть практически все фичи, которые имеются в котлине: есть лямбды, null safe, extention function и другие прелести.
                                                                                                    Есть возможность сделать статическую компиляцию с помощью аннотации @CompileStatic.
                                                                                                    А с версии 2.4 груви можно без проблем использовать на андроиде.
                                                                                                      0
                                                                                                      А че минусуем то? Я не ненавистник котлина, а наоборот. Написал пару приложений под андроид на нем и в восторге.
                                                                                                      Дело в том, что я хочу выяснить сабж выше и только. А у кого еще, как не у разработчиков языка это спросить?
                                                                                                        +3
                                                                                                        Мы, честно говоря, особенно не занимались сравнением с Groovy, потому что это язык преимущественно динамический. Ниже я укажу пару очевидных отличий, а остальное оставлю тем, кто готов сделать более подробный обзор.

                                                                                                        Если в Groovy включить статическую компиляцию, то, с точки зрения системы типов, получится Java. В Котлине есть преимущества в системе типов: functional types, nullable types, declaration-site variance, read-only collections.

                                                                                                        Использовать Груви на Андроиде я не пробовал, но рантайм там довольно большой, кажется.
                                                                                                          –5
                                                                                                          Похоже, вы таки занимались сравнением, потому что этот FUD это ровно то, что повторяет весь JetBrains (например, yole в #razborpoletov). Например, концепция того, что либо динамический и поэтому всё плохо, либо включить статическую компиляцию, и тогда сплошная джава — это полнейший FUD, потому что главное преимущество, конечно, в том, что когда нужно, Груви динамический, а когда нужно, быстрый как Джава.
                                                                                                          Ну и про "не пробовал, но осуждаю" на Андроиде тоже всё ясно.
                                                                                                            +10
                                                                                                            Не хотелось бы скатываться в эмоциональные выпады. Я раскрою немного вопрос про динамику и статику, раз он вызвал такой живой отклик.

                                                                                                            Когда мы делали Kotlin, у нас были вполне конкретные требования:

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

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

                                                                                                            Так вот, если использовать Groovy как статически типизированный язык (а это единственный вариант, который нас устраивает), мы получим систему типов Java, которая нас не устраивает. Поэтому мы дальше особенно не сравнивали, как я и написал в первом же предложении своего комментария.

                                                                                                            Еще раз повторю: у кого-то требования к языку могут не совпадать с нашими, это вполне нормально. Этим людям для их задач вполне может подойти Groovy, или Clojure, или Scala, или Fantom, или что-то еще. Нам не подходит, и мы считаем, что многим другим людям тоже не подходит.
                                                                                                              +3
                                                                                                              Видишь, есть такое объективно наблюдаемое явление: на Groovy под Android никто не программирует. Я не вижу ни заметного количества вопросов на StackOverflow от людей, которые сталкиваются с какими-то проблемами в этой связке, ни баг-репортов про то, что у кого-то что-то не работает в идее, ни блог-постов от людей, которые рассказывают, как у них круто получилось запрограммировать такое приложение и как всем тоже нужно бежать этим пользоваться. (Если я неправ, покажи, пожалуйста, ссылки.)

                                                                                                              Почему это так — я не знаю. Возможно, все на самом деле прекрасно работает (и линтеры все проверяют, и рантайм маленький, и размер/скорость сгенерированного кода не хуже, чем в Java, и собирается все быстро). Но судя по первому пункту — подозреваю, что не все.
                                                                                                                +1
                                                                                                                Ну раз пошла пьянка, можно вкинуть про Scala?
                                                                                                                Чем Kotlin, лучше Scala в android разработке?
                                                                                                                  +8
                                                                                                                  Наброс засчитан :) Отвечаю в художественной форме, потому что ну не могу уже :)

                                                                                                                  Чем Kotlin, лучше Scala в android разработке?

                                                                                                                  Для абстрактной андроид-разработки в вакууме — ничем. Или всем. :)

                                                                                                                  Какой у Вас юзкейс? Вас интересует размер стандартной библиотеки? Точность диагностик в IDE? Наличие в языке фич, не рекомендованных обычным пользователям? Необходимость конвертировать коллекции при передаче между кодом на разных языках? Null-safety? Наличие синтаксиса для вызова монад? Неявные преобразования в языке? Макросы? Типы высших порядков? Type classes? Тьюринг-полная система типов? Еще что-то?

                                                                                                                  В зависимости от ответов на эти вопросы можно принять решение о том, что Вам лучше подходит :)
                                                                                                                    +3
                                                                                                                    Надо в качестве эпиграфа к каждой статье добавлять.
                                                                                                                    +2
                                                                                                                    Просто тут нет универсального ответа, потому что для кого-то стандартная библиотека в 820KB — это преимущество, например, а кому-то все равно. Кому-то без макросов никуда, а кому-то отлично… Но судя по всему, есть много людей, которых Scala на Андроиде не устраивает (по каким-то из вышеописанных параметров, надо полагать), а Kotlin устраивает.
                                                                                                                      0
                                                                                                                      ИМХО, скала отлично подходит для разработки серверов, так как язык достаточно мощный. Но для андроида он слишком медленно будет бегать на большинстве девайсов.
                                                                                                            0
                                                                                                            Сейчас Koans. В целом после C# весьма комфортно, интересно было бы посмотреть еще туториалы о том, как на Kotlin создать базовое приложение со Spring.Mvc+Spring.Rest в той же Идее. А так молодцы) Наверное Kotlin самая интересная альтернатива C#.
                                                                                                              0
                                                                                                              Решаю* :)
                                                                                                                +1
                                                                                                                Мне кажется вы можете начать писать в стиле чистой java используя примеры для нее.
                                                                                                                Просто потом, когда более-менее привыкнете к котлину, отрефакторите.
                                                                                                                  0
                                                                                                                  Проблема в том, что я не джавист :) Просто когда разбирался со Спрингом — был не самый приятный опыт. Особенно когда вышел Boot и часть туториалов просто не работала. Надо же еще и IDE подшаманить как я понимаю. что бы это все взлетело. Поэтому и интересуюсь каким-нибудь quick-start. Думаю будем полезно многим, кто не сильно знаком с JVM — based миром.
                                                                                                            0
                                                                                                            Почему вы решили оставить инкремент как выражение? Вроде столько копий поломано, миллион и одно собеседование с данным вопросом. Оставили бы его как statement, если нравится.
                                                                                                              0
                                                                                                              Смотрели на юзкейсы, увидели, что поломается, решили оставить.

                                                                                                              Замечу, что у нас тут не С++, и на собеседовании про инкремент спросить особо нечего. Разве что разницу между префиксным и постфиксным.
                                                                                                              0
                                                                                                              Какие языки оказали сильное влияние на Kotin? Например, функциональщина вроде any, all похожа на питоновскую в противовес exists, forall из Scala.
                                                                                                                0
                                                                                                                Я бы сказал что в некоторых местах подозрительно напоминает C#… c Any(), All() и разными экстеншен методами..
                                                                                                                  0
                                                                                                                  Java, Groovy, Scala, C#, ML, F#, Gosu, Python, etc

                                                                                                                  Имена для методов стандартной библиотеки выбирались творчески, конкретно эти, кажется, из Groovy пришли, но я не уверен.
                                                                                                                  0
                                                                                                                  Интересный язык. Приятные плюшки других языков и всё это со статической типизацией. abreslav Вопрос про исключения. Есть ли возможность включить какие-то варнинги насчет необработаных исключений или хотя бы подсветку какую-нибудь? А то я узнаю о них из стектрейсов или нужно кажый используемый метов в программе просматривать на наличие бросаемых исключений.
                                                                                                                    0
                                                                                                                    На сегодня таких ворнингов у нас нет. И они в любом случае не будут корректно работать с лямбдами
                                                                                                                      0
                                                                                                                      А опциональная подсветка таких методов невозможна? По аналогии с подсвечеными переменнными, которые подверглись smartcast .
                                                                                                                        0
                                                                                                                        Возможна, но на лямбдах она будет обрываться, что как бы теряет смысл.
                                                                                                                    +1
                                                                                                                    Рас уж речь зашла о подсветке… Глупый вопрос, но почему по дефолту цвет аннотаций и ключевых слов совпадает? Вы таки будете смеяться, но какой-то унылый код без желтых аннотаций. А при их большом числе (spring, etc.) так вообще сливается в монотонное месиво.
                                                                                                                      0
                                                                                                                      Это сложилось исторически: когда-то синтаксис аннотаций и модификаторов был одинаковый, поэтому подсветку тоже сделали одинаковую. С тех пор синтаксис изменился, цвета остались, все привыкли, и Вы первый, кто обратил на это внимание за последние полгода :)
                                                                                                                      +1
                                                                                                                      А есть ли возможность добавить подсветку в студии для типов с <!>, которые получаются при взаимодействии с java? Сейчас очень велика вероятность пропустить такой тип (под пропустить имеется ввиду забыть его проверить на null) из-за прозрачной конвертации в not null типы в kotlin.
                                                                                                                        0
                                                                                                                        В принципе, такая возможность есть, но будет очень пестро
                                                                                                                        +4
                                                                                                                        А почему делегировать можно только в интерфейсы? Нет ли тут обрезки функционала? Например хочется сделать так:

                                                                                                                        class Foo(val buf:ByteBuffer): ByteBuffer by buf {
                                                                                                                        //...
                                                                                                                        }

                                                                                                                        Но нельзя, т.к. ByteBuffer — не интерфейс, и не имеет интерфейса. И наследоваться от него нельзя, потому что final. Неудобно.
                                                                                                                          0
                                                                                                                          Такова реальность JVM: от финального класса наследоваться нельзя, и делегироваться к классу тоже в общем случае нельзя
                                                                                                                          0
                                                                                                                          Как сделать extension метод для enum, чтобы был доступ к Enum.values()? И где определены values() и valueOf()?
                                                                                                                            0
                                                                                                                            На StackOverflow есть решение с reflection, там вместо values() используют enumConstants, но про valueOf() не написано.
                                                                                                                            +1
                                                                                                                            Почему в stdlib / kotlin.collections есть:
                                                                                                                            List — это Collection
                                                                                                                            Set — это — Collection
                                                                                                                            Map — не Collection??
                                                                                                                            Я в курсе, что так в Java, и было бы неудобно делать интероп с Java и т.д. С массивами как-то выкрутились же.
                                                                                                                            Если посмотреть на интерфейс Collection:

                                                                                                                            package kotlin.collections
                                                                                                                            
                                                                                                                            public interface Collection<out E> : kotlin.collections.Iterable<E> {
                                                                                                                                public abstract val size: kotlin.Int
                                                                                                                            
                                                                                                                                public abstract operator fun contains(element: @kotlin.UnsafeVariance E): kotlin.Boolean
                                                                                                                            
                                                                                                                                public abstract fun containsAll(elements: kotlin.collections.Collection<@kotlin.UnsafeVariance E>): kotlin.Boolean
                                                                                                                            
                                                                                                                                public abstract fun isEmpty(): kotlin.Boolean
                                                                                                                            
                                                                                                                                public abstract operator fun iterator(): kotlin.collections.Iterator<E>
                                                                                                                            }

                                                                                                                            то выясняется, что у Map не реализован только метод containsAll(), который очевидно реализуется из contains. Остальные либо уже есть, либо реализованы через extension.
                                                                                                                              0
                                                                                                                              Как, по-вашему, мы выкрутились с массивами? :)
                                                                                                                                0
                                                                                                                                Я имел в виду IntArray, LongArray, CharArray и прочие
                                                                                                                                  0
                                                                                                                                  Не вижу связи с коллекциями
                                                                                                                                    0
                                                                                                                                    В своем первом комментарии я написал "С массивами как-то выкрутились же", пытаясь, может быть не совсем корректно, привести пример того, что в Kotline не все так, как в Java. В котлине нет int[] и прочих, и для interop с Java сделан специальный инструмент IntArray и т.д. Этим примером я неуспешно пытался заранее контр-аргументировать предсказуемый ответ "потому что в Java Map не является коллекцией" на мой вопрос "почему Map — не Collection в Kotlin?" Этим превентивным контр-аргументом я неуспешно пытался подтолкнуть отвечающего дать развернутое и подробное объяснение.
                                                                                                                                    Прошу вас теперь все-таки ответить на мой основной вопрос в этой ветке:
                                                                                                                                    Почему Map не является коллекцией в Kotlin?
                                                                                                                                      +1
                                                                                                                                      Потому что в Java Map не реализует интерфейс Collection, и у нас нет никакой возможности его заставить это делать (и нигде более в языка мы ничего подобного не делаем, а когда пытались, получались ошибки во время выполнения). Придумать более подробный ответ я не смог, задайте уточняющий вопрос, если есть какое-то надопонимание.

                                                                                                                                      Кстати, int[] и IntArray — это одно и то же решение, то есть специальный тип для массива примитивов, только синтаксис разный.
                                                                                                                                        0
                                                                                                                                        Спасибо за ответ.

                                                                                                                                        Скажите, а java.lang.String и kotlin.String — это тоже различия на уровне синтаксиса или разные классы? Если второе, то наверно похожий трюк можно провернуть и с Map, нет?
                                                                                                                                          0
                                                                                                                                          Это различия на уровне синтаксиса, иначе не было бы никакого интеропа. (Отмечу, что заменить один класс на другой и добавить существующему классу новый суперкласс — это не одно и то же :))
                                                                                                                                            0
                                                                                                                                            И подозреваю, что сделать kotlin.Map + добавить его поддержку в синтаксисе не получится/не планируется? Как насчет того, чтобы в stdlib напихать extension методов? Изначально вопрос возник из-за того, что внезапно у Map нет first(), хотя есть iterator(). Конечно, все можно делать через entries, но я, наверно, сладкоежка и слишком избалован скалой :)
                                                                                                                                              0
                                                                                                                                              Таких планов на данный момент нет. Но Вы можете сделать нужные экстеншены сами, если они действительно облегчают жизнь.

                                                                                                                                              Для справки: kotlin.Map и так существует, и мы с Вами говорим именно о нем. Поддержка его в синтаксисе, возможно, будет, но как это связано с темой разговора, я пока не очень понимаю.
                                                                                                                                                0
                                                                                                                                                Написать их можно, но хотелось бы их видеть в стандарной библиотеке.
                                                                                                                                                Если уже есть extension для Collection, не хочется писать отдельный для Map. Какой-нибудь Collection.getRandomElement() например.
                                                                                                                              0
                                                                                                                              Google переведёт ОС Android на язык программирования Apple Swift
                                                                                                                              Представители Google планировали использовать язык Kotlin, однако данное ПО не может удовлетворить запросы разработчиков и отличается низкой производительностью.

                                                                                                                              Можете прокомментировать?

                                                                                                                                +2

                                                                                                                                Источник этого слуха (тут) не заслуживает доверия.

                                                                                                                                  0
                                                                                                                                  А вы никак не лоббируете на этом уровне Kotlin? Если есть реальные претезии- можно же попробовать с ними поработать…
                                                                                                                                    0

                                                                                                                                    Как можем, лоббируем. Если есть претензии — работаем :)

                                                                                                                                    0
                                                                                                                                    не может удовлетворить запросы разработчиков и отличается низкой производительностью

                                                                                                                                    в целом неясно откуда могли появиться слухи о низкой производительности, если котлин изначально затачивался легковесным и весит всего 200кб
                                                                                                                                      0

                                                                                                                                      Слухи — они на то и слухи :)

                                                                                                                                    0
                                                                                                                                    Судя по Источник, Google еще официально ничего не объявило, а лишь рассматривает Swift в качестве альтернативного языка для разработки под Android, впрочем как и Kotlin.
                                                                                                                                      0
                                                                                                                                      Swift — открытый мультипарадигменный объектно-ориентированный язык программирования общего назначения. Создан компанией Apple в первую очередь для разработчиков iOS и OS X. Swift работает с фреймворками Cocoa и Cocoa Touch и совместим с основной кодовой базой Apple, написанной на Objective-C.


                                                                                                                                      интересно, а apple их потом исками не закидает за какой нибудь «копипаст пары строчек» в реализации, как Oracle пытался )
                                                                                                                                        0
                                                                                                                                        так свифт опенсорсный уже
                                                                                                                                    0
                                                                                                                                    Добрый день, belovrv

                                                                                                                                    Есть ли способ создать .kt файлы c помощью javax.annotation.processing.Processor?

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

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