Для тех, кто слышит о 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 (исключая наши) число строчек растет экспоненциально, и на момент релиза их уже больше двух миллионов:
- Мы планируем вскоре зарелизить поддержку JavaScript и Java 8
- У нас есть своя онлайн-песочница: http://try.kotl.in В ней есть серия задачек Kotlin Koans, которые помогают освоиться с языком буквально за несколько часов. Действительно за несколько часов! Также у нас отличная документация на официальном сайте.
- Мы открыты! Kotlin разрабатывается на GitHub, под лицензией Apache 2.0. Но самое главное, мы всегда внимательно прислушиваемся ко всему входящему фидбеку, так что теперь слово вам:
Комментарии (139)
eReS
19.02.2016 16:55-71) Как в плане быстродействия по сравнению с Java и с каким-то нативным языком? Например Go
2) Планируется ли нативная компиляция в будущем для работы без VM?
udalov
19.02.2016 17:15+51) Если писать код, эквивалентный аналогичному коду на Java, то производительность почти ровно такая же. На данный момент нам неизвестно никаких существенных проблем с перформансом. Единственное заметное отличие от байткода Java — для выражений и параметров non-null типов у нас генерируется приличное количество проверок на null, но, по нашему опыту, они не особо что-то замедляют (кроме того, они отключаемы).
Другое дело, что если использовать идиомы и стандартные функции Котлина, производительность может быть даже лучше. Например, разные map/filter не только заинлайнятся вместе с передаваемой лямбдой, но и создадут правильные коллекции с оптимальной capacity.
С нативными языками, думаю, сравнивать несколько странно и этого сравнения пока никто не делал, по крайней мере мне об этом неизвестно.
2) Планируется.nwalker
19.02.2016 18:50-1А вас не посещала идея сделать транспилер в Go вместо нативного таргета?
У него очень приятный рантайм, но так себе язык — как и у всех ваших таргет-платформ.yole
19.02.2016 19:01+3Мысль, кстати, очень интересная, надо подумать. Мы думали в основном про варианты LLVM либо генерации кода на C, но и в том, и в другом случае ребром встает вопрос garbage collection, который в Go как раз решен.
pjBooms
20.02.2016 08:38+71) 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 — это два разных языка, несмоторя на то, что некоторые куски кода могут работать одинаково и там, и там.pjBooms
20.02.2016 08:50+2Да забыл, написать. Из выше написанного следует, что Kotlin компилируется нативно уже сейчас, ничего планировать в этом смысле не надо.
yole
20.02.2016 11:51Ну ты же понимаешь, что это на самом деле не совсем так. То, как Kotlin компилируется сейчас, например, не позволяет писать на котлине полностью нативные iOS-приложения. Компилировать его так, чтобы это было можно — это вполне интересная цель, которую вполне имеет смысл планировать.
pjBooms
20.02.2016 12:15Ну и вы уже сейчас, как я понимаю, интегрируетесь с RoboVM, что вас там не устраивает?
Shoonoise
20.02.2016 11:45Go не более нативный язык, чем Java (и соответсвенно Kotlin).
Гм. Ну, то есть посыл про то, что "VM — это по сути управляемая среда исполнения, то есть просто очень умный рантайм и не более того. " ясен. Н о утверждение, что Go и Java в этом плане мало чем отличаются имеет мало общего с реальностью.
Взять хотя бы необходимость установки рантайма в систему. Это даже не говоря о скорости запуска этого рантайма.pjBooms
20.02.2016 11:56+2Никто не застваляет вас ставить рантайм. Можно его таскать с собой (соврешенно легально). К тому же с компактными профилями для Java 8 размер этого рантайма становится совсем небольшим, начиная с 11MB на диске.
Что касается скорости запуска, то в нашей JVM есть оптимизатор запуска, который делает старт Java приложений практически мгновенным (сравнимым с запуском нативных приложений).Shoonoise
20.02.2016 12:16Что касается скорости запуска, то в нашей JVM есть оптимизатор запуска, который делает старт Java приложений практически мгновенным
Хм, звучит интересно, вроде бы.
Но из представленных там графиков можно сделать вывод, что конкретное приложение на Java может стартавать 5 секунд (что, вообще то, не очень быстро), вместо 20 секунд (что вообще за гранью).
И что оптимизированное приложение стартует сравнимо с каким то другим нативным приложением. Это, конечно показатель.pjBooms
20.02.2016 12:18+1Не просто с каким-то другим, а с реальным приложением с точно такой же функциональностью (читалка и показывалка RSS) написанная на С++.
jdev
20.02.2016 12:595 секунд (что, вообще то, не очень быстро)
Возможно бенчи прводились на HDD и значительная доля времени ушла чтение кода с диска, а на SSD разница будет меньше.
Но в любом случае в обмен на это богатый рантайм позволяет вам писать приложение на смеси языков с динамической и статической типизацией и во время разработки использовать JRebel и Plumbr и ещё пачку различных тулов, которые базируются на том, что рантайм может многое рассказать о состоянии программы.
Так же я хз как это с АОТ компиляцией согласуется, но опять же благодаря богатому рантайму можно делать такие вещи: Quasar.pjBooms
20.02.2016 22:165 секунд — это немного для богатого ГУЕвого приложения даже с SSD. Сколько у вас Office стартует или какая-нибудь Visual Studio? Я только что проверил — у меня офис с моего Macbook Air стартовал с SSD за 10 секунд.
Такие вещи как Quasar согласуются c AOT точно также, как и большинство других Java API — то есть легко.
Throwable
19.02.2016 17:13+1Планируете ли Вы помимо языка создание и поддержку инициативы вроде Typesafe по формированию стека технологий для наиболее актуальных задач на базе языка Kotlin?
yole
19.02.2016 17:38+4Нет, потому что это не нужно — Kotlin прекрасно использует любой существующий Java-стек. Мы экспериментируем с созданием отдельных фреймворков, которые оптимальным образом используют фичи языка, но пока что у нас нет ощущения, что есть потребность в создании полного альтернативного стека.
gaelpa
20.02.2016 12:55Если тема с компиляцией в разные платформы (JVM, JS, [iOS]..) не заглохнет, то будет необходимость в библиотеках отвязанных от конкретной платформы, чтобы на них можно было опирать свой код.
yole
20.02.2016 14:26Какое-то количество кросс-платформенных библиотек нужно, но это совсем не весь стек. Тащить в браузер аналоги Spring и Hibernate решительно ни к чему.
yetanothercoder
19.02.2016 17:18moving forward the compiler will be backwards compatible and future versions of Kotlin must not break existing code.
вопрос:
гарантия вечной обратной совместимости, т.е. тоже самое что и в самой Java. Так ли это необходимо? Последствия известны на примере ущербных generics, устаревшего дизайна коллекций и не всегда удобной реализации лямбд и тд. многие могут сами добавить из наболевшего. Так ли это будет критично если раз в 10-15 лет эта самая обратная совместимость будет не соблюдаться для изменения языка в лучшую сторону? У нас уже есть Java с вечной обратной совместимостью, так ли нужно это теперь еще в Котлине?
Голосование тут показывает что большинству достаточно было бы обратной совместимости в пределах мажорного релиза.yole
19.02.2016 17:41+2Мы не предполагаем, что обратная совместимость Kotlin неизбежно будет вечной. Вполне возможен вариант, что в какой-то момент выйдет Kotlin 2.0, который не будет полностью обратно совместимым с 1.x, так же, как Python 3 не полностью обратно совместим с Python 2.
dougrinch
19.02.2016 21:36и не всегда удобной реализации лямбд
А что с ними не так?yetanothercoder
20.02.2016 19:47никогда не сталкивались? все как надо и удобно?
вот хотя бы
https://dzone.com/articles/whats-wrong-java-8-currying-vs
https://dzone.com/articles/dark-side-java-8
x2bool
19.02.2016 17:21+1- Есть ли что-то такое, что хотелось реализовать в языке, но по тем или иным причинам от этого пришлось отказаться?
- [trololo_mode]Kotlin — всего-лишь Java с более компактным синтаксисом. Переубедите?[/trololo_mode]
udalov
19.02.2016 18:44+31) Вот, что смог вспомнить, но это далеко не всё:
- self type, отказались, т.к. вредит Java-интеропу;
- reified generics, не придумали хорошего решения, и тоже Java-интероп;
- хотели сделать, чтобы '==' был по конвенции, а не доступен на чём угодно (если есть в скоупе функция equals, возможно экстеншн, то '==' вызывает её), а также интерфейс Hashable с функцией hashCode, но это было давно и сейчас уже звучит несколько забавно;
- была идея сделать все модификаторы аннотациями, не получилось;
- хотели сделать полную защиту от NPE и считать всё, что из Java, nullable. Это была долгая и поучительная история
ov7a
25.02.2016 16:30А будут ли подробности "поучительной истории?" Как я понял, проблемы там были с несколькими вещами:
Наследование fun (foo: String?) vs fun (foo: String)
Шаблоны Array vs Array<String?> при получении/передаче в Java
Цепочка Java — Kotlin — Java
И при таких сценариях приходилось делать много костылей, чтобы заработало. (Поправьте пожалуйста, если что не так сказал). И поэтому решили от идеи все Nullable отказаться. Но вроде как один из основных сценариев — свой код пишем на Kotlin, библиотели берем Java (как видится мне, простому крестьянину-кодеру ). И при таком раскладе, лучше безопасность в большей части кода и явные костыли в небольшой части кода, чем "красиво и удобно" + внезапные грабли в рантайме (или яма с кольями, как повезет).udalov
25.02.2016 20:24Одна из основных причин была в том, что писать на таком языке было неудобно, а читать его — неприятно. Повсюду вопросительные и восклицательные знаки, которые не очень-то помогают из-за того, что расставляются в основном, чтобы удовлетворить компилятор, а не чтобы корректно обработать случаи, когда выражение вычисляется в null. Особенно больно в случае дженериков: например,
Map<String?, String?>?.
yole
19.02.2016 18:56+2Если отвечать на второй вопрос, то, конечно же, Kotlin отличается от Java не только синтаксисом. Например, поддержка nullability — это различие на уровне системы типов, а не синтаксиса. Фичи типа reified type parameters и delegated properties — отличия на уровне семантики. И это не говоря уже о поддержке трансляции Kotlin в JavaScript.
HunterNNm
19.02.2016 17:22Мы планируем вскоре зарелизить поддержку JavaScript
— немного не понял данный пункт… Можно поподробнее?
bashor
19.02.2016 17:53+2Есть компилятор Kotlin в JS, который еще не зарелижен, планируем зарелизить :)
yetanothercoder
19.02.2016 18:00а как это будет выглядеть примерно? т.е. пишем UI логику страницы на котлине используя встроенные в js-kotlin runtime DOM объекты (document, window и тд.) потом скармливаешь компилятору — получаешь как в gwt минимизированный js файлик на выходе, который потом вставляешь в <script… страницы?
Будет ли какой-то отладочный режим в IDEA, чтобы сразу без полной перекомпиляции посмотреть как этот котлин код на существующей html странице отработает?bashor
19.02.2016 18:06потом скармливаешь компилятору — получаешь как в gwt минимизированный js файлик на выходе, который потом вставляешь в <script… страницы?
Да, все так, за исключением того что мы минификацией не занимаемся, оставляя это на откуп другим тулам.
Будет ли какой-то отладочный режим в IDEA, чтобы сразу без полной перекомпиляции посмотреть как этот код на существующей html странице отработает?
Будет инкриментальная компиляция, которая перекомпилирует только нужные файлы.
Pinsky
19.02.2016 17:26При разработке JS target'а нода учитывается?
bashor
19.02.2016 17:32+1Да, но это в основном влияет на библиотечную часть, а JS что на ноде что в браузере один и тот же.
Pinsky
19.02.2016 17:36а ES6/ES7?
bashor
19.02.2016 17:55Сейчас таргет только один — ES5, но мы, конечно же, следим за развитием ECMAScript и других смежных технологий.
LMnet
19.02.2016 18:12+4Ребята, которые разрабатывают Scala.js экспериментировали с компиляцией в ES6. На текущий момент эти эксперименты показали, что скомпилированный в ES5 код работает быстрее. Для Kotlin, скорее всего, ситуация будет аналогична. К тому же, если использовать JavaScript как compilation target, то особого смысла в ES6/ES7 нет, там большинство нововведений — синтаксический сахар.
zim32
19.02.2016 19:45Мапы, сеты, генераторы, лямбды, промисы, символы, let, string templates по вашему это все сахар?
LMnet
20.02.2016 08:23+6Я не говорил, что все нововведения в новых версиях JS — это сахар. Я сказал, что большинство — это синтаксический сахар. То есть это конструкции, которые можно выразить и в ES5, и в ES6. Яркий пример сахара — лямбды. Но, к примеру, символы — это не сахар, потому что в ES5 их не выразишь имеющимися средствами языка.
Обычное использование JS, и использование JS как compilation target — это совершенно разные вещи. Какая разница для компилятора, скомпилировать колбэк в обычную функцию, или в лямбду? Если бы лямбды работали быстрее, смысл был бы. Но на текущий момент ES6 работает медленнее, и у него худшая поддержка браузерами. Именно эту мысль я хотел донести.
bashor
20.02.2016 16:06Не смотря на то что таргет ES5 мы стараемся воспользоваться фичами которые есть в рантайме, если это дает какой-то выигрыш. Это например Map, Set, Symbol, методы которые появились только в после ES5.
saladinkzn
19.02.2016 18:11+3Будет ли что-то похоже на async/await из C#? Видел Kovenant, но это всего лишь промизы с потенциальной лапшой из колбэков.
yole
19.02.2016 18:20+4Да, планируется. Мы даже зарезервировали ключевые слова async и await. Правда, по поводу сроков и деталей реализации пока что сказать ничего не можем — фича еще не задизайнена.
Sp0tted_0wl
19.02.2016 18:35Планируется ли написание более обширной документации покрывающей все аспекты языка? То, что есть сейчас на сайте хорошо для старта, но есть вещи, которые там найти нельзя совсем или они раскрыты очень слабо. И если это планируется, то когда ждать?
udalov
19.02.2016 18:50+2Да, будет спецификация языка.
Если какие-то вещи в документации имеет смысл раскрыть подробнее, это повод сообщить нам или исправить самим :) Сайт с документацией лежит на гитхабе
yole
19.02.2016 18:53+1Собственных планов по переработке документации на сайте у нас на данный момент нет. Если вы не можете найти там какую-то конкретную информацию, то это, конечно же, баг, о котором нам нужно рассказать, и мы добавим туда информацию. Мы также следим за вопросами от пользователей и дополняем документацию на сайте, если видим, что ответа на вопрос на сайте не найти, а нужно.
Еще у нас есть книжка, в которой многие вещи объясняются более развернуто и с большим количеством примеров, чем на сайте.
nicolausYes
19.02.2016 19:02+1В прошлом году Jake Wharton назвал невозможность компилятора Kotlin запускать annotation processors (и использовать их с Java 'as is') большим сдерживающим фактором в использовании Kotlin для разработки под андроид.
Что-то изменилось в этом плане с того времени?nwalker
19.02.2016 19:11+2Я не знаю точно, что он имел ввиду, но сейчас annotation processors работают — я играюсь с проектом на Kotlin и Moxy, где все строится на аннотациях, полет нормальный.
basnopisets
19.02.2016 22:51+1если вы про внутренний документ Джейка про Котлин, то с момента его написания (начало 2015 г.) прошло довольно много времени, за которое успел появиться kapt — сейчас ничего не мешает использовать, например Dagger 2 с Kotlin. Если есть вопросы, могу помочь
Ghedeon
20.02.2016 01:15Справедливости ради, kapt все еще толком не переваривает DataBindings: https://youtrack.jetbrains.com/issue/KT-8007
yole
20.02.2016 11:45+1Конкретно сейчас проблема с data bindings вызвана только тем, что компилятор data bindings собран пререлизной версией котлина и падает с проектами, которые используют релизную версию. В следующем апдейте это будет исправлено.
korniltsev
19.02.2016 19:10У меня 2 вопроса.
- Для андроида существует экспериментальный тулчейн. http://tools.android.com/tech-docs/jackandjill
Что Вы про него думаете? Задумывались ли Вы о возможности какой-либо интеграции с ним?
- Время компиляции при работе с андроид проектами всегда была большой проблемой.
Планируются ли какие-нибудь оптимизации в этом направлении?
yole
19.02.2016 20:37+11) Jack и Jill решают задачу генерации Dalvik-байткода напрямую из Java, минуя Java-байткод. Насколько я понимаю, нам никто не мешает самим генерировать Dalvik-байткод, и интегрироваться с Jack и Jill для этого не нужно и не факт, что полезно.
2) Мы сейчас заканчиваем работу над поддержкой инкрементальной компиляции для Gradle, которая позволит компилировать ровно те классы, которые затронуты изменениями после предыдущей компиляции.
- Для андроида существует экспериментальный тулчейн. http://tools.android.com/tech-docs/jackandjill
Zabelnikov
19.02.2016 19:22У меня вопрос по поводу использования kapt и Android Annotations.
Сколько не пытался, так и не удалось их подружить, будет ли поддержка AA в дальнейшем?
abreslav
20.02.2016 18:44Android Annotations должны штатно работать с использованием kapt. Если что-то не в порядке, создайте, пожалуйста, баг в нашем трекере https://youtrack.jetbrains.com/issues/KT
h0tkey
19.02.2016 21:09+1Есть такой вопрос: планируете что-нибудь для метапрограммирования, более мощное, чем annotation processing javac'а? Например, что-нибудь из разряда Groovy AST.
yole
19.02.2016 23:17+2Пока что более-менее серьезно обсуждались только expression trees как в C# 3.0. Конкретных решений пока никаких не принимали, будем смотреть на фидбэк и юзкейзы.
Nagg
20.02.2016 00:13Замечательный язык, очень интересна история появления — чем вдохновлялись, почему реишили создать. Если встает необходимость покодить что-то под жвм — сразу расчехляю котлин.
yole
20.02.2016 12:23+3Решили создать по простой причине: заметили, что у нас есть IDE для такого количества прекрасных языков, а сами мы почему-то пишем все время на Java и не видим убедительной альтернативы. Ну и из предыдущего опыта было известно, что если нам самим не хватает какого-то инструмента, то с большой вероятностью он также окажется востребованным на рынке.
Вдохновлялись — да всем, что вокруг существует. C#, Groovy, Scala, в отдельных местах Python и Ruby, иногда более экзотические языки типа Gosu.
GreatKoshak
20.02.2016 00:31+3У меня вопросы не по технической части:
- Google как-нибудь реагировал во время разработки языка и на его релиз?
- Планируется ли от них какая-нибудь официальная поддержка? У JetBrains, вроде как, имеется опыт работы с ними.
belovrv
20.02.2016 12:12Сложно до конца честно ответить на этот вопрос. Предлагаю вернуться к нему где-то через год.
yole
20.02.2016 12:29Про одну реакцию Google можно рассказать вполне честно: кусок компилятора data bindings в Android SDK написан на котлине.
Вот еще одна реакция: developer evangelist из гугла пишет про котлин с дисклеймером, что это не отражает мнение его работодателя. https://medium.com/@CodingDoug/kotlin-android-a-brass-tacks-experiment-part-1-3e5028491bcc#.dx2f41ebm
А вообще, прежде чем можно будет всерьез говорить об официальной поддержке, нужно проделать еще очень много работы с нашей стороны. Мы стараемся. :)
nicolausYes
20.02.2016 12:46+3Ну, бывает пишут о нем в своем твиттере.
Kotlin & Android: A Brass Tacks Experiment, Part 1: https://t.co/1pl3UhMXKP pic.twitter.com/RaMDqG8wRx
— Android Developers (@AndroidDev) 1 февраля 2016
И даже увидели, что Google во внутрях кое-где использует.
So @project_kotlin is being used in the data binding compiler… interesting… #AndroidDev pic.twitter.com/4pJmYJqXc9
— Ross Hambrick (@rosshambrick) 24 июля 2015
gurinderu
20.02.2016 01:25Не сильно всматривался в Kotlin. Вопрос простой: почему стоит выбрать Kotlin, а не Scala?
Будет ли в Kotlin компилятор встроенная фича как в Scala dotty по выпиливанию ненужного кода?
SergioShpadi
20.02.2016 10:27+3На сайте Kotlin есть сравнение, где сказано, что если вы счастливы со Scala, то Kotlin вам не нужен. Основное различие состоит в том, что Kotlin позиционирует себя как better Java, а у Scala все же своя парадигма и идеология.
В самом Scala dotty тулзы по выпиливанию кода не будет. Будет тулза linker поверх компилятора, разработкой которой занимается хабраюзер darkdimius. И выпиливание ненужного кода — это лишь часть работы, которую linker делает. Он также оптимизирует (ан)боксинг примитивных типов и value-классов. Кроме того ожидается оптимизация создания быстроумирающих объектов в off-heap.
GubkaBob
20.02.2016 02:45+21) idea-плагин может брать версию и рантайм котлина из описания maven-плагина в pom файле? Сейчас котлин конфигурируется в двух местах — в pom и в библиотеках модуля в проекте?
2) почему final val в object не транслируется в public static final field у ява-класса? приходится использовать «class.INSTANCE.val()» конструкцию.
3) lombok @Slf4j не работает… должен ли? или жаловаться разработчику?
4) dynamic — насколько он реально был востребован?yole
20.02.2016 12:371) Если у вас Maven-проект, то отдельно настраивать версию библиотеки Kotlin в проекте не нужно, при импорте из Maven все само настроится. Но при этом очень желательно, чтобы версия Kotlin, на которую вы ссылаетесь в pom.xml, совпадала с версией плагина, который установлен в IDE — а эта версия не может быть разной для разных проектов.
2) Транслируется, если пометить его аннотацией @JvmField.
3) Скорее не должен. У нас есть механизм по поддержке annotation processors, через который в принципе может работать Lombok, но он пока интегрирован только в Gradle-билды и не интегрирован в Maven. Ну и казалось бы, что встроенные фичи Kotlin делают примерно весь Lombok ненужным.
4) Очень сложно говорить о востребованности каких-то фич JS-таргета, пока он существует только в экспериментальном виде. Просто нет столько кода, который мог бы их использовать, чтобы можно было делать какие-то выводы.GubkaBob
20.02.2016 13:51+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 от авторов.yole
20.02.2016 14:233) Я бы просто завел private val logger = LoggerFactory.getLogger(Klass::class.java) на уровне файла. Если сделать хелперную функцию, можно сократить это до private val logger = getLogger()
5) Для решения этой проблемы у нас придуман модификатор lateinit.
vsb
20.02.2016 09:46+21) Насколько вы думали про 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) Есть ли некий список того, что вероятно будет добавлено в обозримом будущем?yole
20.02.2016 12:58+11) и 2) оставлю коллегам, которые занимаются JS и стандартной библиотекой. Со своей стороны скажу, что все будет хорошо. :)
3) dynamic для Java сделать можно, но это очень дорогая фича: во-первых, она сама по себе требует довольно много работы по дизайну и реализации, и во-вторых, про нее нужно все время помнить при дизайне и реализации всех остальных фич ("а что если в этом месте стоит dynamic?"). Кроме того, мы знаем, что в C# dynamic оказался намного менее востребованным, чем ожидалось. Поэтому — да, возможно, в какой-то момент мы увидим востребованные юз-кейзы, которые с dynamic решаются намного лучше, чем без него, и-таки его добавим. Но это точно не приоритет на данный момент.
4) Таких string templates у нас никогда не было, если я ничего не путаю. Ровно такой синтаксис, как в Scala, мы в 1.0 зарезервировали на будущее, и с большой вероятностью в какой-то момент поддержим.
5) Есть, и мы обязательно его опубликуем, как только закончим обсуждение внутри команды.
bashor
20.02.2016 15:541) стандратная библиотека разрабатывается с учетом имеющихся сейчас таргетов и там еть API доступное для обоих платформах, и есть платформо-специфичное API. В свою очередь платорфмо-независемое API могут иметь разные реализации.
2) Политика сейчас такая, что практически все фичи языка должны работать на обоих платформах и иметь одинаковую семантику, по модулю некоторых особенностей платформы, например работа с примитивами или реализация регулярных выражений.
basnopisets
20.02.2016 13:02когда допишется книга Дмитрия и Светланы?
yole
20.02.2016 14:07Опыт показывает, что обещать какие-то конкретные сроки — плохая идея. :) Как только, так сразу. 7 глава вот-вот появится в MEAP, две следующих уже почти готовы.
GubkaBob
20.02.2016 21:05в ява-файле в контекстном меню была опция похожая на «suppress unused warning for class annotated with @тутимяаннотации », например для аннотации Controller. возможно в котлин-плагин такую фичу запилить для классов и методов?
udalov
21.02.2016 01:22Пока что можно на unused классе нажать Alt+Enter -> Edit inspection profile setting -> Configure annotations и добавить туда нужную аннотацию, класс должен перестать быть unused
potan
20.02.2016 21:14+2Почему значение функции не определяется ее последним выражением как в Scala, а требуется специальный оператор return, как в старых языках?
Maccimo
21.02.2016 09:05+3По-моему вы троллите.
Haskell появился где-то в середине восьмидесятых — начале девяностых прошлого века, а вы в две тысячи шестнадцатом говорите об отсутствии «return» как о признаке «новизны». Не говоря уже о том, что корни такой нотации растут из записи математических формул.
IMHO неиспользование return можно оправдать только нестерпимым желанием прострелить себе ногу.potan
21.02.2016 14:34+1Haskell, *ML, Lisp все-таки редкие языки. Языки, не требующие специального оператора, стали получать распространение сравнительно недавно.
Неиспользование return способствует использованию коротких понятных функций и улудшает читабельность и провторное использование кода.
Как отказ от return помогает "прострелить себе ногу"? По моему наоборот, привычка его использовать может вести к неожиданным эффектам.gaelpa
21.02.2016 15:40В котлине есть нотация для "коротких понятных функций" без использования return:
fun summ(a: Int, b: Int) = a + b
Присоединюсь к Maccimo во мнении что для всего что длиннее одной строки return нужен.Optik
21.02.2016 16:16+2Можете пример дать? У меня, честно говоря, фантазии не хватает придумать такой кейс, когда бы return понадобился во имя безопасности. По личному опыту с изучением и дальнейшей работой со scala адаптация прошла почти мгновенно и проблем не было за все время (скорее только вздох облегчения).
yetanothercoder
21.02.2016 23:03много точек выхода в разных местах усложняют анализ и поддержку кода:
http://stackoverflow.com/a/733858/365675
отказ от return вынуждает иметь одну точку выхода в конце.Optik
21.02.2016 23:25Ну как бы да. А где негатив от отсутствия return?
yetanothercoder
21.02.2016 23:54пардон, на уровень выше предполагался коммент )
ну а негатив все же небольшой можно упомянуть — если только при неправильных аргументах первой строчкой удобней через return выйти для улучшения читабельности, на SO там это обсуждается.
potan
21.02.2016 21:03+3Два разных синтаксиса для функций, IMHO, излишество.
А в чем польза от return? Лично мне он только мешает. Сталкивался со многими его адептами, но полезности мне так ни кто и не объяснил. Доходило до того, что допускали его только последним оператором функции, но само слово все равно считали необходимым. Мне интересно узнать почему, особенно от дизайнеров языка.
std
21.02.2016 03:14+21) Очень не хватает алиасов для типов. Хотя бы как в плюсах. И в скале алиасы есть ^__^
Для простых алиасов пока можно выкрутиться подобием правой руки –import kotlin.String as EntityKey, но это некий костыль костыля и не серьёзно ни разу.
Вроде видел в комментах к ранним версиям, что такая фича планируется после релиза. Какие причины/сложности были не делать сразу?
2) Можно как-то сделать крэши kotlin-plugin менее назойливыми? Я даже соглашусь с автоматической отправкой крэш-репорта :D
Спасибо вам, язык хорош!yole
21.02.2016 12:38+11) Алиасы для типов будут обязательно. Насколько я понимаю, сложностей там никаких не было — просто фича не казалась особенно приоритетной, а когда мы поняли, что казалась неправильно, нужно было уже стабилизироваться к релизу, а не добавлять новые фичи.
2) Пока никак, извините. Наверное, сделаем выключатель, чтобы все только в лог писалось.
GubkaBob
21.02.2016 16:31+2относительно методов коллекций filter и подобным ему (нетерминальным): сейчас все сгружается в ArrayList и возвращается как результат функции.
подобные вещи в Java8 делаются через стрим без промежуточных хранилищ.
про производительность спрашивать не стану, это дело конкретных кейсов. интересует были ли полемики на альтернативные подходы типа «возовращаем Iterable<> и пусть делают toList()»? если да, то какие были варианты и почему остановились на этом.udalov
21.02.2016 21:10+2У нас есть интерфейс Sequence, операции на котором имеют ленивую семантику. Преобразовать коллекцию в Sequence можно, вызвав asSequence, а обратно — toList/toSet. На Sequence определены практически все экстеншны, доступные и на обычных коллекциях: map, filter, drop, take и т.д.
Sp0tted_0wl
21.02.2016 20:17Google предоставил крутую возможность работы с NDK прямо из студии. Такие проекты требуют определенного формата Gradle файла и еще ряда других приседаний. Будет ли возможность писать такие проекты на Kotlin? Сейчас при попытке подключить Kotlin-плагин к такому проекту показывается ошибка о невозможности найти "android {}" в Gradle файле.
abreslav
22.02.2016 18:14Мы пока на это не смотрели, но, если есть юзкейсы, можем поддержать. Напишите нам реквест в https://youtrack.jetbrains.com/issues/KT
andreich
22.02.2016 13:01А можно выделить какие-нибудь приемущества котлина перед груви?
Знаю что в груви есть практически все фичи, которые имеются в котлине: есть лямбды, null safe, extention function и другие прелести.
Есть возможность сделать статическую компиляцию с помощью аннотации @CompileStatic.
А с версии 2.4 груви можно без проблем использовать на андроиде.andreich
24.02.2016 12:30А че минусуем то? Я не ненавистник котлина, а наоборот. Написал пару приложений под андроид на нем и в восторге.
Дело в том, что я хочу выяснить сабж выше и только. А у кого еще, как не у разработчиков языка это спросить?abreslav
24.02.2016 12:57+3Мы, честно говоря, особенно не занимались сравнением с Groovy, потому что это язык преимущественно динамический. Ниже я укажу пару очевидных отличий, а остальное оставлю тем, кто готов сделать более подробный обзор.
Если в Groovy включить статическую компиляцию, то, с точки зрения системы типов, получится Java. В Котлине есть преимущества в системе типов: functional types, nullable types, declaration-site variance, read-only collections.
Использовать Груви на Андроиде я не пробовал, но рантайм там довольно большой, кажется.
jbaruch
25.02.2016 03:15-5Похоже, вы таки занимались сравнением, потому что этот FUD это ровно то, что повторяет весь JetBrains (например, yole в #razborpoletov). Например, концепция того, что либо динамический и поэтому всё плохо, либо включить статическую компиляцию, и тогда сплошная джава — это полнейший FUD, потому что главное преимущество, конечно, в том, что когда нужно, Груви динамический, а когда нужно, быстрый как Джава.
Ну и про "не пробовал, но осуждаю" на Андроиде тоже всё ясно.abreslav
25.02.2016 09:42+10Не хотелось бы скатываться в эмоциональные выпады. Я раскрою немного вопрос про динамику и статику, раз он вызвал такой живой отклик.
Когда мы делали Kotlin, у нас были вполне конкретные требования:
- статическая типизация для поддержки больших объемов кода,
- очень хороший тулинг (для этого тоже нужна статическая типизация),
- совместимость для миграции и переиспользования инфраструктуры,
- "демократичность" языка (не нужно делить фичи на "для всех" и "не для всех").
В данном случае нас интересуют первый и второй пункты. Верно ли, что языки должны быть статически типизированными — это бессмысленный вопрос. Некоторые люди предпочитают статически типизированные, а некоторые другие люди — динамически типизированные. Мы относимся к первой группе. Это значит, что мы хотим, чтобы наш код был статически типизированным. Кроме отлова ошибок на стадии компиляции, это, в том числе, дает возможность тулингу много чего про код точно понять, что невозможно в динамическом языке. Естественно, не все люди на свете хотят такой тулинг или ловить баги на стадии компиляции, но мы хотим, и думаем, что есть много людей, которые тоже хотят.
Так вот, если использовать Groovy как статически типизированный язык (а это единственный вариант, который нас устраивает), мы получим систему типов Java, которая нас не устраивает. Поэтому мы дальше особенно не сравнивали, как я и написал в первом же предложении своего комментария.
Еще раз повторю: у кого-то требования к языку могут не совпадать с нашими, это вполне нормально. Этим людям для их задач вполне может подойти Groovy, или Clojure, или Scala, или Fantom, или что-то еще. Нам не подходит, и мы считаем, что многим другим людям тоже не подходит.
yole
25.02.2016 10:41+3Видишь, есть такое объективно наблюдаемое явление: на Groovy под Android никто не программирует. Я не вижу ни заметного количества вопросов на StackOverflow от людей, которые сталкиваются с какими-то проблемами в этой связке, ни баг-репортов про то, что у кого-то что-то не работает в идее, ни блог-постов от людей, которые рассказывают, как у них круто получилось запрограммировать такое приложение и как всем тоже нужно бежать этим пользоваться. (Если я неправ, покажи, пожалуйста, ссылки.)
Почему это так — я не знаю. Возможно, все на самом деле прекрасно работает (и линтеры все проверяют, и рантайм маленький, и размер/скорость сгенерированного кода не хуже, чем в Java, и собирается все быстро). Но судя по первому пункту — подозреваю, что не все.gurinderu
25.02.2016 11:12+1Ну раз пошла пьянка, можно вкинуть про Scala?
Чем Kotlin, лучше Scala в android разработке?abreslav
25.02.2016 11:21+8Наброс засчитан :) Отвечаю в художественной форме, потому что ну не могу уже :)
Чем Kotlin, лучше Scala в android разработке?
Для абстрактной андроид-разработки в вакууме — ничем. Или всем. :)
Какой у Вас юзкейс? Вас интересует размер стандартной библиотеки? Точность диагностик в IDE? Наличие в языке фич, не рекомендованных обычным пользователям? Необходимость конвертировать коллекции при передаче между кодом на разных языках? Null-safety? Наличие синтаксиса для вызова монад? Неявные преобразования в языке? Макросы? Типы высших порядков? Type classes? Тьюринг-полная система типов? Еще что-то?
В зависимости от ответов на эти вопросы можно принять решение о том, что Вам лучше подходит :)
abreslav
25.02.2016 11:29+2Просто тут нет универсального ответа, потому что для кого-то стандартная библиотека в 820KB — это преимущество, например, а кому-то все равно. Кому-то без макросов никуда, а кому-то отлично… Но судя по всему, есть много людей, которых Scala на Андроиде не устраивает (по каким-то из вышеописанных параметров, надо полагать), а Kotlin устраивает.
andreich
25.02.2016 17:28ИМХО, скала отлично подходит для разработки серверов, так как язык достаточно мощный. Но для андроида он слишком медленно будет бегать на большинстве девайсов.
Razaz
23.02.2016 20:03Сейчас Koans. В целом после C# весьма комфортно, интересно было бы посмотреть еще туториалы о том, как на Kotlin создать базовое приложение со Spring.Mvc+Spring.Rest в той же Идее. А так молодцы) Наверное Kotlin самая интересная альтернатива C#.
Razaz
23.02.2016 21:14Решаю* :)
andreich
24.02.2016 13:45+1Мне кажется вы можете начать писать в стиле чистой java используя примеры для нее.
Просто потом, когда более-менее привыкнете к котлину, отрефакторите.Razaz
24.02.2016 15:25Проблема в том, что я не джавист :) Просто когда разбирался со Спрингом — был не самый приятный опыт. Особенно когда вышел Boot и часть туториалов просто не работала. Надо же еще и IDE подшаманить как я понимаю. что бы это все взлетело. Поэтому и интересуюсь каким-нибудь quick-start. Думаю будем полезно многим, кто не сильно знаком с JVM — based миром.
bashor
24.02.2016 21:27+1Попробуйте начать с этого:
https://kotlinlang.org/docs/tutorials/
http://hadihariri.com/2013/12/29/jvm-minimal-survival-guide-for-the-dotnet-developer/
ov7a
25.02.2016 15:17Почему вы решили оставить инкремент как выражение? Вроде столько копий поломано, миллион и одно собеседование с данным вопросом. Оставили бы его как statement, если нравится.
abreslav
25.02.2016 21:28Смотрели на юзкейсы, увидели, что поломается, решили оставить.
Замечу, что у нас тут не С++, и на собеседовании про инкремент спросить особо нечего. Разве что разницу между префиксным и постфиксным.
ov7a
25.02.2016 15:18Какие языки оказали сильное влияние на Kotin? Например, функциональщина вроде any, all похожа на питоновскую в противовес exists, forall из Scala.
Razaz
25.02.2016 15:40Я бы сказал что в некоторых местах подозрительно напоминает C#… c Any(), All() и разными экстеншен методами..
abreslav
25.02.2016 21:30Java, Groovy, Scala, C#, ML, F#, Gosu, Python, etc
Имена для методов стандартной библиотеки выбирались творчески, конкретно эти, кажется, из Groovy пришли, но я не уверен.
vektory79
Спасибо за открытие темы.
И первый вопрос для затравки: какие планы по улучшению быстродействия работы плагина Kotlin в Idea?
Дело в том, что если в большом проекте добавить .kt файл, то IDE начинает просто очень медленно работать. Реакция code intelligence может достигать 10-ти секунд и более. Подсветка то слетает, то опять появляется ну и т.п.
yole
Скорее всего, вы столкнулись с проблемой, специфичной для вашего проекта — у нас довольно много больших проектов, содержащих .kt файлы, и мы такого поведения не наблюдаем. Чтобы понять, что в точности у вас происходит, вы можете прислать нам CPU snapshot: https://intellij-support.jetbrains.com/hc/en-us/articles/207241235-Reporting-performance-problems