1) и 2) оставлю коллегам, которые занимаются JS и стандартной библиотекой. Со своей стороны скажу, что все будет хорошо. :)
3) dynamic для Java сделать можно, но это очень дорогая фича: во-первых, она сама по себе требует довольно много работы по дизайну и реализации, и во-вторых, про нее нужно все время помнить при дизайне и реализации всех остальных фич ("а что если в этом месте стоит dynamic?"). Кроме того, мы знаем, что в C# dynamic оказался намного менее востребованным, чем ожидалось. Поэтому — да, возможно, в какой-то момент мы увидим востребованные юз-кейзы, которые с dynamic решаются намного лучше, чем без него, и-таки его добавим. Но это точно не приоритет на данный момент.
4) Таких string templates у нас никогда не было, если я ничего не путаю. Ровно такой синтаксис, как в Scala, мы в 1.0 зарезервировали на будущее, и с большой вероятностью в какой-то момент поддержим.
5) Есть, и мы обязательно его опубликуем, как только закончим обсуждение внутри команды.
1) Если у вас Maven-проект, то отдельно настраивать версию библиотеки Kotlin в проекте не нужно, при импорте из Maven все само настроится. Но при этом очень желательно, чтобы версия Kotlin, на которую вы ссылаетесь в pom.xml, совпадала с версией плагина, который установлен в IDE — а эта версия не может быть разной для разных проектов.
2) Транслируется, если пометить его аннотацией @JvmField.
3) Скорее не должен. У нас есть механизм по поддержке annotation processors, через который в принципе может работать Lombok, но он пока интегрирован только в Gradle-билды и не интегрирован в Maven. Ну и казалось бы, что встроенные фичи Kotlin делают примерно весь Lombok ненужным.
4) Очень сложно говорить о востребованности каких-то фич JS-таргета, пока он существует только в экспериментальном виде. Просто нет столько кода, который мог бы их использовать, чтобы можно было делать какие-то выводы.
Решили создать по простой причине: заметили, что у нас есть IDE для такого количества прекрасных языков, а сами мы почему-то пишем все время на Java и не видим убедительной альтернативы. Ну и из предыдущего опыта было известно, что если нам самим не хватает какого-то инструмента, то с большой вероятностью он также окажется востребованным на рынке.
Вдохновлялись — да всем, что вокруг существует. C#, Groovy, Scala, в отдельных местах Python и Ruby, иногда более экзотические языки типа Gosu.
Сделать такую подсветку — это несколько часов работы максимум, так что кто-нибудь когда-нибудь наверняка сделает. Мы сами этим заниматься не планируем.
Ну ты же понимаешь, что это на самом деле не совсем так. То, как Kotlin компилируется сейчас, например, не позволяет писать на котлине полностью нативные iOS-приложения. Компилировать его так, чтобы это было можно — это вполне интересная цель, которую вполне имеет смысл планировать.
Конкретно сейчас проблема с data bindings вызвана только тем, что компилятор data bindings собран пререлизной версией котлина и падает с проектами, которые используют релизную версию. В следующем апдейте это будет исправлено.
Пока что более-менее серьезно обсуждались только expression trees как в C# 3.0. Конкретных решений пока никаких не принимали, будем смотреть на фидбэк и юзкейзы.
1) Jack и Jill решают задачу генерации Dalvik-байткода напрямую из Java, минуя Java-байткод. Насколько я понимаю, нам никто не мешает самим генерировать Dalvik-байткод, и интегрироваться с Jack и Jill для этого не нужно и не факт, что полезно.
2) Мы сейчас заканчиваем работу над поддержкой инкрементальной компиляции для Gradle, которая позволит компилировать ровно те классы, которые затронуты изменениями после предыдущей компиляции.
С LLVM главная проблема в том, что его не очень понятно как из Java использовать. Ну и свой GC, годный для использования в production — ни разу не маленькая задача.
Мысль, кстати, очень интересная, надо подумать. Мы думали в основном про варианты LLVM либо генерации кода на C, но и в том, и в другом случае ребром встает вопрос garbage collection, который в Go как раз решен.
Если отвечать на второй вопрос, то, конечно же, Kotlin отличается от Java не только синтаксисом. Например, поддержка nullability — это различие на уровне системы типов, а не синтаксиса. Фичи типа reified type parameters и delegated properties — отличия на уровне семантики. И это не говоря уже о поддержке трансляции Kotlin в JavaScript.
Собственных планов по переработке документации на сайте у нас на данный момент нет. Если вы не можете найти там какую-то конкретную информацию, то это, конечно же, баг, о котором нам нужно рассказать, и мы добавим туда информацию. Мы также следим за вопросами от пользователей и дополняем документацию на сайте, если видим, что ответа на вопрос на сайте не найти, а нужно.
Еще у нас есть книжка, в которой многие вещи объясняются более развернуто и с большим количеством примеров, чем на сайте.
Да, планируется. Мы даже зарезервировали ключевые слова async и await. Правда, по поводу сроков и деталей реализации пока что сказать ничего не можем — фича еще не задизайнена.
Мы не предполагаем, что обратная совместимость Kotlin неизбежно будет вечной. Вполне возможен вариант, что в какой-то момент выйдет Kotlin 2.0, который не будет полностью обратно совместимым с 1.x, так же, как Python 3 не полностью обратно совместим с Python 2.
Нет, потому что это не нужно — Kotlin прекрасно использует любой существующий Java-стек. Мы экспериментируем с созданием отдельных фреймворков, которые оптимальным образом используют фичи языка, но пока что у нас нет ощущения, что есть потребность в создании полного альтернативного стека.
Да, сейчас YouTrack переписывается с MPS на Kotlin. MPS там пока еще используется и какое-то время еще будет, но конкретно для задачи разработки веб-приложений он действительно оказался не идеален.
3) dynamic для Java сделать можно, но это очень дорогая фича: во-первых, она сама по себе требует довольно много работы по дизайну и реализации, и во-вторых, про нее нужно все время помнить при дизайне и реализации всех остальных фич ("а что если в этом месте стоит dynamic?"). Кроме того, мы знаем, что в C# dynamic оказался намного менее востребованным, чем ожидалось. Поэтому — да, возможно, в какой-то момент мы увидим востребованные юз-кейзы, которые с dynamic решаются намного лучше, чем без него, и-таки его добавим. Но это точно не приоритет на данный момент.
4) Таких string templates у нас никогда не было, если я ничего не путаю. Ровно такой синтаксис, как в Scala, мы в 1.0 зарезервировали на будущее, и с большой вероятностью в какой-то момент поддержим.
5) Есть, и мы обязательно его опубликуем, как только закончим обсуждение внутри команды.
2) Транслируется, если пометить его аннотацией @JvmField.
3) Скорее не должен. У нас есть механизм по поддержке annotation processors, через который в принципе может работать Lombok, но он пока интегрирован только в Gradle-билды и не интегрирован в Maven. Ну и казалось бы, что встроенные фичи Kotlin делают примерно весь Lombok ненужным.
4) Очень сложно говорить о востребованности каких-то фич JS-таргета, пока он существует только в экспериментальном виде. Просто нет столько кода, который мог бы их использовать, чтобы можно было делать какие-то выводы.
Вот еще одна реакция: developer evangelist из гугла пишет про котлин с дисклеймером, что это не отражает мнение его работодателя. https://medium.com/@CodingDoug/kotlin-android-a-brass-tacks-experiment-part-1-3e5028491bcc#.dx2f41ebm
А вообще, прежде чем можно будет всерьез говорить об официальной поддержке, нужно проделать еще очень много работы с нашей стороны. Мы стараемся. :)
Вдохновлялись — да всем, что вокруг существует. C#, Groovy, Scala, в отдельных местах Python и Ruby, иногда более экзотические языки типа Gosu.
2) Мы сейчас заканчиваем работу над поддержкой инкрементальной компиляции для Gradle, которая позволит компилировать ровно те классы, которые затронуты изменениями после предыдущей компиляции.
Еще у нас есть книжка, в которой многие вещи объясняются более развернуто и с большим количеством примеров, чем на сайте.