«Kotlin — язык для всех платформ»: интервью с Андреем Бреславом

JetBrains

За последний год вокруг Kotlin произошло много заметного: официальная поддержка со стороны Google и гигантский рост популярности на Android, выход версии 1.2 с поддержкой мультиплатформенных проектов и аншлаговая конференция KotlinConf в Сан-Франциско. А в итоге язык словно перешёл в другую лигу: например, в предыдущем ежегодном опросе от Stack Overflow он вообще не фигурировал, а теперь в категории «most loved languages»
оказался на втором месте. Год назад мы опубликовали интервью, в котором возглавляющий Kotlin Андрей Бреслав рассказал много интересного. А теперь, после всего произошедшего, впору было расспрашивать заново. Мы так и сделали: встречайте новое большое интервью с Андреем, которое начали как раз со сравнения «что изменилось за год». А затем обсудили, как в работе над Kotlin вдохновляют другие языки, какие возникают сложности и каково возглавлять такой проект.

Год спустя

— Предыдущее интервью начиналось со слов «2016-й выглядел прорывным годом для Kotlin». Теперь хочется начать словами «Оказывается, это были ещё цветочки, а вот 2017-й стал годом Kotlin». Возможно, в будущем всё снова померкнет в сравнении, но пока что спросим о прошлом: как этот прошедший год выглядел с вашей стороны?

— Ну, у меня по понятным причинам уже почти восемь лет каждый год — «год Kotlin». Но на самом деле, конечно, в 2017-м мы очень сильно рванули вперёд по количеству пользователей, по количеству внимания к проекту. У нас совершенно зашкаливающие по нашим меркам цифры: в 2017 году Kotlin попробовали около 700 000 человек. А если экстраполировать то, что мы видим в последние три месяца, на весь 2018-й, то к концу года получится хорошо за полтора миллиона пользователей. Это, конечно, грубая экстраполяция, и на самом деле может оказаться меньше. Тем не менее, есть ощущение, что внимания очень много.

Естественно, что его особенно много на Android, но и на серверных платформах тоже немало. В последнее время очень много интереса к Kotlin/Native, к мультиплатформенным проектам — тому, что мы анонсировали на конференции KotlinConf в ноябре. Многие люди интересуются, пробуют и задают вопросы «бизнес-уровня»: «а как нам строить свою стратегию, исходя из того, что будет Kotlin/Native»? Это всё очень приятные индикаторы. И мы, естественно, видим, что и запросов в issue tracker поступает больше, и просто вопросов по всяким нашим каналам обратной связи, и так далее, так что всё очень бодро.

— Год назад в докладе на JPoint 2017 вы перечисляли области применения Kotlin, которые кажутся вам перспективными: мобильная разработка, кроссплатформенные игры, embedded и так далее. Тогда же уточнили, что «не делаем никаких обещаний, потому что всё слишком быстро меняется». И теперь, спустя год, интересно: что в итоге поменялось, какие направления для вас приоритетны сейчас?

— Скажем так: какими-то направлениями прямо сейчас реалистично заниматься, какими-то — нет. Например, к геймдеву мы только подбираемся (в частности, потому что у нас особенно нет выходов на это комьюнити). Хотя мы буквально недавно начали довольно плотно контактировать с какими-то серьёзными игровыми движками. Embedded у нас скорее в совсем пробном варианте. А вот мобильная разработка уже в полный рост.

Это скорее вопрос текущих приоритетов, а большие направления у нас всё те же: мы готовим к релизу корутины, очень плотно смотрим на кроссплатформенную мобильную разработку, на кроссплатформенную разработку между сервером и клиентами. Естественно, отдельно Android и отдельно server-side — наши крупные приоритеты сейчас. Кроме этого, довольно важный приоритет у нас — это data science, анализ данных, и всё, что с этим связано. А embedded и геймдев, скажем так, в нашем поле внимания.

— Очевидно, что в Android-мире у вас всё очень хорошо, но в этом можно увидеть и угрозу: люди могут воспринимать Kotlin только как «язык для Android», не замечая ваши амбициозные планы. Видите ли вы в этом возможную проблему и боретесь ли как-то с ней?

— Да, у нас совершенно осознанная позиция, что Kotlin — язык для всех платформ. И действительно, многим людям может казаться, что Kotlin — это язык для Android и всё. Поэтому мы стараемся во всех коммуникациях делать акцент на том, что есть всё: есть сервер, есть Android, есть другие клиенты.

Пока это, вроде как, неплохо работает. Конечно, рост на Android у нас выше, чем на других платформах. Если в 2016-м «неандроидных» пользователей у нас было заметно больше «андроидных», то в 2017-м доля «серверных» снизилась и стала чуть больше трети, а сейчас их чуть больше четверти. Но это не потому что серверные пользователи нас бросили, а потому что андроидных много набежало.

