Дмитрий Жемеров yole

А что вы имеете в виду под «убирают возможность»? Мы ничего специально не убирали и не планируем.

Можно выключить: нажимаете Shift два раза, вводите Registry, в диалоге переключаете ide.win.frame.decoration в off.

Это известная проблема, связанная с переходом на новую версию JDK, мы ее чиним. Пока что вы можете скачать версию с JDK 8 с www.jetbrains.com/idea/download/other.html, в ней дизайнер работает.

Какие плагины вы имеете в виду? Наши собственные плагины сейчас всегда релизятся вместе с IDE.

Да, все это там есть.

1) В jar-файл экспортируются настройки уровня IDE. В него не попадают, например, ран-конфигурации, которые специфичны для проекта. Инспекции можно настроить по-разному для разных модулей в проекте, такую конфигурацию тоже нельзя экспортировать в jar. Ну и workflow совсем не такой удобный — нужно явно просить коллег импортировать jar (и делать это каждый раз, когда что-то меняется). В случае с шаренным .idea настройки автоматически применяются у всех, кто открыл проект, и автоматически подхватываются, когда кто-то их обновляет.

2) Вы можете добавить .idea в .git/info/exclude. Ну и нет ничего ужасного в PR, который добавит .idea в .gitignore проекта — нашими IDE пользуются достаточно людей, чтобы такие PR воспринимались вполне адекватно.

Про Consolas да, забыли рассказать. Про межстрочное расстояние в посте есть :)

Fira Code вернем обратно, он по ошибке потерялся.

Не в этом году. Ближайшие планы команды Kotlin-плагина — работа над перформансом и качеством существующих фич, а не добавление новых.

Нет, потому что наш основной механизм шаринга настроек внутри команды, работающей над одним проектом (ран-конфигураций, настроек инспекций, code style) — это именно помещение папки .idea в систему контроля версий. Мы сейчас автоматически создаем .idea/.gitignore, в который добавляются те файлы из .idea, которые содержат личные настройки. Остальные файлы рассчитаны на то, что их можно шарить через систему контроля версий.

Если вы имеете в виду Жемерова, то я в Мюнхене, у меня к сожалению не получилось приехать и выступить.

Нет, вопрос-то задавать можно, конечно, просто я не знаю, как на него отвечать. Особенно трудно с утверждениями про то, что в Clojure есть на 99% то же, что в котлине — учитывая, насколько эти языки друг на друга не похожи.

Вот, например, поддержка nullability. Мы считаем, что это преимущество. Очень многие люди, которые используют Kotlin, тоже так считают. С вашей точки зрения, это преимуществом не является. Какого продолжения разговора вы ожидаете? Я мог бы называть вам другие фичи, которые на наш взгляд являются преимуществами, но не очень понимаю, зачем это делать, если вы уже с ними со всеми ознакомились и ничего хорошего в них не нашли.

Ну я даже не знаю… задавать вопрос «зачем» в комментариях к посту, в котором мы рассказываем о том, какое распространение получил Kotlin? Зачем же, интересно, люди из Google, Pivotal, Gradle и многих других компаний вкладывают столько ресурсов в поддержку технологии, которая несёт так мало новых концепций? Возможно, потому, что продуктивность работы программиста определяется не только тем, сколько новых концепций несёт в себе язык, которым он пользуется?

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

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

Ответ на ваш вопрос вы можете найти в предпоследнем абзаце поста, который вы комментируете.

Потому что переписать 350 страниц текста на другом языке — это много работы, и не то, что можно сделать «сразу».

Насколько я знаю, нет.

Насколько я знаю, нет.

Расскажите при случае, чьими именно наемными работниками являются владельцы компании, Сергей Дмитриев и Валентин Кипятков.

Аннотация NotNull не является частью системы типов Java, и компилятор Java никак не ограничивает использование nullable-значений в выражениях, которые могут привести к NPE.

