Мы были бы рады, но к сожалению не всегда понятно, какие из проблем, о которых сообщают пользователи EAP-версий — это действительно мажорные баги, которые ломают процесс тысячам пользователей. Мы пытаемся улучшить процесс разбора фидбэка так, чтобы по возможности не пропускать такие проблемы.
Про поддержку работы с проектами, где исходники лежат только на сервере, мы пока не готовы ничего анонсировать. Понятие «окружение для сборки» имеет смысл далеко не для всех проектов — сборка большинства Java проектов не зависит от окружения, а для Ruby/Python/PHP собирать часто вообще ничего не надо — поэтому у нас нет планов вводить такое понятие на уровне платформы.
На GraalVM мы конечно смотрим, но пока что мы не видим такого соотношения cost/benefit, которое оправдывало бы серьезные в него вложения.
Это известная проблема, связанная с переходом на новую версию JDK, мы ее чиним. Пока что вы можете скачать версию с JDK 8 с www.jetbrains.com/idea/download/other.html, в ней дизайнер работает.
1) В jar-файл экспортируются настройки уровня IDE. В него не попадают, например, ран-конфигурации, которые специфичны для проекта. Инспекции можно настроить по-разному для разных модулей в проекте, такую конфигурацию тоже нельзя экспортировать в jar. Ну и workflow совсем не такой удобный — нужно явно просить коллег импортировать jar (и делать это каждый раз, когда что-то меняется). В случае с шаренным .idea настройки автоматически применяются у всех, кто открыл проект, и автоматически подхватываются, когда кто-то их обновляет.
2) Вы можете добавить .idea в .git/info/exclude. Ну и нет ничего ужасного в PR, который добавит .idea в .gitignore проекта — нашими IDE пользуются достаточно людей, чтобы такие PR воспринимались вполне адекватно.
Нет, потому что наш основной механизм шаринга настроек внутри команды, работающей над одним проектом (ран-конфигураций, настроек инспекций, code style) — это именно помещение папки .idea в систему контроля версий. Мы сейчас автоматически создаем .idea/.gitignore, в который добавляются те файлы из .idea, которые содержат личные настройки. Остальные файлы рассчитаны на то, что их можно шарить через систему контроля версий.
Нет, вопрос-то задавать можно, конечно, просто я не знаю, как на него отвечать. Особенно трудно с утверждениями про то, что в Clojure есть на 99% то же, что в котлине — учитывая, насколько эти языки друг на друга не похожи.
Вот, например, поддержка nullability. Мы считаем, что это преимущество. Очень многие люди, которые используют Kotlin, тоже так считают. С вашей точки зрения, это преимуществом не является. Какого продолжения разговора вы ожидаете? Я мог бы называть вам другие фичи, которые на наш взгляд являются преимуществами, но не очень понимаю, зачем это делать, если вы уже с ними со всеми ознакомились и ничего хорошего в них не нашли.
Ну я даже не знаю… задавать вопрос «зачем» в комментариях к посту, в котором мы рассказываем о том, какое распространение получил Kotlin? Зачем же, интересно, люди из Google, Pivotal, Gradle и многих других компаний вкладывают столько ресурсов в поддержку технологии, которая несёт так мало новых концепций? Возможно, потому, что продуктивность работы программиста определяется не только тем, сколько новых концепций несёт в себе язык, которым он пользуется?
Про возможности Kotlin вы можете узнать в очень многих местах, начиная с официального сайта языка, и дальше вам уже решать, какие из этих возможностей вы считаете существенными.
На GraalVM мы конечно смотрим, но пока что мы не видим такого соотношения cost/benefit, которое оправдывало бы серьезные в него вложения.
2) Вы можете добавить .idea в .git/info/exclude. Ну и нет ничего ужасного в PR, который добавит .idea в .gitignore проекта — нашими IDE пользуются достаточно людей, чтобы такие PR воспринимались вполне адекватно.
Вот, например, поддержка nullability. Мы считаем, что это преимущество. Очень многие люди, которые используют Kotlin, тоже так считают. С вашей точки зрения, это преимуществом не является. Какого продолжения разговора вы ожидаете? Я мог бы называть вам другие фичи, которые на наш взгляд являются преимуществами, но не очень понимаю, зачем это делать, если вы уже с ними со всеми ознакомились и ничего хорошего в них не нашли.
Про возможности Kotlin вы можете узнать в очень многих местах, начиная с официального сайта языка, и дальше вам уже решать, какие из этих возможностей вы считаете существенными.