Соответственно, мы стараемся вкладывать свои маркетинговые усилия преимущественно в то, чтобы продвигаться на других платформах. На Android продвигает Google, они отлично справляются, поэтому мы можем сфокусироваться на других областях.

— Со стороны Google сейчас много разной Kotlin-активности (проект Android KTX, добавление Kotlin в документацию, серия твитов #31daysofkotlin и так далее) — компания проводит это всё самостоятельно, или они обращаются к вам за содействием?

— На уровне маркетинга наша помощь не нужна, а вот на техническом уровне взаимодействие есть. Например, по документации мы сотрудничаем, потому что для генерации документации библиотек используется наш проект Dokka — там у ребят были какие-то реквесты, чтобы мы сделали что-то удобное для них. Собственно, мы и сделали, и, по-моему, ещё будем делать.

Другое важное направление технического сотрудничества — производительность. Мы много сотрудничаем с Google в области оптимизации производительности Kotlin как во время выполнения, так и на стадии компиляции.

— Насколько успех на Android помогает покорять другие платформы? Грубо говоря, если вы говорите фронтендерам «А вот можно компилироваться в JavaScript», Android-достижения при этом как-то сказываются?

— Я подозреваю, что фронтендерам это всё вообще не очень интересно, просто потому что это не те люди, к которым мы хотим обращаться. В этом смысле Kotlin не пытается конкурировать во фронтенде, скажем, с TypeScript, а в чистой iOS-разработке со Swift, потому что это бессмысленно. Это те рынки, где уже есть достаточно хорошие популярные языки, поэтому Kotlin не будет радикально лучше. Есть хороший язык TypeScript, есть хороший язык Kotlin, почему человек должен выбрать Kotlin, а не TypeScript — вообще не очевидно.

Поэтому мы ходим не к фронтендерам, которые пишут исключительно клиентский код, а к людям, которые хотят писать код и для клиента, и для сервера. И вот им уже довольно-таки очевидно, во-первых, что Kotlin для них полезнее любого другого языка, а во-вторых, что Kotlin — это серьёзно, и в частности, как раз потому, что на Android у него куча пользователей.

Это одна вещь. Вторая вещь: привлечение внимания приводит к тому, что люди начинают писать новые библиотеки, а уже существующие большие библиотеки обращают внимание на наш язык. Соответственно, улучшается поддержка — например, в тех вещах, которые на Android «цветут», но и за его пределами тоже используются. Вроде какого-нибудь OkHttp, которым пользуются не только на Android. Так что, безусловно, есть положительный эффект просто от того, что Kotlin становится большим языком с большим количеством пользователей. Все платформы, на которых он работает, в этом смысле выигрывают.

— В прошлом году, вскоре после введения процесса KEEP, вы говорили «хочется активно взаимодействовать с сообществом, но не хочется из-за этого тормозить», и тогда было не до конца ясно, что с этим будет. Что с этим вопросом теперь?

— Радикальных изменений в случае с KEEP нет, но у нас в процессе дизайна случились другие вещи. Как раз в результате сотрудничества с Google у нас появился такой специальный орган, группа из «трёх мудрецов», которая следит, чтобы мы не ломали обратную совместимость плохими способами. Это такой совет или комитет, состоящий из меня, Джеффри ван Гога из Google и Уилла Кука из университета Остина. Мы каждые несколько недель смотрим на изменения, которые собираемся делать в языке, и вместе думаем, какие проблемы обратной совместимости могут возникать. Большая часть внимания, в смысле развития дизайнового процесса, за это время ушла именно в эту сферу.

И мы относительно скоро опубликуем подробное описание того, какая в точности наша политика обратной совместимости, что и как мы меняем. Потому что для нас это довольно существенная штука: мы хотим, чтобы Kotlin эволюционировал. Когда пользователей много, очень велик риск «застыть в янтаре»: их много, они написали много кода, менять что-то в языке несовместимым образом страшно, потому что пользователям будет плохо.

Это абсолютно разумно, но на примере Java мы знаем, что это может привести к довольно большому legacy. Мы хотим этого избежать и хотим, чтобы язык, по возможности, всегда оставался современным. Для этого у нас есть некая политика, как мы будем постепенно избавляться от плохих идей в языке, не делая пользователям плохо. Это, наверное, самый большой прогресс: выработана эта политика, и мы её пока довольно успешно применяем.

Наша цель в том, чтобы все вещи, которые мешают и со временем оказались неудачными идеями, мы постепенно депрекейтили и со временем выбрасывали, а пользователи при этом мигрировали автоматически. То есть у нас не будет, как у Swift — «если у вас старая версия ОС, вы не можете писать на Swift версии такой-то». У нас будет постепенная миграция, когда вы можете пользоваться старой версией компилятора всегда (ну, скажем так, много лет после того, как она вышла), но весь инструментарий подталкивает вас к тому, чтобы перейти на новую версию языка, и это происходит гладко и автоматически.

— Ещё про взаимодействие с сообществом. Недавно появилась библиотека Arrow, «чтобы писать на Kotlin, но функционально». Подобные библиотеки — это полностью пользовательские инициативы, или их создатели тоже обращаются к вам за чем-то, и в них есть ваш вклад?

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

А есть библиотеки, в которые мы что-то энергично контрибьютим. Но это, в основном, проекты людей, которые если и не аффилированы с нами, то, по крайней мере, в близком контакте. Например, есть библиотека Конрада Камински spring-kotlin-coroutine с поддержкой асинхронных API Spring на корутинах. И Конрад очень много разговаривал с Ромой Елизаровым, они много всего обсуждали. Не знаю, есть ли там Ромин код, но, по крайней мере, Рома на эту библиотеку смотрел. Если я не ошибаюсь, сейчас ребята из команды Spring тоже разговаривают с Конрадом и думают, не взять ли что-нибудь из этого в полноценный Spring-фреймворк.

— За год список каналов, с помощью которых вы взаимодействуете с сообществом, пополнился конференцией KotlinConf. А насколько проведение собственной конференции влияет на сообщество по сравнению с другими каналами, что вы в итоге получили?

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

Взаимодействие с другими языками

— На приближающемся JPoint вы выступите с темой «На плечах гигантов: языки, у которых учился Kotlin», и хочется задать ряд вопросов в связи с ней.

Понятно, что инновации всегда опираются на предшествующие, и цитата из Ньютона в названии доклада тому подтверждение. Но нередко можно увидеть позицию «планшеты существовали и до iPad, поэтому Стив Джобс ничего не придумал, и зря им восхищаются». И поэтому любопытно: а в вашем случае бывает, что кто-то приходит и говорит «вот тут у вас как в Groovy и поэтому всё плохо, надо свой язык придумывать, а не в чужих подсматривать»?

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

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

Например, была эпоха, когда разговаривали про то, должны типы писаться справа от имени переменной или слева, такой типичный спор остроконечников с тупоконечниками. Такого ещё до дури: есть, например, апологеты точек с запятой или отсутствия точек с запятой. И если человек вкладывает много усилий в то, чтобы доказать, что ключевое слово «new» в языке обязательно нужно или обязательно не нужно, сразу понятно, что он человек энергичный, но не очень прошаренный.

А что до вопроса о том, кто молодец и достоин называться оригинальным дизайнером языков — есть группа людей, которым это важно, а мне просто не важно. Поэтому я в такие дискуссии не вступаю.

Такого, чтобы кто-то говорил «вы всё скопировали с Groovy и поэтому не молодцы», мало. А вот людей, которые приходят и говорят, что мы всё скопировали из Scala, много. Потому что им обидно. Ну, тут я мало чем могу помочь. Но, к счастью, обидно не тем, кто Scala делал, а тем, кто Scala пользуется (и то далеко не всем). А с Мартином Одерски у нас очень хорошие деловые отношения, мы общаемся, пересекаемся на всяких конференциях, и я даже разок ездил в гости к Мартину в университет.

Я не знаю ни одного дизайнера успешного языка, с которым разговор шёл бы не в духе «о, вы тоже сделали эту фичу, которую мы придумали, отлично, мы очень рады». И когда ребята из Facebook, занимающиеся Hack, просят нас рассказать, как у нас сделаны корутины, с прямой целью сделать точно так же, меня лично это очень радует. И когда Крис Латтнер говорит «мы взяли в Swift все хорошие идеи из других языков и совершенно этого не стыдимся», меня это тоже очень радует. Мне кажется, что это здоровый подход, а идея «язык плохой, потому что в нём мало радикально новых идей» мне не симпатична, это странная идея, попросту далёкая от нужд пользователя.

— А помимо Мартина, много ли коммуникации с теми, кто работает над другими языками? Когда в Kotlin вдохновляются чем-то из другого языка, просто смотрят, как там это сделано, или общаются с его создателями?

— На самом деле, лично общаемся гораздо меньше, чем мне хотелось бы. Я с удовольствием больше разговаривал бы с создателями других языков, но это технически непросто: все заняты.

Но, например, ежегодно разговариваем с людьми, которые делают Java, у них есть специальная конференция для этого, мы к ним ездим. Довольно много общаемся с людьми, которые делают Hack — это Эрик Мейер и компания, туда теперь перешло довольно много людей из Microsoft.

Пожалуй, кроме них и Мартина Одерски, систематически больше ни с кем не общаемся, но по отдельным вопросам бывает, и вообще мы всегда рады пообщаться. В своё время ребята из Microsoft проводили конференцию Lang.NEXT, куда съезжались разработчики современных языков — была очень интересная штука. Эрик, который это делал, теперь в Facebook, и есть очень призрачная надежда, что они ещё одну такую конференцию забацают — было бы хорошо, я бы с радостью поехал.

— В работе над Kotlin возникают систематически конкретные задачи «сесть и порисёрчить другие языки», или познания о них появляются скорее бессистемно?

— Я был бы рад, если бы мы делали это более систематически, но делать это систематически непросто, потому что там нерегулярно происходят изменения. Но есть несколько человек, которые регулярно смотрят на другие языки, включая меня и Рому Елизарова, а по определённым поводам и другие люди смотрят. Мы стараемся быть в курсе того, что происходит в других успешных языках. Скажем, много смотрим на C#, Java, Swift, TypeScript, на ту же Scala. В Scala в последнее время изменения немножко в другой сфере, но тем не менее.

Правда, мы почти не смотрим пристально на ещё не известные языки или research-языки. Такого, чтобы мы систематически смотрели, как дела в Pony или ещё в каком-нибудь research-языке, у нас, к сожалению, нет. Просто сил не хватает следить. А было бы интересно. Но когда возникают какие-то конкретные задачи, в этот момент мы можем пойти и посмотреть, какие есть по этому поводу research-языки, и в них заглянуть.

— А насколько приходится смотреть на изменения других языков в связи с тем, что вы от них как-либо зависите? Когда Java распилили на модули, на вас это сильно сказалось, или, раз всё по-прежнему компилируется в тот же байт-код, для вас мало что меняется?

— К сожалению, Project Jigsaw — это такая боль абсолютно для всех, не исключая нас. Не потому что байт-код стал другой, байт-код там плюс-минус такой же. У нас при выходе Java 9 возникли и некоторые проблемы, не связанные напрямую с Jigsaw: в «девятке» стали, наконец, проверять некоторые вещи, которых спецификация требовала давно. А мы не знали, что мы их не исполняем, и оказалось, что мы фейлимся с какими-то проблемами. Но это относительно локальная штука в уголке, а проблема, которая есть у всех — это, естественно, split-пакеты, то, что теперь нельзя в двух разных модулях иметь пакеты с одинаковым именем. Это болит у очень многих людей, у нас тоже. Нам пришлось мигрировать свои библиотеки, как-то переразбивать, что-то депрекейтить. В общем, пришлось поплясать просто из-за того, что стало нельзя иметь один и тот же пакет в двух разных JAR-файлах. С этим все получили много «удовольствия», и мы тоже получили.

— Многие отмечают сходство Kotlin и Swift, а также замечают, что это упростило мобильную разработку: Android- и iOS-разработчикам стало проще заглядывать в код друг друга. А было ли в этом какое-то намеренное желание быть похожими для общего удобства, или просто само собой получилось, что языку в 2018-м логично быть таким?

— Тут вопрос скорее к Крису Латтнеру, потому что мы-то публично показали дизайн Kotlin гораздо раньше, чем в Apple открыли Swift. А про их мотивацию я точно не знаю. Хотя нет, знаю: когда Swift дизайнился, Kotlin ещё не был официальным языком на Android. Так что, видимо, мысли «пусть будет просто туда-сюда мигрировать» ни у кого не было: мы просто не знали про Swift, а Крис не знал, что Kotlin будет популярен на Android.

А то, что какой-то набор идей в воздухе витает — это 100%. И ребята из Swift наверняка на нас смотрели, пока мы вели разработку — потому что почему бы нет? А мы сейчас совершенно сознательно смотрим на Swift, думаем, что бы такого оттуда утащить, там много отличных идей.

— В докладе будет рассказано о том, что из других языков попало в Kotlin, и возникает такой вопрос: а есть ли какая-то фича, на которую вы смотрели и хотели добавить в Kotlin, но по каким-то причинам этого не сделали?

— Таких фич, на самом деле, целый класс. Например, чего в Kotlin всё ещё нет, но когда-нибудь может появиться — это value-семантика, которая есть, например, в Swift. Но на тот момент, когда мы думали, смотрели ещё не на Swift, а скорее на какой-нибудь C#. Это не попало просто из-за того, что это сложно сделать технически. И Project Valhalla когда-нибудь состоится, и у нас с Kotlin/Native будут какие-то подвижки. Но пока у нас ещё нет value-типов, хотя есть какие-то идеи, как это могло бы выглядеть.

Полноценный pattern matching в Kotlin не попал, хотя в своё время был задизайнен. Просто потому что он, с моей точки зрения, не окупается по затратам на его поддержку в языке. Но теперь, если Брайан Гетц продолжит настаивать на pattern matching в Java, мы окажемся в интересной ситуации, когда в Java есть более сложная и выразительная фича, чем в Kotlin. С другой стороны, если какой-то язык сделал что-то раньше, чем мы — это для нас большая удача.

— Потому что он проверит, как надо делать?

— Да, потому что они сходят по граблям. Если другие это всё зарелизили, то взяли на себя риск попробовать сделать определённым образом. И мы можем послушать, что им пользователи на это ответили, и учесть их ошибки. А заодно посмотреть, насколько эта фича вообще востребована. Например, появится в Java pattern matching, мы посмотрим, пишут люди вообще на этом или не пишут, что с его помощью на самом деле делают, какие есть кейсы важные, какие нет. То же самое касается C# и всех остальных: как только кто-то выпускает какую-то фичу, мы начинаем внимательно смотреть, а как же люди её используют и на что надо обращать внимание. Если окажется, что это действительно очень важно, полезно и классно, мы, конечно, тоже сделаем.

— А когда вы делаете что-то первыми, тогда из-за обратной совместимости на порядок больше головной боли?

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

Но, например, корутины в нашем виде мы делали фактически первыми, потому что все остальные их делали немножко по другой схеме. И это был большой головняк с обратной совместимостью. Мы корутины по сей день ещё держим экспериментальными, потому что всё ещё вносим какие-то изменения, но в версии 1.3 уже собираемся их зарелизить. То есть относительно скоро они будут зафиксированы как дизайн.

Безусловно, если что-то делать первым, то поводов что-то поменять (то есть степеней свободы, угрожаюших обратной совместимости) гораздо больше.

Сложности

— Хочется поговорить о проблемных местах. Продолжая разговор про обратную совместимость: а было ли за годы работы над Kotlin принято какое-то значимое решение, о котором впоследствии пожалели, но было уже поздно менять?

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

Одна — это делегирование классов, возможность имплементировать интерфейсы делегированием. Хорошо было бы, если бы мы не зарелизили это в своё время в 1.0 и взяли побольше времени на то, чтобы это подизайнить. В 1.0 у нас ещё не было понятия экспериментальных фич. В итоге получилась очень негибкая фича, и очень сложно как-то её развить. Мы в этой области не сделали никаких позитивных шагов за два года, потому что это попросту слишком сложно, она сопротивляется. И что с этим делать, пока непонятно, будем думать дальше, как сдвинуться с этой мёртвой точки.

И вторая такая же проблемная фича — это companion objects. Там развитие какое-то есть, но это тоже слишком сложная в поддержке история, потому что много завязок в разные места. Было бы здорово, если бы мы в своё время потратили побольше времени на дизайн этой фичи. Но мы не догадались, что это такая серьёзная точка риска, и не вложили туда больше ресурсов.

— В сообществе можно услышать, что не хватает книг и материалов о Kotlin для новичков в программировании: про язык много пишут для уже знающих Java, а «посоветовать племяннику» нечего. Согласны ли вы, что ощущается дефицит? Планируется ли что-то со стороны JetBrains для его устранения?

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

А в целом мне кажется довольно естественным, что если язык исходно таргетирован на уже сформировавшихся профессионально разработчиков, то сначала появляются книги, которые нужны именно этим людям, а потом это будет расширяться. Мы видим, что постепенно расширяется и спектр университетов, преподающих Kotlin, и спектр разных онлайн-курсов и книг, и так далее. Я думаю, что постепенно это всё выровняется и станет адекватным реальному ландшафту, реальному запросу публики. Естественно, что началось с того места, где был самый большой спрос.

— Также от разработчиков можно услышать, что поддержка Kotlin со стороны тулинга пока что отстаёт от Java — а когда язык создан JetBrains, непроизвольно хочется, чтобы с тулингом всё было идеально. Согласны ли, что отставание есть, или считаете это устаревшим мифом?

— Я думаю, что тулинг, над которым работали двадцать лет, по сравнению с тулингом, над которым работали четыре года, конечно, в чём-нибудь обязательно будет лучше. Но мне кажется, что сейчас для большинства проектов котлиновский тулинг уже достаточно хорош. И, естественно, всегда можно найти место, где тулинг для какого-нибудь одного языка лучше, чем для другого, в том числе и где тулинг для Kotlin лучше. Просто потому что их пишут независимые команды, и наверняка что-то мы сделали лучше.

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

Я бы сказал так: мне кажется, что сейчас уже не осталось прямо ужасных каких-то вещей. Таких, чтобы всем мешало, большинство проектов жаловались, и их жизнь была реально хуже, чем на Java, из-за того, что у нас в тулинге что-то не доделано. Но при этом у нас очень большое пространство для роста, мы довольно энергично вкладываемся в это, и будем вкладываться ещё довольно долго.

— Роман Елизаров недавно писал, что разработчики печалятся, когда они выучили что-то сложное и хитрое, а затем прогресс всё упрощает и делает эти знания ненужными. А в итоге люди противятся хорошим вещам, которые упростили бы им же жизнь — и, в частности, не хотят принимать котлиновские корутины. Насколько вы согласны, что есть эффект сопротивления?

— Такой эффект, безусловно, есть. Но мне сложно утверждать, что причина именно в «людям кажется, что вложенные усилия были зря и их знания не нужны».

У меня есть альтернативная гипотеза, про которую тоже не знаю, насколько она верна: многим людям нужно как-то доказывать себе и окружающим, что они очень умные. Поэтому есть каста людей, которые ни на что не променяют программирование на C++ или Scala во всей полноте этих языков: это такой способ чувствовать себя очень умным. Вот человек справился с очень сложной штукой, и он будет использовать её дальше, чтобы подтверждать свою невероятную компетентность и талантливость, потому что не всякий может освоить систему такой сложности. И даже если для конкретной задачи система прагматически не обязана быть такой сложной, человеку может нравиться это делать, просто потому что «я же умею такую крутейшую вещь, а вы не умеете».

Это просто альтернативная мысль, может быть, она менее верная, чем Ромина, а может быть, они вообще обе верны одновременно, сложно сказать. Но здравая идея, по-моему, есть и там, и там.

— А Хади Харири недавно сожалел об ограничениях бесплатного режима Slack, мешающих официальному Kotlin-чату. Тут задумываешься, «не лучше ли вам держать чат в бесплатном Telegram» — и внезапно осознаёшь, что у Telegram ограничение в 10 000 участников чата, а у вас в Slack уже 15 000. А обычно это телеграмовское ограничение кажется бесконечным.

То есть с проектом таких масштабов можно уткнуться в лимиты, о которых в других проектах даже не задумываешься. Поэтому интересно: есть ли ещё какие-то потолки, о которые вы ударились головой в процессе роста?

— На самом деле, сложно сказать, где это настоящий потолок, а где просто мы не ожидали, что именно здесь и именно в этот момент будут вопросы роста. У нас не так давно закончилось место на Bintray. Раньше уже кончалось, когда был бесплатный аккаунт, а теперь на платном тоже кончилось. Не то что бы это какой-то невероятный рост, наверное, надо просто чаще удалять старые артефакты. Но, в любом случае, это тоже требует внимания.

С нагрузкой на сайт, к счастью, у нас проблем вроде бы нет. Хотя если бы были, это было бы, наверное, приятно. Какие ещё масштабы? Я думаю, что в какой-то момент у нас может начать трещать система сбора статистики, но мы ей превентивно занимаемся, чтобы она умела собирать всё, что нужно.

Ну, естественно, есть ещё наш Continuous Integration, но это связано скорее не с ростом количества пользователей, а с ростом количества людей в команде. Там 50 человек работает, понятно, что сборок много, и нам периодически нужно увеличить количество агентов просто для того, чтобы всё собиралось в какие-то разумные сроки. Заметно, что к времени сборок все чувствительны, и периодически приходится предпринимать какие-то усилия. Растёт объём кода в проекте, растёт время сборки всего проекта — когда-то мы собирались, условно, за две минуты, а теперь собираемся долго-долго, потому что нас много. Такие вещи есть.

— Ощущается ли что-то в работе над Kotlin как «самый главный челлендж»?

— Самый главный мне трудно выделить, потому что, скажем так, на разных уровнях у нас разные «самые главные челленджи».

Если на совсем стратегическом уровне — сложно выбирать приоритеты, думать, во что мы сейчас сложим 80% ресурсов. Вроде «это были корутины, а стали мультиплатформенные проекты». Такого рода приоритеты выбирать тяжело. Потому что очень много неопределённости, очень много информации не хватает, и её нельзя получить по-простому.

На техническом уровне, где код, тоже очень сложно принимать далеко идущие решения. Скажем, мы видим, что нам что-то серьёзно «жмёт» по архитектуре компилятора или по архитектуре IDE, но в каком порядке вкладывать ресурсы, сложно решать. Потому что, с одной стороны, нужно обслуживать какие-то непосредственные надобности, которые возникают просто из-за текущих проблем, а с другой, нужно вкладываться в стратегическую переделку, какой-нибудь большущий рефакторинг компилятора или IDE. Тут тяжело балансировать, там приходится много думать, экспериментировать, заходить в тупики, возвращаться и так далее.

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

Каково возглавлять язык

— Интересно узнать, каково живётся, когда возглавляешь разработку языка. Объём знаний, которые могут пригодиться в такой работе, представляется куда больше, чем человек физически может получить за жизнь. И в таком случае, например, когда начинается работа над Kotlin/Native, насколько вы лично спускаетесь на уровень железа? По какому принципу выбираете, какие технические знания надо получить, как происходит приоритезация?

— Скажем так, интуитивно. В основном мне, конечно, нужно много неглубоких знаний. С тем же Native, условно говоря, нужно знать много названий, но не обязательно детально понимать, как работают системы прерывания на каком-нибудь контроллере. Тонкости различия архитектур ARM и x86, к счастью, мне знать не надо.

При этом надо знать, что в принципе с моделями памяти в разных языках, как какие проблемы решаются, какие у нас основные компромиссы. По этому поводу я могу с людьми, которые специально внимательно смотрели, поговорить два часа и плюс-минус понять, какие у нас реальные компромиссы, как есть там-то и там-то, куда в итоге пойти и что первым попробовать. В этом отношении очень помогают идеи итеративной разработки, то есть agile в очень широком смысле.

Условно, делаем мы новую модель памяти для Native. Много вариантов: можно пойти так, сяк, и никто не знает, какой вариант лучше. Что-то гораздо сложнее реализовывать, зато, вроде бы, потенциально проще для пользователей, что-то, наоборот, реализовывать гораздо проще, а для пользователей — чем-то сложнее. А, может быть, это и хорошо, что сложнее? Много вопросов таких, не поймёшь заранее.

И ответ обычно в том, что надо просто пробовать: выбрать какую-то относительно безопасную стратегию, сделать и дать пользователям попробовать. Не гадать заранее, а узнать, каково на самом деле этим пользоваться. И если оказывается, что какая-то наша идея не срабатывает, то просто сделать по-другому. В этом смысле все наши истории про экспериментальный режим и про EAP, когда мы показываем что-то достаточно рано, хорошо работают. Мы получаем фидбек. Жить на фидбеке — гораздо проще, с ним не надо иметь никаких свойств пророка, чтобы принимать решения.

С другой стороны, конечно, есть какие-то вещи, в которые неплохо бы заглянуть. И они приоритезируются интуитивно, по ходу: «Ой, что-то я слишком много раз уже слышал про вот это, пора почитать». Я при этом действительно не в курсе многих даже более-менее устоявшихся новинок, например, по состоянию на прошлую неделю я ещё не запустил ни одного своего Docker-контейнера. Просто потому что не было ни времени этим заниматься, ни прямой необходимости. Мне любопытно узнать, как там всё устроено, но некогда. Таких вещей очень много, я ещё много чего не попробовал и не разбирался в деталях. Но когда приходит необходимость, я просто делаю, а иногда, если есть минутка и что-то очень интересно, то я про это почитаю и буду радоваться.

— Приводит ли редкость профессии language designer к «оторванности от общества»: возникает ли ощущение, что вот с Мартином Одерски можно как следует поговорить о наболевшем, а больше и не с кем обсудить?

— Нет, существует выражение «одиночество на вершине», но у меня такого нет. Во-первых, у меня всегда есть коллеги по команде, которым необходимо въехать в то же, что и мне. А во-вторых, я вообще не очень-то считаю технические разговоры частью своей именно социальной жизни. Если мне хочется с кем-нибудь поговорить, я лучше о чём-нибудь другом поговорю. Мне работы на работе хватает. В этом смысле, у меня, наверное, не очень интересный твиттер: я не веду там дискуссий на технические темы. Просто потому что вне работы я стараюсь про что-нибудь другое.

— Зачастую технари про управление проектом говорят «хочется разбираться с техническими вопросами, а не заниматься менеджерскими задачами». Сколько времени в вашей работе уходит на «техническое», а сколько на «менеджерское», и возникает ли желание минимизировать менеджерское, или обе стороны интересны?

— Скажем так, если бы у меня была параллельная жизнь, я бы с удовольствием позанимался и тем, и другим, но параллельной жизни у меня нет. И я считаю, что мои более редкие особенности лежат скорее в технической области, чем в области управления. То есть в области управления я гораздо более заменимый человек, чем в области дизайна языков. И поэтому я предпочитаю побольше делегировать в управлении и продвигаюсь на этом пути. Если какое-то время назад я сам занимался вообще всей менеджерской работой, то сейчас уже много чего делегировано, и хочу делегировать по возможности больше, чтобы управлением занимался кто-нибудь другой.

Я бы вообще с удовольствием код пописал, но у меня пока всё-таки не хватает времени писать код руками. В основном, конечно, я разговариваю, что-то смотрю и обсуждаю. А хочется и просто руками что-нибудь поделать, просто потому что приятно. В смысле именно написания кода руками я тоже абсолютно заменимый, нет никакой проблемы «если я этот код не напишу, его никто не напишет» — напишут, всё будет хорошо. Просто приятно код писать, поэтому я хочу это делать.

То есть основной приоритет у меня — вещи, в которых меня сложно заменить (то, что касается дизайна), а удовольствие мне приносит ещё и написание кода. Так что моя идеальная картина — это когда я пишу код хотя бы 20-30% времени. И по возможности практически не занимаюсь непосредственно управлением — управлением людьми, управлением проектами. Стратегией продукта я хочу заниматься, а вот такой непосредственно менеджерской работой не очень хочу. Но пока занимаюсь в каком-то объёме.

— К словам «хочется писать код»: а то, что помимо Kotlin, сейчас ещё и участвуете в стартапе Alter, отчасти как раз история про то, что там руками пишете код?

— Да, там руками. С Alter забавно получилось. Я выделил какое-то время, и в Alter не только код пишу, а ещё занимаюсь всякой конфигурационной ерундой, где, с одной стороны, я вообще совершенно заменимый. Но, с другой стороны, в условиях стартапа заменить меня не так просто: нужно заменить кем-то очень самостоятельным, зарплаты там нет, всё сложно. В общем, да, я действительно пишу код руками. Удивительным образом, даже не на Kotlin.

— А на чём?

— На JavaScript. Это, кстати, тоже был очень познавательный опыт: частично это было сознательно сделано, чтобы я разобрался, как люди сейчас пишут фронтенд и бэкенд на JS. Узнал очень много интересного, и, конечно, фейспалмы у меня были в большом количестве.

Во-первых, это был любопытный опыт, во-вторых, писать код всё-таки очень заметное удовольствие, а в-третьих, накладные расходы на управление проектом в таком объёме достаточно маленькие: во многих случаях мне проще самому написать за два часа, чем потратить час, чтобы рассказать, как это сделать, чтобы кто-то другой это написал за два часа.

Сейчас я ещё и составил учебную программу. Там очень простая идея: у нас есть какие-то задачи, которые нужны проекту, есть я, который может прочитать чужой код и дать какой-то разумный фидбэк, и если кто-то хочет на этом бесплатно поучиться — в обе стороны бесплатно, то есть мы ему ничего не заплатим, и он нам ничего не заплатит — то добро пожаловать.

Сейчас один человек уже приступил, и ещё какие-то делают тестовое задание, посмотрим, что из всего этого получится. Это такой эксперимент на стыке моих давнишних педагогических опытов с прагматической пользой, которую получим и мы, и такие обучающиеся. Потому что Alter получит код, а люди получат опыт и фидбек от человека, который что-то понимает.

— А есть ли тут мотивация «посмотрев на то, как пишут код другие, понять что-то ценное для Kotlin»?

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

— Фейспалмы, возникавшие при работе с JavaScript, породили какие-нибудь новые мысли в связи с Kotlin?

— В основном это были подкрепления имеющихся мыслей. Например, то, как в JavaScript сделано слово «await», конечно, очень грустно. Там разложены некоторые специфические грабли, на которые я совершенно неожиданно для себя наступил. Хотя если бы не так быстро всё это писал и подумал, то не наступил бы и не потратил бы потом 20 минут на отладку. В общем, хорошо, что в Kotlin нет «await» как ключевого слова, и просто не существует целого вороха проблем, которые могут быть с этим связаны. Это некое подтверждение того, что правильно сделали.

Там куча проблем, связанных с динамической типизацией, и там немного другой цикл разработки. С одной стороны, в JavaScript быстрый цикл обратной связи, потому что не надо ничего компилировать. А с другой, я много раз что-то перезапускаю и передеплоиваю на сервер, чтобы пофиксить какую-то ерунду, потому что компилятор мне не сказал про вот эту глупую ошибку. Естественно, когда я начал писать, этого было больше, со временем стало меньше. Но всё равно, хотя уже относительно много времени на этом пописал, всё равно возникают дурацкие ошибки, дурацкие опечатки. Несмотря на весь тулинг, который я использую, тесты и всё прочее, всё равно куча всякой ерунды. И это, конечно, неудобно, замедляет и раздражает.

— Предыдущее интервью заканчивалось прогнозом на следующий год: вы тогда сразу сказали, что это гадание на кофейной гуще, но в итоге слова «будет расти, как снежный ком» сбылись. А каков теперь прогноз на год вперёд?

— Сейчас прогнозировать сложнее: в прошлый раз это была умеренная халява, потому что было понятно, где будет расти больше всего. Но я могу сказать, на что мы рассчитываем.

Я рассчитываю на то, что мы получим много внимания в области Kotlin/Native и в мультиплатформенных проектах, что люди будут пробовать кроссплатформенную разработку. Сложно сказать, сколько количественно людей там будет, но хочется верить, что порядочно.

Скорее всего, Android и server-side будут расти со скоростями, сравнимыми с происходящим сейчас. Если это подтвердится, то через год увидим что-то вроде «за полтора миллиона пользователей».

Что ещё интересного случится? У нас может выстрелить ещё что-нибудь, например, наша история с data science. Мы довольно уверенно туда вкладываемся, может оказаться, что в какой-то момент набрали критическую массу, и на нас обратило внимание data science-комьюнити. Или то же самое может случиться с играми. А может не случиться. Будем смотреть.

На JPoint 2018 среди спикеров можно будет увидеть и Андрея, и других ключевых участников команды Kotlin: Роман Елизаров расскажет про корутины, а Дмитрий Жемеров выступит с темой «Идиоматичный Kotlin: от форматирования до DSL».
Также теме Kotlin DSL будет посвящён доклад Ивана Осипова (Haulmont).
Конференция пройдёт 6-7 апреля.