Все, что делает компания JetBrains (за исключением минимального стартового капитала, на который трое основателей жили первый год), она делает на самостоятельно заработанные деньги. Владельцы компании, практически весь ее менеджмент, вся команда Kotlin — все русские. Так что непонятно, кто тут кому «просто наемный работник».

Ну почему «не так»? Он просто ориентирован на другую целевую аудиторию, другой способ мышления.

Самый яркий пример, на мой взгляд — nullable/optional types. От программистов на Scala я слышал, что эта фича неправильная и ненужная, потому что она поддерживает один конкретный случай, а не общую концепцию монады. Для меня же наоборот, использование Option.flatMap и тому подобных вызовов для работы с опциональными значениями выглядит намного более сложно и менее интуитивно, чем котлиновский ?., а возможность создания абстракций, которые одинаково обрабатывают списки и nullable-значения, не представляет практически ниакого интереса.

Какой вам больше нравится. Можно Spring, можно vert.x, можно ktor (http://github.com/kotlin/ktor).

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

Я не знаю, что вы имеете в виду под словом «обвертка». Kotlin может транслироваться в байткод JVM (который может выполняться также на совместимых с ней виртуальных машинах, таких как Android), а также в исходный код на JavaScript и в нативный код, выполняемый вообще без виртуальной машины. У Kotin своя система типов и свои языковые фичи, несколько более сложные, чем "#define блять ;".

Пользуясь вашим определением, обвертками, кажется, следует считать все языки, не имеющие своей виртуальной машины, начиная с C++.

Котлин — это не синтаксический сахар, а полноценный язык со своей системой типов и своей семантикой. Ключевое отличие системы типов Kotlin от Java — это поддержка nullable и non-null types, то есть, возможность определять в момент компиляции, какие выражения могут приводить к NPE, и запрещать компиляцию таких выражений. Свою JVM для этого иметь не надо, достаточно иметь свой компилятор.

Буковки «JVM» в названии «Kotlin/JVM» как бы намекают, что целевой платформой для компиляции и исполнения является JVM, то есть Java Virtual Machine, то есть виртуальная машина Java.

В Scala, помимо всего того, о чем вы говорите, есть также дизайн языка. Вкладывая силы в поддержку и развитие Scala, мы могли бы решить проблемы со временем сборки, удобством отладки, тестирования и т.д., но принципиально изменить дизайн языка мы не смогли бы. А мы считаем, что в этом мире должен существовать не только язык с таким дизайном, как у Scala, но и язык с таким дизайном, как у нас.

Пожалуйста, прочитайте пост, который вы комментируете. Там вполне явно написано, под какие платформы компилируется котлин.

Язык. Со своим компилятором под три разных платформы, своей системой типов и много чем ещё.

Все хорошо :) На днях коллега на стэндапе рассказывал, что тетрис завелся.

Поправил, спасибо!

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

Но тем не менее хочется всё-таки, чтобы мир двигался куда-то вперёд :)

Вы можете найти ответ на ваш вопрос во втором абзаце записи, под которой вы оставили этот комментарий.

А что с Nemerle? Команда Nemerle уже некоторое время как не работает в JetBrains, так что вопрос надо задавать не нам.

На данный момент таких планов нет.

Пока никаких договорённостей с издательством на этот счёт нет.

Да, это заработает в Gradle 3.5.

Мы очень внимательно следим за планами Java, и на данный момент нам неизвестно о том, чтобы там планировались бы какие-то фичи, которые бы как-то конфликтовали с существующими или новыми фичами котлина. В том, что появляются фичи, которые предоставляют синтаксический сахар, аналогичный существующим фичам Kotlin (например, слово var), проблемы нет никакой вообще — .class-файлы остаются такими же, как были, и мы остаёмся с ними совместимыми так же, как раньше.

Сейчас нормального способа для этого нет (хотя я не помню, чтобы кто-то когда-то этого просил). В будущем мы планируем сделать для каждого диагностического сообщения страничку с документацией, в которой написано, в каких случаях оно возникает и как его правильно избегать, и тогда можно будет сделать навигацию с @Suppress на соответствующую страничку.