Kotlin язык: обучающее руководство и сравнение нового языка Android-разработки с Java

Документация Kotlin кода — Kotlin

Язык для документации Kotlin кода (являющийся аналогом Java JavaDoc) называется KDoc. По сути, KDoc
комбинирует JavaDoc синтаксис для тегов (расширенных для поддержки специфичных Kotlin конструкций) и Markdown для встроенной разметки.

Генерация документации

Утилита для генерации Kotlin документации называется Dokka. Смотрите инструкцию по использованию
Dokka README.

В Dokka есть плагины для Gradle, Maven и Ant, поэтому вы можете интегрировать создание документации в свой процесс сборки.

KDoc синтаксис

Как и JavaDoc, KDoc комментарий начинается с /** и заканчивается */. Каждая линия комментария может начинаться со звездочек, которые не считаются частью содержимого комментария.

Обычно первый параграф текста документации (параграф считается первым до первой пустой строки) — это общее описание элемента, а текст дальше является детальным описанием элемента.

Каждый тег начинается с новой строки и с символа @.

Ниже пример документации класса с использованием KDoc:

/**
 * A group of *members*.
 *
 * This class has no useful logic; it's just a documentation example.
 *
 * @param T the type of a member in this group.
 * @property name the name of this group.
 * @constructor Creates an empty group.
 */
class Group<T>(val name: String) {
    /**
     * Adds a [member] to this group.
     * @return the new size of the group.
     */
    fun add(member: T): Int { ... }
}

Теги

KDoc поддерживает следующие теги:

@param <name>

Описание аргументов функции или типов параметров класса, свойств или функций.
Для более удобного разделения названия параметра и его описания, при необходимости, можно заключать имя параметра в квадратные скобки. Два приведенных ниже синтаксиса равнозначны:

@param name description.
@param[name] description. 

@return

Описание возвращаемого функцией значения.

@constructor

Описание первичного конструктора класса.

@receiver

Описание расширения функции.

@property <name>

Описание свойства класса, имеющего указанное имя. Этот тег может использоваться для документации свойств указанных в основном кострукторе, где описание свойств прямо до их объявления выглядит нелепо.

@throws <class>, @exception <class>

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

@sample <identifier>

Добавляется в тело функции с указанным именем элемента, чтобы показать пример того, как этот элемент можно использовать.

@see <identifier>

Добавляет ссылку на спецификацию класса или метода на See Also блок документации.

@author

Определяет автора документируемого элемента.

@since

Указывает версию программного обеспечения, в которой элемент был документирован.

@suppress

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

KDoc не поддерживает @deprecated тег. Вместо него используйте @Deprecated аннотацию.
{:.note}

Встроенная разметка

Для встроенной разметки KDoc использует Markdown синтаксис, расширенный для поддержки сокращенного синтаксиса с возможностью привязки к другим элементам кода.

Привязка элементов

Для связи с элементом (классом, методом, свойством или параметром), достаточно указать его имя в квадратных скобках:

Use the method [foo] for this purpose. 

Если вы хотите ввести свое обозначение для ссылки, используйте следующий Markdown синтаксис:

Use [this method][foo] for this purpose.

Вы также можете использовать подходящее имя в ссылках. Заметьте, в отличие от JavaDoc, подходящее имя всегда использует точку для разделения компонентов, даже до имени метода:

Use [kotlin.reflect.KClass.properties] to enumerate the properties of the class.

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

Заметьте, что KDoc не имеет синтаксиса для обозначения переопределенных функций. Поскольку Kotlin инструмент генерации документации добавляет все переопределенные методы в один файл, особое обозначение переопределенных функций не требуется для корректной работы ссылок.

Документирование модулей и пакетов

Документация для модуля в целом, а также пакетов в этом модуле, создается как отдельный Markdown файл,
и путь до файла передается в Dokka с использованием параметра командной строки -include или соответствующих параметров в Ant, Maven и Gradle плагинах.

Внутри файла, документация для заголовка модуля и отдельных пакетов обозначается заголовком первого уровня. Текст заголовка должен содержать «Module <module name>» для модуля, и «Package <package qualified name>» для пакета.

Ниже приведены примеры документации модулей и пакетов:

# Module kotlin-demo

The module shows the Dokka syntax usage.

# Package org.jetbrains.kotlin.demo

Contains assorted useful stuff.

## Level 2 heading

Text after this heading is also part of documentation for `org.jetbrains.kotlin.demo`

# Package org.jetbrains.kotlin.demo2

Useful stuff in another package.

За что Kotlin так полюбили в Google и кому нужны две тысячи языков программирования

Язык программирования Kotlin, разработанный петербургской компанией JetBrains, стал официальным языком разработок для Android. Об этом официально объявили на конференции Google I/O. Командой Kotlin руководит выпускник Университета ИТМО Андрей Бреслав. Почему именно Kotlin так полюбился IT-гиганту среди многих других «молодых» языков, как и зачем вообще появляются новые языки программирования, читайте в комментариях экспертов и информационной подборке ITMO.NEWS.

Как разрабатываются языки программирования

По разных подсчетам, в мире уже более двух тысяч разных языков программирования. Для старых языков постоянно выходят обновления, а также появляются новые языки. Когда синтаксис языка не меняется, а лишь усложняется и дополняется, разработчику достаточно немного потренироваться, чтобы продолжать писать на любимом языке. Иногда же меняется сама структура языка, и тогда программисту подчас приходится переучиваться, адаптируясь к обновленному языку. Обычно переход на новую структуру идет постепенно и частями, то есть только 10-20% программного кода начинает писаться с помощью нового языка.

«Программисты не были абсолютно довольны языками С++ и Java, потому что это достаточно сложные языки, при этом первый сложнее, чем второй. Поэтому появился язык Scala, который нравится многим программистам, но и он весьма сложен. Огромный опыт компании JetBrains в создании средств разработки программ для разных языков программирования позволил за семь лет создать язык Kotlin, который полностью совместим с Java, но проще и удобнее его. Языки программирования разрабатываются постоянно, задачу сделать универсальный язык уже никто перед собой не ставит. Несмотря на это, каждый язык более эффективен в определенной области, где его чаще всего и используют. Есть даже такое направление в создании языков, когда они разрабатываются под конкретную предметную область», – прокомментировал заведующий кафедрой технологии программирования Университета ИТМО Анатолий Шалыто.

Анатолий Шалыто

Сегодня некоторые компании даже составляют свои рейтинги языков. Например, компания TIOBE, которая специализируется в оценке качества программного обеспечения, ежемесячно вычисляет индекс популярности тех или иных языков с 2001 года. В генерируемом списке 50 строчек, и чтобы язык программирования попал в индекс, разработчики должны написать соответствующее письмо в компанию. Подсчет ведется на основе данных 25 поисковых Интернет-систем. Пока в рейтинге с большим отрывом лидирует Java, за ней идет С. При этом составители списка подчеркивают, что за последний год оба языка программирования стали менее популярными, примерно на 6%. При этом TIOBE показывает, что язык С был языком №1 вплоть до 2002 года, а Java в 1997 году была на 14 месте, но уже через пять лет заменил С на первой позиции.

Отличную лекцию по истории развития языков можно послушать здесь: о том, как появились языки С, PHP, Ruby и Java рассказывает куратор академических программ «Яндекса», директор центра студенческих олимпиад факультета компьютерных наук ВШЭ Михаил Густокашин. Лектор подчеркивает, что для каждой задачи следует выбирать разный язык программирования. Например, он говорит, что для военной промышленности лучше всего писать на старом-добром Pascal – языке, который родился еще в 1970 году! Почему? Потому что он надежней. Приложения для бизнеса можно писать на Java, потому что этот язык тоже достаточно надежен, но гораздо более прост в использовании. Эксперт также подчеркивает, что важно поддерживать интерес к языку среди программистов с помощью создания сообщества разработчиков, которые пишут на этом языке. Если вокруг какого-нибудь нового языка создается инфраструктура, собираются люди, которые им пользуются, только тогда язык станет популярным. Кстати, разработчики Kotlin тоже взяли на вооружение эту стратегию.

Немного о  Kotlin

Язык программирования Kotlin начал разрабатываться в петербургской компании JetBrains в 2010 году. Официальный релиз продукта был выпущен в 2016 году. Такое название язык получил в честь острова в Финском заливе, на котором расположен Кронштадт. По интересному совпадению, название популярного языка Java – это тоже имя острова в Индонезии. Вероятно, совпадение не случайно. Как сообщается в пресс-релизе, Kotlin должен работать везде, где работает Java, и один из ориентиров был сделать такой продукт, который можно будет использовать в смешанных проектах, которые создаются на нескольких языках.

Язык программирования Kotlin. Источник: cdn-business.discourse.org

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

«Инструменты разработки, включая языки программирования, постоянно развиваются. Языки отличаются от других инструментов тем, что их довольно сложно развивать эволюционно. Новая версия языка должна поддерживать все уже существующие программы. Это ограничивает возможности развития существующих языков и создает потребность в появлении новых. Фактор, который определяет успешность нового языка программирования, это, в первую очередь, удобство для разработчиков. Кроме краткости и выразительности, Kotlin хорошо совместим с кодом на Java: можно использовать все существующие библиотеки и даже смешивать код на двух языках в одном проекте, поэтому не возникает особенных сложностей с переходом», – прокомментировал Андрей Бреслав, руководитель проекта Kotlin в JetBrains, выпускник Университета ИТМО.

Почему Google полюбил Kotlin

На официальном сайте разработчики Android пишут, что они наблюдали «восхождение» Kotlin все последние годы. «Гуглеры» не стесняются описывать этот язык как впечатляющий и лаконичный, который отрывает больше возможностей и с которым приятно работать. Он обладает повышенной производительностью: программный код на нем получается в среднем на 40% короче, чем на других языках, а также Kotlin позволяет не допускать некоторые ошибки в коде. Одним из определяющих факторов популярности Kotlin в Google стало то, что он совместим с Java, который уже используется при разработке приложений под Android.

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

«Отсутствие гарантий поддержки языка со стороны Google отпугивало многих разработчиков от перехода на Kotlin. Даже если язык очень нравится,  программист всегда думает о риске, что в какой-то момент этот язык просто перестанет работать. Теперь есть гарантия того, что работать Kotlin не перестанет, и мы ожидаем, что количество пользователей языка резко возрастет. Было бы естественно предположить, что многие компании со временем перейдут на Kotlin полностью, хотя технически их к этому ничего не вынуждает, это просто вопрос предпочтений», – подчеркнул Андрей Бреслав.

Он добавил, что Kotlin очень активно развивается. Команда разработчиков сейчас работает над билд-системой, скоростью компиляции, улучшает производительность IDE, добавляет в инструментарий новые возможности, в том числе связанные с интеграцией в Android Studio. Также идет работа над мультиплатформенными проектами (возможность компилировать один и тот же код под несколько платформ), целый ряд языковых улучшений находится в стадии дизайна.

Андрей Бреслав

В Google также подчеркнули, что их вдохновляет концепт языка Kotlin, по которому он всегда был и останется бесплатным для разработчиков, то есть open source project. Это значит, что язык не привязан к какой-либо отдельной компании, а исходный код распространяется под свободной лицензией. Загрузить продукт можно здесь. Чтобы поддерживать развитие Kotlin, компаниями Google и JetBrains будет создано некоммерческое партнерство. Также в рамках «миссии» Android очень важно, что авторы Kotlin создают вокруг своего продукта сообщество людей, которые профессионально занимаются разработкой на этом языке и любят делиться опытом. Например, в ноябре в США состоится конференция Kotlin, также разработчики могут получать ежедневные новости и советы о программном продукте, встречаться на местном уровне.

Кстати, сам проект Android Studio был разработан на базе программной среды разработки IntelliJ IDEA, которую также создали в компании JetBrains. Но несмотря на тесной сотрудничество, в петербургской компании подчеркивают, что ни о какой продаже JetBrains американскому IT-гиганту речи не идет. При этом Koltin не будет заточен только под Android. Цель компании – сделать язык программирования подходящим под разные платформы разработки.

Перейти к содержанию

язык программирования как продукт / Блог компании ProductSense / Хабр

Язык программирования — это тоже продукт. Он помогает разработчикам выражать свои идеи так, чтобы их мог интерпретировать компьютер. Может показаться, что развивать язык — это брать последние достижения теории языков программирования, реализовывать их и из года в год выкатывать разработчикам. Это не так. Егор Толстой, Kotlin Product Manager, и Андрей Бреслав, руководитель проекта Kotlin, рассказали, зачем JetBrains бесплатный язык программирования, как он устроен и откуда приходят новые пользователи. Статья вдохновлена выпуском подкаста make sense о Kotlin.

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

Мы начали делать Kotlin десять лет назад, а первый релиз вышел зимой 2016 года. Изначально он задумывался как язык, который улучшит жизнь Java-программистов. Сейчас на Kotlin пишут даже приложения для браузеров и iOS. Современный Kotlin — универсальный язык программирования с большим количеством приятных для разработчиков фич, статически типизированный, заточенный под большие проекты и поддержку крупных кодовых баз.

В серии статей мы расскажем про то, как Kotlin организован с продуктовой точки зрения, как устроен менеджмент продуктов у программистов для программистов, что такое developer experience, как его можно измерить и улучшить.

Зачем JetBrains делает бесплатный язык программирования

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

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

У JetBrains есть четыре причины заниматься созданием языка.

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

Но при этом Kotlin поддерживается в IDE от JetBrains, которые не заточены под какую-то конкретную технологию. Например, та же IntelliJ IDEA поддерживает Kotlin — и какая-то часть ее продаж приходится на Kotlin-разработчиков. Это достаточно сложно отследить, но мы видим, что среди пользователей платной версии IntelliJ IDEA их немало.

Узнаваемость бренда. Если раньше JetBrains была компанией, которая делает классные IDE, то теперь мы — компания, которая сделала Kotlin. А это совершенно другой уровень интереса — просто потому, что за кофе люди чаще обсуждают языки программирования, чем IDE. И нам это действительно помогает. Если когда-то в самом начале JetBrains был локомотивом для Kotlin, то теперь уже оба бренда помогают друг другу — и мы видим, что все больше людей знает про JetBrains благодаря Kotlin.

Kotlin как наш собственный инструмент. У нас в JetBrains много разработчиков, и от их продуктивности сильно зависит эффективность компании. Идея начать делать Kotlin вообще родилась из того, что мы не хотели продолжать использовать Java. И сейчас Kotlin используется почти во всех наших продуктах. Например, в IntelliJ IDEA на Kotlin написано 1,5 миллиона строк кода. А недавно мы запустили Space — инструмент для интегрированной работы команд, который написан на Kotlin сразу для всех платформ: Android, iOS, сервер, веб, десктоп. Ребята, которые его разрабатывают, говорят, что без Kotlin такой продукт создать было бы в разы сложнее.

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

Итог — Kotlin приносит деньги компании косвенно. Он — верхушка воронки продаж, потому что к тому моменту, когда люди задумываются о покупке наших продуктов, они уже знают JetBrains как «тех ребят, которые сделали один из самых популярных сегодня языков программирования». И это важно.

Как устроен язык программирования

Язык программирования — это не только синтаксис, но и целая система различных инструментов. Далеким от программирования людям мы объясняем это так: представьте себе Word. Так вот — мы работаем над тем, чтобы в «Word для программистов» можно было удобно описывать свои идеи и превращать их в приложения для мобильных устройств или веба. 

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

Kotlin как продукт: схема

Синтаксис. Это набор правил, по которым пишется программа. За синтаксис отвечают дизайнеры языка. Код в первую очередь пишется для людей, которые его читают и редактируют. Из этого следует две важные задачи: 

1. Нужно дать пользователям единый понятийный аппарат, который поможет понимать идеи друг друга.

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

Интегрированная среда разработки (IDE). Правильно работать с синтаксисом позволяет поддержка языка в IDE, том самом «Word для программистов». Что делает IDE:

• подсказывает подходящие по смыслу конструкции;

• подсвечивает некорректный код;

• запускает код и помогает искать в нем ошибки;

• упрощает частые преобразования.

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

Библиотеки. Есть множество библиотек для всего на свете — от асинхронного программирования до записи на диск. Пересылка данных по сети, обращение к веб-сервисам, запись или парсинг чего-то в формате JSON, общение с другими девайсами по Bluetooth — что угодно может существовать в виде библиотеки. Особняком стоит стандартная библиотека, которая поставляется с языком. Она включает в себя манипуляции с числами, строками, коллекциями и тому подобными вещами.

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

Компилятор. Это специальная программа, которая переводит код на Kotlin в машиночитаемый формат. Kotlin умеет компилировать код сразу для трех окружений — JVM, JS и Native. Это значит, что технически Kotlin можно исполнять практически на любой платформе, которую вы знаете: браузер, смартфоны, холодильник или умная колонка. 

Помимо этого компилятор делает еще много всяких полезных вещей — проверяет код на ошибки, оптимизирует его объем. 

Подробно и глубоко компилятор Kotlin мы разбирали в отдельном выпуске подкаста Podlodka.

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

Сообщество. Программы, правила, инструменты и все такое — это замечательно, но Kotlin — это в первую очередь люди. За последний год почти 6 миллионов людей работали с кодом на Kotlin, из которых 1,2 миллиона делали это регулярно.  

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

Влияние языка программирования на продукт и людей

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

Итак, на что влияет язык:

• UX продукта — от него зависит размер итогового приложения, скорость его работы, платформы, доступные для запуска. 

• Надежность и стабильность продукта. Отличный пример – billion dollar mistake.

• Создадите ли вы в целом свой продукт. В некоторых случаях разработчиков искать очень легко, а в других вам придется месяцами охотиться за редкими специалистами.

• Атмосферу и культуру вашей команды. Сообщества программистов очень отличны по своему духу. Поклонники одного языка могут быть в среднем более токсичны или, наоборот, открыты всему новому, чем поклонники другого.

Последний пункт стоит развернуть отдельно. Например, программисты на COBOL очень редко делают хипстерские сервисы, так же, как и  значимая часть программистов на С++ — у них фокус внимания с опыта конечного пользователя и красивого UI смещается в сторону технических деталей.

Но отличия видны и на менее радикальных примерах. Возьмем Java и JavaScript. На обоих языках можно писать бэкенд, но делать это будут разные люди, с разной ментальностью, подходом к работе и разной культурой. Соответственно, продукты тоже получатся разные, ведь они похожи на тех, кто их создает.

Откуда берутся новые пользователи

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

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

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

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

Приток новых пользователей идет из трех основных источников.

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

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

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

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

Анализируя сегменты, мы смотрим на их объем, динамику роста, существующие проблемы и боли, какие задачи для них Kotlin уже решает хорошо, а какие пока не очень, где стратегия выхода на рынок понятна, а где — нет. Это регулярная работа, которая помогает нам реагировать на изменения структуры всего рынка.

Классификация стадий роста продукта

Для анализа мы используем известную классификацию стадий роста продукта из книги «Crossing the Chasm». Ранние последователи у нас сейчас есть практически во всех сегментах разработки. Люди используют Kotlin для Data Science, пишут на нем игры, решения для IoT и даже занимаются научными вычислениями — физическим моделированием процессов и подобными вещами. В сегменте кроссплатформенной мобильной разработки мы только подходим к бездне, в бэкенд-разработке — перешагиваем ее, а в Android вовсю захватываем Late Majority и смотрим на Laggards.

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

Ценность инструмента для разработчиков

Ценность языка программирования сильно зависит от самого человека, от его бэкграунда и целей. И хотя в Kotlin заложено конечное количество ценностей, люди очень по-разному расставляют для себя субъективные приоритеты. Осознанный человек может говорить, что ему Kotlin нравится из-за возможности быстро обнаруживать ошибки или из-за того, что код получается короче. Но если его разговорить, окажется, что ему «просто нравится» — в целом комфортно, и все. Это признак синергии. Разные аспекты, складываясь вместе, дают гораздо большее удовольствие и комфорт, чем в языке, которым программист пользовался раньше.

Мы опираемся на следующие ключевые ценности:

Читаемость кода. Люди в реальности пишут гораздо меньше кода, чем читают. Пишем мы только тот код, который способны написать в одиночку, а читаем то, что написали многие другие разработчики. Kotlin оптимизирован для удобства чтения.

Пример типичной операции на Kotlin

Безопасность. Kotlin старается предостерегать разработчика от ошибок и поддерживать его в процессе написания кода. Это помогает удерживать его в состоянии потока, которое, с одной стороны, позволяет разработчику быстрее добиваться результата, а с другой — дает чистый приток дофамина.

Интероперабельность. Kotlin позволяет программисту использовать библиотеки, написанные на других языках. Это очень важно, потому что, несмотря на молодость языка, разработчики получают доступ к 20−25 годам работы других сообществ. С другой стороны, Kotlin очень легко интегрировать в уже существующий проект. Для этого не нужно выкидывать всю кодовую базу и переписывать с нуля — можно это делать по одному файлу.

Эти базовые ценности мы используем, чтобы выстроить value proposition (ценностное предложение) для любого сегмента. Например, в нашем кроссплатформенном мобильном SDK KMM, мы делаем упор на:

• Переиспользование одной и той же бизнес-логики на двух платформах во избежание ошибок.

• Возможность легко реализовывать функциональность, специфичную для каждой платформы, самостоятельно.

• Простое встраивание в существующие большие кодовые базы.

Кто такие менеджеры продуктов в Kotlin

Исторически в JetBrains главным инструментом менеджмента продуктов была техника догфудинга — когда сотрудники тестируют решение на себе. Например, разработчики IDEA сами принимают продуктовые решения: начиная от того, какие конкретно проблемы решать, и заканчивая тем, как именно реализовать ту или иную фичу. Это становится возможным, потому что они ежедневно используют свой продукт и регулярно сталкиваются с теми же болями, что и пользователи (подробнее см. в видео о культуре догфудинга в JetBrains).

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

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

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

Развивать язык программирования — сложная, но очень интересная задача. В этой статье мы коснулись только одной из ее составляющих — рынка языков программирования. В следующий раз я расскажу, как выглядят программисты с точки зрения менеджера продуктов: какими инструментами и методами исследовать их поведение, помогать решать их проблемы, что такое developer experience и на какие метрики языка программирования он влияет.

Статья вдохновлена выпуском подкаста make sense о Kotlin с Андрем Бреславом и Егором Толстым. В подкасте make sense Юра Агеев, основатель ProductSense, вместе с гостями говорит о том, что важно при создании продуктов. Еще несколько интересных эпизодов:

— о выстраивании отношений с командой разработки и важности технических навыков;

— об аутсорс-разработке, работе с заказчиком и развитии бизнес-мышления;

— о продуктовом мышлении у разработчиков, технических навыках у продактов и культурном коде.

Что такое Kotlin

Kotlin — это язык про­грам­ми­ро­ва­ния ком­па­нии JetBrains, кото­рый за 9 лет потес­нил Java и стал важ­ным инстру­мен­том андроид-разработчиков. Раз­бе­рём­ся, что осо­бен­но­го в Kotlin, какие у него рис­ки и с чего начать. 

🤔 Зачем понадобился ещё один язык вместо Java

На этот вопрос есть два ответа. 

Офи­ци­аль­ный ответ: в 2017 году язы­ком Kotlin поль­зо­ва­лись око­ло мил­ли­о­на про­грам­ми­стов, и им не хва­та­ло под­держ­ки на Андро­и­де. Гугл пошёл навстре­чу раз­ра­бот­чи­кам и сде­лал Kotlin при­о­ри­тет­ным язы­ком на Андроиде. 

Догад­ки и слу­хи: с 2010 года Гугл судит­ся с ком­па­ни­ей Oracle по пово­ду исполь­зо­ва­ния Java в систе­ме Андро­ид. Вот почему: 

в осно­ве пер­вых вер­сий Андро­и­да лежа­ла вир­ту­аль­ная маши­на Dalvik, 

Dalvik постро­е­на на осно­ве плат­фор­мы Apache Harmony, 

Apache Harmony — это плат­фор­ма Java, на кото­рую у Гугл нет лицензии. 

В 2010 году Oracle потре­бо­ва­ла от Гугл мил­ли­ард­ную ком­пен­са­цию и три­жды выиг­ры­ва­ла суд: в 2012, 2014 и 2015-м. Дело не закры­ва­лось, посколь­ку в Гугл отка­зы­ва­лись столь­ко пла­тить. В 2016 году иск вырос до девя­ти мил­ли­ар­дов, одна­ко суд встал на сто­ро­ну Гугл. Дело висит с 2017 года, а Гугл посте­пен­но пере­во­дит всю андроид-инфраструктуру с Java на Kotlin. 

✅ Преимущества 

Сов­ме­сти­мость с Java. Kotlin и Java мож­но исполь­зо­вать в одном про­ек­те. Для это­го у язы­ка Kotlin есть соб­ствен­ный ком­пи­ля­тор, кото­рый выда­ёт байт-код, сов­ме­сти­мый с обыч­ной Java-машиной. Полу­ча­ет­ся, что с точ­ки зре­ния Java неваж­но, из како­го язы­ка был сде­лан байт-код.

Упро­щен­ная схе­ма вза­и­мо­дей­ствия Java и Kotlin 

Выра­зи­тель­ность. Kotlin — это ком­пакт­ный язык без кус­ков избы­точ­но­го кода: 

В про­стых про­грам­мах у Kotlin про­ще син­так­сис и мень­ше вспо­мо­га­тель­ных конструкций 

В неко­то­рых слу­ча­ях код на Kotlin может быть в несколь­ко раз коро­че, чем код на Java 

Без­опас­ность. Язык Kotlin и его сре­да про­грам­ми­ро­ва­ния — это про­дукт одной ком­па­нии, кото­рая посто­ян­но обнов­ля­ет базу оши­бок и помо­га­ет раз­ра­бот­чи­кам редак­ти­ро­вать код до момен­та испол­не­ния программы. 

На эта­пе ком­пи­ля­ции в Kotlin сра­ба­ты­ва­ет null-защита: Kotlin авто­ма­ти­че­ски про­ве­ря­ет типы дан­ных, отсле­жи­ва­ет null-значения и предот­вра­ща­ет появ­ле­ние NullPointerException — рас­про­стра­нён­ной Java-уязвимости.

❌ Недостатки 

Низ­кая ско­рость. Чаще все­го раз­ра­бот­чи­ки жалу­ют­ся на непред­ска­зу­е­мую ско­рость ком­пи­ля­ции. По быст­ро­дей­ствию Kotlin усту­па­ет Java, посколь­ку в его осно­ве лежит вир­ту­аль­ная маши­на JVM — фун­да­мен­таль­ная про­грам­ма, выпу­щен­ная спе­ци­аль­но под язык Java, а не под Kotlin.

Дру­гие нюан­сы смот­ри­те в твит­те­ре Дани­и­ла Попо­ва — андроид-инженера Ави­то, кото­рый изу­ча­ет Kotlin на прак­ти­ке и рас­ска­зы­ва­ет о све­жих тех­ни­че­ских багах.  

👉 Исто­рия Дани­и­ла Попо­ва: про андроид-разработку, отказ от тим­лид­ства в Mail.ru Group и пере­ход в инже­не­ры Ави­то. 

Малень­кое сооб­ще­ство и един­ствен­ный вла­де­лец язы­ка. Kotlin всё ещё не такой попу­ляр­ный, как Java. При­чи­на в том, что Kotlin — это не про­дукт Гугл. Раз­ра­бот­чи­ки боят­ся, что через какое-то вре­мя Гугл отка­жет­ся от него, при­ду­ма­ет какую-то свою вер­сию язы­ка или поссо­рит­ся с JetBrains. 

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

В сен­тяб­ре 2020 в баг-трекере Kotlin око­ло 40 000 задач, кото­рые закры­ва­ют­ся по мере кри­тич­но­сти. До неко­то­рых задач оче­редь дохо­дит через несколь­ко лет, но есть и те, что оста­ют­ся нере­шён­ны­ми — в таких усло­ви­ях раз­ра­бот­чи­ки вынуж­де­ны искать костыль­ные реше­ния или пере­хо­дить на дру­гой язык с раз­ви­тым сообществом.

С 2002 года попу­ляр­ность Java посте­пен­но сни­жа­ет­ся, одна­ко по-прежнему на высо­ком уровне 

Для чего используется 

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

Для веб-разработки преду­смот­ре­на ком­пи­ля­ция с JavaScript и инстру­мен­ты для HTML и CSS-кода. 

Для бэкен­да преду­смот­ре­на ком­пи­ля­ция Java и Kotlin в одном про­ек­те. По отдель­но­сти Kotlin и Java сов­ме­сти­мы по умолчанию. 

Для муль­ти­плат­фор­мен­но­го про­грам­ми­ро­ва­ния преду­смот­ре­ны тех­но­ло­гии раз­ра­бот­ки интер­фей­сов в React, созда­ния сер­вер­но­го HTTP API в Ktor и адап­ти­ро­ва­ния андроид-приложений под опе­ра­ци­он­ную систе­му iOS. 

Google, Netflix, Twitter, Uber, Netflix и дру­гие ком­па­нии пере­во­дят неко­то­рые свои про­дук­ты на Kotlin. Кей­сы есть на developer.android.com в раз­де­ле «Исто­рии раз­ра­бот­чи­ков».  

Андроид-приложения с опти­ми­зи­ро­ван­ным Kotlin-кодом. Источ­ник: developer.android.com

С чего начать 

Почи­тай­те у нас ста­тью про Java — это язык, на кото­ром напи­са­но мно­же­ство при­ло­же­ний, биб­лио­тек и фрейм­вор­ков. Пере­чис­лен­ное часто исполь­зу­ет­ся в мобиль­ной раз­ра­бот­ке и в обо­зри­мом буду­щем не будет пере­во­дить­ся на Kotlin. 

Ска­чай­те IntelliJ IDEA или Android Studio. Обе про­грам­мы — это сре­да раз­ра­бот­ки под язык Kotlin. IntelliJ IDEA боль­ше под­хо­дит для сай­тов и деск­топ­ных про­грамм, а Android Studio — для раз­ра­бот­ки мобиль­ных при­ло­же­ний под андроид. 

Уста­но­ви­те пла­гин EduTools — это спе­ци­аль­ный инстру­мент, раз­ра­бо­тан­ный для изу­че­ния язы­ка Kotlin. Есть в IntelliJ IDEA и Android Studio. Позна­комь­тесь с офи­ци­аль­ным руко­вод­ством по язы­ку Kotlin. Если воз­ник­нут слож­но­сти с пере­во­дом — посмот­ри­те неофи­ци­аль­ную рус­ско­языч­ную вер­сию.

Текст и код:
Алек­сандр Бабаскин

Редак­тор:
Мак­сим Ильяхов

Кор­рек­тор:
Ира Михе­е­ва

Иллю­стра­тор:
Даня Бер­ков­ский

Вёрст­ка:
Маша Дро­но­ва

Достав­ка:
Олег Веш­кур­цев

Как петербуржцы создали язык программирования Kotlin и почему его теперь используют Android и Google

Язык программирования Kotlin, созданный петербургской компанией JetBrains, стал официальным языком для разработки на Android.

Почему Kotlin назвали в честь острова в Финском заливе, как и когда язык стал популярен среди разработчиков мобильных приложений, почему им удобно пользоваться и зачем он изначально понадобился? Маркетинг-менеджер Kotlin Роман Белов рассказал «Бумаге», как в Петербурге создавали язык, признанный Google.

Фото из архива Романа Белова

Мы начали разрабатывать Kotlin в 2010 году. К тому времени компании JetBrains было уже десять лет и основной продукт компании — JetBrains IntelliJ IDEA, полностью написанный на Java, — был уже очень большого размера. Стало понятно, что во многом Java нас не устраивает. Было несколько альтернативных языков программирования, но оказалось, что ни один из них не соответствует тем требованиям, которые мы выдвигаем к языку, на который хотели бы перейти.

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

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

В тот момент, когда придумывалось название, на JVM (Java Virtual Machine — прим. «Бумаги») существовали еще языки, названные в честь островов: Java, Ceylon. И мы подумали: какой у нас есть остров рядом? Котлин. И это название прижилось. Тут нет какой-то традиции или правила, но так случилось, какой-то более глубокой мысли за этим нет.

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

Внутри компании у нас также полная демократия: каждый программист сам решает, на каком языке писать, на Java или на Kotlin, и далеко не все переходят на Kotlin. Для меня как для маркетинг-менеджера языка JetBrains — это маленький мир. Когда в нашей большой компании все перейдут на Kotlin, тогда, наверное, и во всем мире программисты перейдут на него. Но, действительно, процент использования Kotlin в компании неизменно растет.

Чем же Kotlin так хорош? В первую очередь разработчики любят Kotlin за его краткость и выразительность. Это свойственно всем новым языкам. Раньше людей это не очень смущало, потом размер программ стал больше — люди поняли, что пишут очень много совершенно бессмысленных кусков кода только потому, что от них это требует синтаксис языка программирования.

Вторая причина в том, что он полностью совместим с Java и позволяет постепенно мигрировать с Java-приложения на Kotlin-приложение. Например, приложение Basecamp в течение полугода полностью мигрировало с Java на Kotlin.

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

В JetBrains мы не занимаемся Android-разработкой и изначально никто не думал, что Kotlin будет языком, который так удачно подойдет для целей Android-разработчиков. Но в какой-то момент оказалось, что Android застрял на Java 6 и очень многие новые фичи Java на Android недоступны. Тогда прогрессивные разработчики обратили внимание на Kotlin.

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

Год назад у нас произошло довольно большое событие: система сборки Gradle, с помощью которой собираются все приложения для Android, объявила о переходе на Kotlin.

В каком-то смысле история с Kotlin на Android — совершенно сказочная и хрестоматийная: мы просто делали язык программирования, и он очень нравился разработчикам. Это история про движение снизу вверх, а не наоборот. Разработчики давно просили Google поддержать Kotlin. И Google к ним прислушался.

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

В компании мы начали применять Kotlin года с 2012-го, но официальный релиз языка был 17 февраля 2016 года. До этого времени конструкции языка активно менялись и поддерживать код на Kotlin было достаточно проблематично. Надо понимать, что развитие языков программирования требует большого внимания к обратной совместимости. И когда мы заявили о релизе, взяли на себя обязательство по обратной совместимости: по тому, что новый код будет совместим на бинарном уровне со старым. И мы эти обязательства выполняем.

Сейчас язык Kotlin в своих приложениях используют такие российские компании, как Avito и «Рокет Банк». За прошлый год Kotlin опробовали 160 тысяч программистов. До сегодняшнего дня Kotlin показывал экспоненциальный рост по числу программистов, и, думаю, объявление Google поможет нам продолжить этот рост.

Язык Kotlin – Факультет компьютерных наук – Национальный исследовательский университет «Высшая школа экономики»

Преподаватель

Kotlin — активно развивающийся язык программирования для платформы JVM. Этот язык создан прежде всего для того, чтобы упрощать и ускорять процесс разработки для специалистов, использующих Java. Язык полностью совместим с Java, в одном проекте можно использовать оба языка, общие библиотеки. Вместе с тем, код на Kotlin более компактен и безопасен. Язык довольно прост в освоении, но содержит массу интересных возможностей и особенностей, которые присущи языкам, предполагающим, что любая языковая конструкция является выражением (как, например, Python). Мы считаем, что изучение этого языка будет хорошим вложением в свое будущее (да и просто интересно). 

Расписание: 
по пятницам с 15.10 до 18.00
c 25.01 по 22.03 — ауд. 432
с 12.04 по 14.06 — ауд. 432 (17 мая — ауд. 400)

Для кого этот курс: Для студентов 2-4 курсов бакалавриата, которые уже умеют программировать, заинтересованы в изучении новых перспективных технологии, планируют работать (или уже подрабатывают в свободное от учебы время) как программисты-практики, думают о том, каким образом повысить эффективность процесса программирования. Студенты первого курса могут записываться на курс, но должны предварительно хорошо рассчитать свои силы.

Требования: Умение программировать хотя бы на одном языке программирования высокого уровня (Java, C#, C++, Python). Язык Kotlin работает в среде JRE, а потому знание именно языка Java и особенностей виртуальной машины будет большим плюсом.

Организация курса: Курс продлится 16 недель. Еженедельно нужно будет посетить одно занятие и выполнить домашнее задание. Каждое занятие будет длиться 2 пары и состоять из теоретической и практической частей. Практика будет занимать большую часть времени. На занятии будут разбираться конкретные «фишки» языка. От студентов ожидается самостоятельность при решении задач, активное взаимодействие друг с другом. Предполагается, что студенты будут приносить с собой на занятие свои портативные компьютеры с настроенной средой IntelliJ IDEA версии не ниже 2017.3 с установленным расширением для разработки на языке Kotlin новейшей версии.

Предварительный список тем курса:

• Базовый синтаксис языка. Основные управляющие конструкции.
• Система типов.
• Массивы, диапазоны, строки, коллекции.
• Операторы.
• Объектно-ориентированное программирование с использованием языка Kotlin. Разбор конкретных приёмов и задач.
• Функциональное программирование с использованием языка Kotlin. Разбор конкретных приёмов и задач.
• Инструменты обобщенного программирования в языке.
• Разработка предметно-ориентированных языков с использованием языка Kotlin.
• Использование языка Kotlin совместно с Java.
• Другие темы. 

Предварительно в рамках курса запланированы доклады от приглашенных лекторов. Их темы будут определены позднее.

Как будут выставляться оценки: Каждую неделю студенты будут выполнять задания в аудитории. Будут предложены дополнительные задачки для решения дома. Эти задачи составят 0,7 от накопленной оценки. Еще 0,3 даёт большое домашнее задание, выполняемое в середине курса. Экзамен, завершающий курс, имеет вес 0,2, а накопленная оценка составляет 0,8 от итоговой. Экзамен — тест по пройденному материалу.

Литература:

1. Книга: Dmitry Jemerov, Svetlana Isakova — Kotlin in Action. 2017, Manning Publications. ISBN 9781617293290
2. Сайт с материалами по языку 

интервью с Андреем Бреславом — JUG.ru

За последний год вокруг 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 апреля.

Почему Kotlin — мой следующий язык программирования | Майк Хирн

Kotlin — это новый язык программирования от JetBrains, производителя лучших в мире IDE. После долгих поисков я остановился на нем как на языке программирования, который, вероятно, буду использовать в ближайшие 5–10 лет или около того.

Мне очень нравится Kotlin, и я думаю, что это будет очень успешный проект. Кто-то, кто видел, как я использую его в своей работе с открытым исходным кодом, попросил меня написать об этом, поэтому в этой статье я объясню, почему я считаю Kotlin хорошим.Затем я расскажу о некоторых проблемах и сбоях, с которыми вы можете столкнуться, если начнете использовать его сегодня. Наконец, я утверждаю, что теперь на сцене появился Kotlin, и вам следует подумать об использовании JVM, если вы еще этого не сделали (например, потому что вы используете Go или Node).

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

Я начну с того, что расскажу вам о других вещах, потому что исследование 2013 года показало, что языковые функции имеют мало значения по сравнению с проблемами экосистемы, когда разработчики оценивают языки программирования.Это согласуется с моим собственным опытом, так что приступим:

Kotlin компилируется в байт-код JVM или JavaScript . Это не тот язык, на котором вы будете писать ядро. Он представляет наибольший интерес для людей, которые сегодня работают с Java, хотя он может понравиться всем программистам, использующим среду выполнения со сборкой мусора, включая людей, которые в настоящее время используют Scala, Go, Python, Ruby и JavaScript.

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

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

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

Это доступно, и его можно выучить за несколько часов , просто прочитав справочник по языку.Синтаксис скудный и интуитивно понятный. Kotlin очень похож на Scala, но проще. В языке хорошо сочетаются лаконичность и удобочитаемость.

Он не навязывает никакой особой философии программирования , такой как чрезмерно функциональная или ООП-стилизация.

Это не требует дополнительных затрат времени выполнения. Стандартная библиотека небольшая и компактная: она состоит в основном из специализированных расширений стандартной библиотеки Java. Интенсивное использование встраивания во время компиляции означает, что функциональные конструкции, такие как конвейеры map / filter / reduce, компилируются аналогично императивной версии того же кода.

В сочетании с появлением таких фреймворков, как Anko и Kovenant, эта легкость ресурсов означает, что Kotlin начинает становиться популярным среди разработчиков Android. . Если вы работаете над Android, скоро вы попадете в хорошую компанию. Вы можете прочитать отчет разработчика Square об их опыте работы с Kotlin и Android.

Kotlin позволяет вам продолжать использовать инструменты повышения производительности. Если вы используете IntelliJ, взаимодействие IDE будет полностью бесшовным. : код можно рефакторировать, искать, перемещаться и автоматически завершать, как если бы код Kotlin был Java, и наоборот.Имеется полная поддержка отладки, модульного тестирования, профилирования и так далее.

Помимо Android, я думаю, что Kotlin очень подходит для корпоративных магазинов Java . Если вы проводите весь день, работая над большими базами кода Java в еще более крупных компаниях, вам следует изучить Kotlin, потому что:

• Он имеет сильную коммерческую поддержку от авторитетной компании . JetBrains привержена проекту, над ним работает большая и высококвалифицированная команда, имеет стабильную бизнес-модель и даже конвертирует части своего собственного флагманского продукта для его использования. Вряд ли в ближайшее время от Котлина откажутся.
• Внедрение Kotlin сопряжено с низким риском : он может быть опробован в небольшой части вашей кодовой базы одним или двумя энтузиастами, не нарушая остальную часть вашего проекта: классы Kotlin экспортируют Java API, который выглядит идентично обычному Код Java.
• Поскольку Kotlin фокусируется на удобочитаемом синтаксисе, проверка кода не является проблемой : они все еще могут выполняться членами команды, которые не знакомы с языком.
• Он нацелен на Java 6 , поэтому вы можете использовать его, даже если ваше развертывание затрудняет обновление до новой JVM.

Ранее в этом году я представил Kotlin группе архитекторов Java и .NET в крупной перестраховочной компании Swiss Re. Я начал с определения простого Java-класса с несколькими полями, toString, equals, hashCode и т. Д. Это было около 50 строк кода. К тому времени, когда мы закончили преобразование его в Kotlin (в основном автоматически), он сократился до одной строки кода. Затем я продемонстрировал другие функции экономии времени. Они были полны энтузиазма и рассматривали его как потенциально сильного конкурента C # для их собственных проектов.

Я думаю, что Kotlin — лучшее место для корпоративных Java-разработчиков, поэтому, хотя Kotlin бесплатен, я ожидаю, что JetBrains выиграет от увеличения продаж коммерческой версии их IDE. Это будет стимулировать их продолжать улучшать его в соответствии с пожеланиями своих клиентов.

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

Язык программирования Kotlin: как Google использует его для устранения ошибок кода, вызывающих большинство сбоев

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

Google поощряет всех разработчиков Android использовать Kotlin после того, как в 2019 году было объявлено, что с этого момента разработка Android будет осуществляться «в первую очередь на Kotlin», а не на Java, которая исторически была приоритетным языком для разработки приложений для Android.

Объявив на прошлой неделе о новом бесплатном курсе разработки Android на Kotlin для новичков, Google заявила, что 70% из 1000 лучших приложений Android написаны на Kotlin, и одно из них принадлежит команде, которая разрабатывает приложение Google Home для Android.

SEE: Лучшие ИТ-сертификаты для увеличения зарплаты (бесплатный PDF)

Приложение Google Home еще не полностью написано на Kotlin, но по состоянию на июнь около 30% кодовой базы было переписано на Kotlin из устаревшего кода Java.Kotlin также поощряется за все новые функции в приложении.

Переход на Котлин имел два основных эффекта. Во-первых, он уменьшил количество исключений NullPointerExceptions на 33% благодаря системе типов Kotlin. Этот тип ошибок является основной причиной сбоев приложений в Google Play, поэтому их уменьшение может существенно повлиять на восприятие пользователями приложений Android.

«Поскольку Kotlin может сделать допуски пустыми значениями частью языка, можно избежать сложных ситуаций, например, когда непоследовательное использование аннотаций допустимости пустых значений в Java может привести к пропущенной ошибке», — объясняет Google.

Kotlin также помог разработчикам приложений Google Home стать более продуктивными, поскольку для этого требуется гораздо меньше кода по сравнению с эквивалентом существующего кода Java. Google указывает на использование классов данных и плагина Parcelize в качестве примера.

«Класс, который состоял из 126 рукописных строк в Java, теперь может быть представлен всего в 23 строках в Kotlin — сокращение на 80%», — заявляет компания.

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

SEE: Рейтинг языков программирования: R возвращается, но есть споры о его росте

Команда Google Home постепенно добавляла библиотеки Jetpack, которые заменяют индивидуальные решения. Поскольку эти библиотеки помогают разработчикам кодировать менее подробным образом, они помогли сделать код более читаемым для разработчиков, анализирующих код, ранее написанный другими членами команды.

Продвижение Kotlin, созданного чешским производителем IDE JetBrains, является частью приверженности Google языку для разработки приложений Android.

В соответствии с политикой Google Kotlin-first, компания обязалась обеспечить лучшую поддержку Kotlin. Хотя Android Studio IDE поддерживает как Kotlin, так и Java, библиотеки Jetpack поддерживают исключительно Kotlin, а новые учебные материалы и образцы, которые определенно доступны только для Kotlin, могут быть доступны только для Java. В настоящее время у Google есть 60 приложений, написанных на Kotlin, в том числе Maps, Home, Play, Pay и Drive.

Ваше полное руководство по языку программирования Kotlin

При наличии более 600 языков программирования процесс выбора подходящего для изучения или разработки проекта стал настоящей проблемой.

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

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

Основы Kotlin

Язык программирования Kotlin сегодня довольно популярен. Давайте начнем с основ и узнаем, что такое Kotlin, как он появился и какие компании создают свои решения на этом языке.

Что такое Котлин?

Kotlin — это язык программирования с открытым исходным кодом, история которого началась в 2016 году. Этот язык разработан JetBrains, которая работает над тем, чтобы сделать Kotlin основным языком программирования для Android и iOS.

Язык программирования Kotlin работает на виртуальной машине Java (JVM), что делает его прямым конкурентом более широко известной и зрелой Java с более чем 20-летней историей.Оба языка могут использоваться в одних и тех же сферах, включая серверные, клиентские, веб-разработки и разработки для Android.

Сочетание мощных функций с чистым кодом заставляет программистов из разных отраслей обращать внимание на Kotlin.

Источник

В 2019 году произошел переломный момент в развитии Kotlin. Google назвал его предпочтительным языком программирования для разработки приложений Android, что повысило его статус в глазах многих.

Какие компании используют Котлин?

Kotlin стал популярным с момента его первого запуска.Благодаря признанию Google он получил широкое признание. Фактически, 66% разработчиков говорят, что используют Kotlin для разработки под Android.

Если мы посмотрим на компании, которые признают Kotlin языком программирования с огромным потенциалом, мы увидим такие всемирно известные имена, как Google, Atlassian, Pinterest, Kickstarter, Uber, Netflix и многие другие. Нет никаких сомнений в том, что в ближайшие годы все больше и больше компаний будут выбирать Kotlin для своих проектов.

Для чего используется Котлин?

Kotlin — это язык программирования общего назначения, то есть его можно применять в самых разных сферах.Обычно Kotlin используется для кроссплатформенной мобильной разработки, разработки на Android, JavaScript и на стороне сервера. Давайте исследуем каждый аспект, для которого Kotlin подходит.

Кроссплатформенная мобильная разработка

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

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

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

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

Разработка под Android

До появления Kotlin в 2016 году все приложения для Android писались с помощью Java. И никто даже не подозревал, что им нужна замена языку с многолетним быстрым ростом. Пока не был выпущен Kotlin, началось неизменное противостояние Kotlin vs. Java.

Kotlin представил новый способ создания приложений для Android. Разработчикам больше не нужно использовать Java, устоявшийся язык, но с множеством проблем. Несмотря на то, что некоторые проблемы были решены в Java 8 и затем решены в Java 9 и Java 10, его популярность пошатнулась.

Основным преимуществом Kotlin при разработке Android является совместимость с JDK 6, что означает, что разработчики могут разрабатывать решения для старых устройств.Другие причины, по которым многие разработчики Android обратились к Kotlin, включают высокую производительность, совместимость, крошечную библиотеку времени выполнения и быструю компиляцию.

Кроме того, язык программирования Kotlin может использоваться в тех же проектах вместе с Java. Поэтому нет необходимости перестраивать весь проект с помощью Kotlin. Можно проверить основы, написав некоторые функции в Kotlin и посмотрев, как все пойдет.

Разработка JavaScript

Как вы уже знаете, Kotlin может работать на виртуальной машине, а это означает, что вы можете создать код в Kotlin и использовать его транспилеры для изменения его на другой язык.Однако виртуальная машина поддерживает не все среды, включая встроенные системы и браузеры. Вот почему для запуска приложения в браузере нам нужно использовать JavaScript.

Если вы не хотите писать код на двух разных языках программирования, вы можете скомпилировать код Kotlin в JavaScript. Таким образом, можно использовать код как для клиентских, так и для серверных веб-разработок.

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

Разработка на стороне сервера

Kotlin — это не только язык программирования для разработки под Android. По данным JetBrains, язык используется в двух направлениях: Android и серверные разработки. Такой подход уже используют многие компании, в том числе Google, Hexagon, Gradle и так далее.

Kotlin отлично подходит для сложных проектов, которые сильно зависят от шаблонов и логики. Устраняя шаблон, Kotlin значительно уменьшает размер кода по сравнению с Java. Все это приводит к менее затратному процессу разработки и упрощению поддержки проекта.

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

Котлин против Java

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

Ниже вы можете найти основные различия между ними и узнать, для каких задач каждый из них лучше.

1. Краткое изложение кода

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

У программистов нет проблем с проверкой и изменением кода, написанного другими специалистами. Это особенно важно при реализации сложных проектов, когда команда разработчиков растет. Интерфейс типов, интеллектуальное приведение типов, классы данных и свойства помогают достичь высокого уровня краткости.

Источник

2.

Функциональная совместимость

Взаимодействие, вероятно, одна из самых привлекательных особенностей языка программирования Kotlin.С самого начала его разработки создатели Kotlin поставили цель сделать каждую библиотеку доступной для программистов Kotlin. Это позволяет писать некоторые части кода, которые без проблем работают с кодом Java. Это значительно упрощает процесс перехода с Java на Kotlin во время разработки.

3. Нулевая безопасность

Когда мы говорим о разработке Android, встроенная нулевая безопасность делает Kotlin очевидным лидером. NullPointerException — одна из основных причин серьезных ошибок в Android, поскольку Java позволяет разработчикам назначать нулевое значение ссылке на объект.В большинстве случаев из-за таких значений происходит сбой приложения Android.

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

4. Время компиляции и производительность

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

Два языка программирования имеют различие в их компиляции. Java компилируется на 10-15% быстрее, чем его партнер в чистых сборках. Тем не менее, в инкрементных компиляциях, когда компилируется только код с модификациями, а не вся сборка, Kotlin работает немного лучше. Как правило, Kotlin лучше приспособлен для функционального программирования.

5. Проверенные исключения

Это еще один момент, в котором два языка программирования отличаются. В Java такие выражения проверяются в процессе компиляции.Если в методе есть такое выражение, он должен либо обработать его, либо разработчикам необходимо указать их с помощью ключевого слова « throws».

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

6. Делегация

В

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

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

7. Классы данных

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

Kotlin подходит к задаче с другой точки зрения. Включив ключевое слово «data» в определение класса, вы можете избежать настройки всего вручную. Компилятор берет на себя задачу и автоматически генерирует все необходимые геттеры и сеттеры.

И снова эта функция делает Kotlin более экономичным по времени языком программирования по сравнению с Java, который требует выполнения большого количества ручного кодирования.

8. Сообщество

За более чем двадцатилетний период существования на рынке неудивительно, что сообщество Java больше по сравнению с Kotlin.

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

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

Заключение

Никто не мог даже предсказать, что новый язык станет настолько популярным за такое короткое время.Не так давно Java считался основным языком разработки под Android.

Сейчас он уступает позиции Kotlin, языку, который лучше приспособлен для удовлетворения потребностей современной индустрии. Основная причина его создания — сделать разработку цифровых продуктов плавной, быстрой и рентабельной.

Ниже вы можете увидеть таблицу, в которой обобщена вся упомянутая в статье информация:

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

Поскольку JetBrains и Google так активно продвигают Kotlin, нет никаких сомнений в том, что мы будем много слышать об этом языке программирования в будущем, и с его помощью будет разработано много новых и крупных проектов.

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

Kotlin Учебное пособие для начинающих | Learn Kotlin

Kotlin — это язык программирования со статической типизацией, разработанный JetBrains. Если у вас есть базовые знания Java, вы сможете быстро изучить Kotlin. Этот учебник Kotlin предназначен для начинающих, поэтому вы сможете понять программирование на Kotlin, даже если у вас нет знаний о Java.

Kotlin и Java совместимы, что означает, что вы можете использовать их вместе в проекте, а также можете эффективно переписать код Java на Kotlin.Синтаксис Kotlin лаконичнее, чем Java. В этом руководстве вы узнаете, зачем использовать Kotlin, каковы его преимущества, а также несколько руководств по различным темам Kotlin.

Особенности Kotlin

Лаконично: Kotlin лаконичнее, чем Java, вам потребуется написать примерно на 40% меньше строк кода по сравнению с Java.

Взаимодействие: Kotlin хорошо совместим с Java. Вы не столкнетесь с какими-либо трудностями при использовании Kotlin в проекте Java.

Открытый исходный код: Kotlin — это язык программирования с открытым исходным кодом.

Trust: Вы можете доверять kotlin, поскольку он разработан популярной и известной компанией JetBrains. JetBrains известен созданием нескольких инструментов разработки. Популярная Java IDE IntelliJ IDEA разработана этой же компанией.

Многофункциональный: Kotlin предоставляет несколько расширенных функций, таких как перегрузка оператора, лямбда-выражения, строковые шаблоны и т. Д.

Easy: Kotlin — простой в освоении язык программирования. Если у вас есть опыт работы с Java, вам будет легко изучить Kotlin.

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

Kotlin Учебники

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

Начало работы

1. Создайте и запустите свой первый проект Kotlin в Eclipse IDE
2. Создайте и запустите свой первый проект Kotlin в IntelliJ IDEA
3. Первая программа Kotlin — Hello World

Основы Kotlin

1. Котлин Ключевые слова
2. Переменные Котлина
3. Котлинское литье
4. Операторы Котлина
5. Kotlin Input Output
6. Kotlin Комментарии

Kotlin String Tutorial

1. Котлин Строка

Kotlin Array Учебники

1. Котлин Массив
2. Котлин Диапазон

Учебники Kotlin Control Flow

1. Котлин, если выражение
2. Котлин при выражении
3. Котлин для петли
4. Котлин, пока цикл
5. цикл Kotlin do-while
6. Котлин продолжение
7. Котлин перерыв

Руководства по функциям Kotlin

1. Котлин Функция
2. Рекурсия Котлина
3. Kotlin по умолчанию и именованные аргументы
4. Лямбда-функции
5. Функция высшего порядка

Учебники по обработке исключений Kotlin

1. Обработка исключений
2. Котлин попробовать поймать
3. Блоки с несколькими захватами
4. Вложенная попытка поймать
5. Вывести ключевое слово
6. Kotlin попробуйте выражение

Kotlin OOP Учебники

1. Класс и объекты
2. Конструкторы Котлина
3. Наследование Котлина
4. Модификаторы видимости
5. Котлин абстрактный класс
6. Интерфейсы Kotlin
7. Вложенный и внутренний класс
8. Класс данных Kotlin
9. Герметичный класс Kotlin

Далее ❯

JetBrains / kotlin: язык программирования Kotlin

Добро пожаловать в Котлин!
Это статически типизированный язык программирования с открытым исходным кодом, поддерживаемый и разрабатываемый JetBrains и участниками с открытым исходным кодом.

Полезные ссылки:

Kotlin Многоплатформенные возможности

Поддержка мультиплатформенного программирования — одно из ключевых преимуществ Kotlin. Это сокращает время, затрачиваемое на написание и поддержку одного и того же кода для разных платформ, сохраняя гибкость и преимущества нативного программирования.

Монтажник Котлин

Требования к среде сборки

Для сборки дистрибутива Kotlin вам необходимо:

• JDK 1.6, 1.7, 1.8 и 9

• Установите следующие переменные среды:

    JAVA_HOME = "путь к JDK 1.8"
    JDK_16 = "путь к JDK 1.6"
    JDK_17 = "путь к JDK 1.7"
    JDK_18 = "путь к JDK 1.8"
    JDK_9 = "путь к JDK 9"
    

Для локальной разработки, если вы не работаете над генерацией байт-кода или стандартной библиотекой, можно установить только JDK 1.8 и JDK 9 и указать переменные среды JDK_16 и JDK_17 в JDK 1.8 установка.

Вы также можете использовать свойства Gradle для установки переменных JDK_ * .

Примечание. JDK 6 для MacOS недоступен на сайте Oracle. Вы можете установить его на

 $ кран для домашнего пивоварения / бочонка
$ brew install --cask java6 

В Windows вам может потребоваться добавить параметр длинных путей в репо:

  git config core.longpaths true
  

Корпус

Проект построен на Gradle. Запустите Gradle, чтобы собрать проект и запустить тесты
используя следующую команду в Unix / macOS:

 ./ gradlew <параметры-задачи>
  

или следующую команду в Windows:

  gradlew 
  

В первой конфигурации проекта gradle загрузит и настроит зависимости на

.

• intellij-core является частью компилятора командной строки и содержит только необходимые API.
• idea-full — это полноценная версия IntelliJ IDEA Community Edition для использования в модуле расширения.

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

  ./gradlew -Dhttp.socketTimeout = 60000 -Dhttp.connectionTimeout = 60000
  

Важные задачи Gradle

• clean — результаты чистой сборки
• dist — собирает дистрибутив компилятора в папку dist / kotlinc /
• ideaPlugin — собирает дистрибутив плагина Kotlin IDEA в папку dist / artifacts / ideaPlugin / Kotlin /
• install — сборка и установка всех общедоступных артефактов в локальный репозиторий maven
• runIde — создайте плагин IDEA и запустите с ним IDEA
• coreLibsTest — сборка и запуск stdlib, рефлексия и тесты kotlin-test
• gradlePluginTest — сборка и запуск тестов плагина gradle
• compilerTest — собрать и запустить все тесты компилятора
• ideaPluginTest — сборка и запуск всех тестов плагинов IDEA

Для воспроизведения сборки TeamCity используйте флаг -Pteamcity = true . Локальные сборки не запускают proguard и по умолчанию отключено сжатие jar.

ДОПОЛНИТЕЛЬНО: Некоторые артефакты, в основном подключаемые модули Maven, создаются отдельно с помощью Maven.
За подробностями обращайтесь к библиотекам / ReadMe.md.

Сборка для разных версий IntelliJ IDEA и Android Studio

Плагин

Kotlin предназначен для работы с несколькими последними версиями IntelliJ IDEA и Android Studio. Каждая платформа может иметь свой набор функций и может предоставлять немного другой API.Вместо использования нескольких параллельных ветвей Git проект хранит все в одной ветке, но файлы могут иметь аналоги с расширениями версий (* .as32, * .172, * .181). Ожидается, что основной файл будет заменен на его копию при настройке на платформу, отличную от стандартной.

Более подробное описание этой схемы можно найти на https://github.com/JetBrains/bunches/blob/master/ReadMe.md.

Обычно нет необходимости заботиться о нескольких платформах, поскольку по умолчанию все функции включены везде. Дополнительные аналоги должны быть созданы, если есть ожидаемая разница в поведении или требуется несовместимое использование API. и нет разумного обходного пути для сохранения совместимости источников. Плагин Kotlin содержит проверку перед фиксацией, которая показывает предупреждение, если файл был обновлен без его аналогов.

Разработка для определенной платформы возможна после «переключения», которое может быть выполнено с помощью Bunch Tool из командной строки.

 cd kotlin-project-dir

# переход на IntelliJ Idea 2019.1
переключатель связки 191 

Работа с проектом в IntelliJ IDEA

Для работы с проектом Kotlin требуется как минимум IntelliJ IDEA 2019.1. Вы можете скачать IntelliJ IDEA 2019.1 здесь.

После клонирования проекта, чтобы импортировать проект в IntelliJ, выберите каталог проекта в диалоговом окне «Открыть проект». Затем после открытия проекта выберите
Файл -> Новый -> Модуль из существующих источников . .. в меню и выберите сборку .Файл gradle.kts в корневой папке проекта.

В диалоговом окне импорта выберите использовать обертку градиента по умолчанию .

Чтобы иметь возможность легко запускать тесты из IntelliJ, отметьте Delegate IDE build / run actions to Gradle и выберите Gradle Test Runner в настройках Gradle runner после импорта проекта.

В настоящее время вы можете использовать последнюю выпущенную версию 1.3.x плагина Kotlin для работы с кодом. Чтобы убедиться, что у вас установлена ​​последняя версия, используйте инструменты -> Kotlin -> Настройка обновлений подключаемого модуля Kotlin .

Компиляция и запуск

Из этого корневого проекта есть конфигурации запуска / отладки для запуска IDEA или, например, Generate Compiler Tests ; поэтому, если вы хотите попробовать последний и лучший плагин IDEA

• VCS -> Git -> Pull
• Запустите конфигурацию запуска IDEA в проекте
• Затем запустится дочерняя IntelliJ IDEA с плагином Kotlin

Включение в составную сборку

Чтобы включить компилятор kotlin в составную сборку, вам необходимо определить dependencySubstitution для модуля kotlin-compiler в настройках . gradle.kts

 includeBuild ("/ путь / к / котлин") {
    dependencySubstitution {
        замените (модуль ("org.jetbrains.kotlin: kotlin-compiler"))
            .with (проект (": include: kotlin-compiler"))
    }
} 

или в настройках . Gradle

 includeBuild ('/ путь / к / котлин') {
    dependencySubstitution {
        заменить модуль ('org.jetbrains.kotlin: kotlin-compiler') на проект (': include: kotlin-compiler')
    }
} 

Kotlin распространяется в соответствии с условиями лицензии Apache (версия 2.0). См. Подробную информацию в папке с лицензией.

Обязательно ознакомьтесь с руководящими принципами Kotlin, чтобы узнать, как помочь проекту.

Kotlin: Как JetBrains создала язык программирования Android, предпочитаемый Google

Вице-президент JetBrains Хади Харири делится внутренней историей о том, как Kotlin стал де-факто языком программирования для Android и как компания построила вокруг него сообщество разработчиков.

Kotlin приобрел огромную популярность за последние несколько лет и стал предпочтительным языком Google для создания приложений для Android, но это не было первоначальным планом.В этом выпуске Dynamic Developer мы поговорили с Хади Харири, вице-президентом по защите интересов разработчиков в JetBrains, о том, как компания, наиболее известная своими IDE, создала язык программирования и построила вокруг него процветающее сообщество. Эта статья представляет собой стенограмму нашего разговора, отредактированную для удобства чтения.

Билл Детвайлер: Давайте поговорим об опыте JetBrains с Kotlin и построении сообщества вокруг него. Расскажи, как это произошло. Расскажите мне о процессе начала работы.Начни с самого начала.

Хади Харири: Конечно. Я думаю, что когда мы запускали Kotlin, у нас было основано сообщество вокруг JetBrains. JetBrains в этом году на самом деле исполнилось 20 лет. Мы запустили Kotlin еще в 2010 году, так что у нас уже было 10 лет форы с точки зрения построения сообщества вокруг нашего бренда и некоторых наших продуктов.

Хади Харири, вице-президент по защите интересов разработчиков, JetBrains

Кредит: JetBrains

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

Когда мы объявили: «О, мы сейчас создаем язык», все сказали: «Нет. Просто придерживайтесь IDE. JetBrains не должна заниматься языками.«Мы такие:« Хорошо ». Это было довольно сложно. Это было довольно сложно.

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

Bill Detwiler: Как вы думаете, какое сопротивление было в сообществе, которое уже существовало вокруг инструментов JetBrains? Как вы думаете, почему они колебались?

Хади Харири: Я не думаю, что это действительно касается JetBrains как самой компании.Я думаю, что люди начинают идентифицировать определенные бренды по определенным вещам. Это похоже на то, что Google — это поисковая система, которая продает рекламу. Завтра, если они придумают машину, ты такой … Ладно, ну, Google другой. Они могут придумать машину или купить компанию, которая производит машины.

Но если завтра придет Nike и скажет: «Ну, я делаю зонтики», люди будут типа: «Зачем [вы] делаете зонтики?» Я думаю, что, хотя, опять же, язык — это инструмент разработчика, было много такого мышления, как: «Ну, вы просто делаете IDE.Вы делаете IDE и инструменты для других языков. Почему вы хотите создать свой собственный язык? »Тогда, конечно, дополнительная вещь такая же, как« Ну, вы не просто создаете еще один контроль версий. Вы создаете язык ».

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

Как завтра, если вы возьмете компанию, которая пишет, например, код Java, и кто-то использует IntelliJ IDEA, который является нашим инструментом, а кто-то использует Eclipse; завтра, если этот человек уйдет, и они выберут, они могут просто использовать другую IDE. Это не принципиально для успеха или неудачи проекта.

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

СМ .:
Разработчики: 7 бесплатных руководств по популярным языкам программирования

(TechRepublic)

Kotlin не создавался специально для Android

Bill Detwiler: Я думаю, это отличный переход к тому, чего я хотел достичь, — это уроки, которые вы извлекли в процессе разработки Kotlin, который действительно стал предпочтительным языком для разработки на платформе Android. верно? Какие уроки извлекли JetBrains в процессе преодоления этого сопротивления, разработки этого языка и построения сообщества, сказав: «Ну что ж, они не просто производители IDE. У них есть этот язык, и да, я очень доволен им, и да, я собираюсь его принять ».

Хади Харири: Я думаю, что в первую очередь, извлеченные уроки. Это сложно, немного, чтобы ответить, потому что это зависит от того, кто и что, потому что в Котлине задействовано так много людей. Я думаю, что то, что мы, не то, что мы будем изучать, но то, что я чувствую, в некотором смысле, мы пытаемся Избегать означает демотивировать первоначальной реакцией.

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

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

Еще одна вещь: мало кто знает об этом, но мы никогда не создавали Kotlin для Android. Мы создали язык, который хотели использовать для разработки наших собственных IDE, потому что нам надоели некоторые вещи с существующими языками. Мы сказали: «Хорошо, давайте попробуем сделать это. Это хорошая возможность также предоставить другим людям лучший опыт.»

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

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

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

Но также, когда вы разрабатываете открыто и получаете много отзывов, вам нужно балансировать между видением и тем, куда вы хотите идти и куда все хотят идти.Кто это сказал … Это был Форд, верно? Тем не менее, про машины.

Билл Детвайлер: Справа. Он бы дал людям, если бы он спросил людей, чего они хотят, они бы сказали более быстрых лошадей.

Хади Харири: Ага.

СМ . :
Лучшие языки программирования для изучения в 2020 году

(TechRepublic)

Будьте восприимчивы к конструктивным отзывам клиентов

Билл Детвилер: Я думаю, что это действительно важный момент, потому что компании на протяжении всей истории, большие и маленькие, должны пытаться решать ту же проблему.Как это было с JetBrains? Вы получаете все эти отзывы. Некоторые из них отрицательные. Некоторые из них могут быть конструктивными. Вы хотите создать сообщество, поэтому не хотите лишать всех прав. Как вам удалось достичь этого баланса в случае с JetBrains?

Хади Харири: Я думаю, что у нас более или менее хорошо получается рассуждать с людьми. Если вы посмотрите на JetBrains как на компанию, в целом мы … Все началось с трех человек 20 лет назад. Когда я пришел, их было около 150 человек.Хорошо? Сейчас там около 1400 человек. Тем не менее, несмотря на это, он очень плоский по иерархии.

Я никогда не смогу . .. Я не … Как правило, это работает так, что вы не навязываете свои пути в JetBrains. Вы говорите: «Хорошо, я думаю, мы должны это сделать. Вот миллионы причин, почему я так сильно чувствую это». Но какой бы ни была моя должность или титул, если кто-то придет к выводу, что мы должны сделать это по-другому, мы сделаем это. Мы стараемся все аргументировать. Когда мы хотим добавить функцию к продукту, даже внутри команд, мы пытаемся объяснить, почему это ценно, почему мы должны добавить ее, почему мы должны добавить ее таким образом.

Итак, я думаю, что команда Kotlin была очень хороша, и особенно Андре, который возглавляет команду Kotlin, он всегда был очень хорош и восприимчив к идеям, и объяснял людям причины, почему это может не работать, и как это сделать. делает. Я думаю, что делать это открыто, например, как и все …

Теперь у нас есть открытый процесс, который называется Kotlin Evolution and Enhancement Process, где люди могут отправлять запросы на функции на GitHub или в нашем трекере проблем. Они придумывают сценарий, а затем мы его открыто обсуждаем. Мы говорим: «Хорошо. Что ж, этот сценарий может покрыть это, но он не будет охватывать эти вещи, поэтому, возможно, это не будет хорошей идеей, потому что это откроет шлюзы для всех этих других проблем».

Я думаю, что в целом вроде работает. Быть восприимчивым к обратной связи, но пытаться убедить людей в том, почему мы должны или не должны принимать это. Я думаю, что обычно мы пытаемся сбалансировать вещи именно так.

ПОСМОТРЕТЬ: Следует ли разработчикам Android переходить с Java на Kotlin? Вот совет Google по замене языков программирования (TechRepublic)

Билл Детвайлер: Как вы думаете, это приведет к увеличению заинтересованности сообщества? Это то, о чем я регулярно говорю с компаниями.Это становится еще более очевидным, когда я разговариваю с компаниями-разработчиками программного обеспечения и людьми, занимающимися разработкой с открытым исходным кодом. Разработчики, инженеры, программисты, люди, участвующие в процессе разработки, ожидают, что они примут эти компромиссы. «Эй, посмотри. Я собираюсь добавить функцию». Вы посмотрите на это. Ты мне об этом расскажешь. Вы собираетесь сделать … Есть нечто большее, чем, скажем, по аналогии, производитель автомобилей.

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

Хади Харири: Ага. На самом деле это забавно, потому что всего несколько дней назад я написал в Твиттере и сказал, что представьте, если бы производители автомобилей действовали так же, как мы, как разработчики программного обеспечения.Кто-то подает в Tesla вопрос и говорит: «Я хочу шесть колес. Если вы не дадите мне шесть колес, я пойду и куплю Ford». Это как если бы вы пытались сказать: «Хорошо. Давайте попробуем объяснить, почему у вас не может быть шести колес, или почему у нас нет пропускной способности для реализации шести колес сегодня».

Так что да, я думаю, есть компромисс. Но я думаю, что в конечном итоге все получается хорошо. Одна из причин, одна из причин … Говоря об извлеченных уроках. Когда у вас есть трекер проблем, который, по сути, является местом, куда мы отправляем запросы на функции, на наличие ошибок, что угодно, что является открытым, что является нашим случаем, оно очень, очень прозрачно.

У нас есть, чтобы дать вам пример, у нас есть проблема, которая существует уже 12-15 лет. У него много голосов. Мы усвоили один урок: даже если у нас нет пропускной способности, даже если у нас даже нет планов … Если у нас нет планов по реализации этого, мы должны это сказать. Мы просто говорим: «Смотри. Этого не произойдет». Люди ценят эту прозрачность и ценят эту честность. Они ценят то, что вы общаетесь, и это уроки, которые мы извлекли. Общаться. Расскажи им, что происходит.

Это тоже иногда бывает сложно. Когда у вас есть, например, запрос, который выполняется в течение пяти лет, чего не должно быть, но эй, это жизнь, вот как все работает, и что-то происходит в течение длительного времени … С вашей точки зрения , вы думаете: «Неужели я действительно должен присылать обновления каждые шесть месяцев и говорить:« Ну, мы все еще не работаем над этим. Ну, мы все еще не работаем над этим »». Верно? Так что это очень сложный баланс.

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

Но я думаю, что здесь важно, если вы прозрачны, если вы говорите людям: «Смотрите. Это план. Мы работаем над этим» или «Мы не работаем над этим». , «это самое ценное. Некоторым это может понравиться. Некоторым это может не понравиться. Некоторые люди могут сказать: «Ну, если вы не собираетесь работать над этим, я собираюсь использовать конкурента.«Но, как говорится, нельзя делать всех все время счастливыми.

СМОТРИ:
Google: если вы создаете новое приложение для Android, используйте язык программирования Kotlin.

(TechRepublic)

Создание успешного сообщества означает быть там, где находятся ваши клиенты.

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

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

Билл Детвайлер: Хорошо.

Хади Харири: Даже когда мы чувствуем, что нечего обновлять, мы время от времени подталкиваем нас со словами: «Ребята, мы все еще смотрим на это.Он все еще в разработке. Мы доберемся до этого, как только сможем «, — люди это ценят. Им не кажется, что вы их игнорируете. Я думаю, что это важно.

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

Я думаю, что это также очень важный урок для компаний.Часто, когда вы смотрите на компании, они смотрят на них с точки зрения наиболее эффективного способа оказания поддержки, а не на то, почему бы нам не открыть как можно больше каналов для клиентов, чтобы они не нужно прилагать огромных усилий, чтобы связаться с нами. Я думаю, что это очень важный урок, который …

Билл Детвилер: Итак, все дело в снижении барьеров между …

Хади Харири: Да, именно так.

Билл Детвайлер: … ваших клиентов, разработчиков и вас, и убедиться, что люди думают: «Эй, смотрите, даже если ответ отрицательный, я получил ответ».

Хади Харири: Ага. Я считаю, что это важно.

Билл Детвилер: Считаете ли вы, что это требование для достижения успеха в сегодняшних условиях? Кажется, именно этого и ожидают люди, будь то в какой-то степени ваша автомобильная компания или программное обеспечение.

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

Но, похоже, он остается во множестве продуктов и компаний, которыми мы живем сегодня. Просто кажется, что это тот мир, в котором мы находимся. Как вы думаете, что … Это похоже на ваш опыт работы с Kotlin, с другими инструментами, которые делает JetBrains?

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

Конечно. Вы абсолютно правы. Мы ожидаем этого, особенно в социальных сетях. Сегодня … Но есть два типа компаний, верно? Есть компании, которые активно работают в социальных сетях, по разным каналам и пытаются вам помочь.Затем есть те, кто хочет контролировать ущерб. Когда тебя обдирают или игнорируют . .. Ты, наверное, миллион раз видел, как кто-то твитнул и сказал: «Большое спасибо, XO и Y, за игнорирование меня, бла, бла, бла. » Затем сразу же они ответят вам в социальных сетях.

Тогда есть другие компании, которые … В былые времена, я не знаю, помните ли вы, у нас раньше были эти вещи, самолеты. Раньше они летали по воздуху. Да. Как защитник разработчиков, я много летала.Было два типа авиакомпаний. Был один, который я мог отменить, забронировать, перебронировать, сделать с ними все, что мог, через Твиттер. Затем был другой вопрос, которым их взаимодействие в Twitter было ограничено: «Пожалуйста, заполните эту форму или позвоните по этому номеру телефона».

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

Чтобы дать вам некоторые цифры, когда мы запускали Kotlin, с точки зрения сообщества, мы использовали BBS. Вы помните BBS?

Билл Детвайлер: Услуги старой доски объявлений?

Хади Харири: С ASCII …

Билл Детвилер: Да, да, да.

Хади Харири: Но мы были в IRC. Нас было шестеро, буквально шестеро, двое из JetBrains и еще четыре человека.Никогда ничего не происходило. Однажды я сказал своему коллеге: «Знаешь что? Может, нам стоит просто попробовать Slack». Мы создали Slack-канал. Затем это начало нарастать. Сейчас у нас, я думаю, около 30 000 человек на канале Slack. И там около сотни разных каналов. Это очень гостеприимное сообщество.

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

Информационный бюллетень Developer Essentials

От самых популярных языков программирования до вакансий с самыми высокими зарплатами — получайте новости и полезные советы для разработчиков.Еженедельно

Зарегистрироваться Сегодня

См. Также

Статически типизированный язык программирования для JVM, Android и браузера

Как вы можете внести свой вклад

Внесение вклада в код

Если вы хотите внести свой вклад в код, перейдите на GitHub, проверьте последнюю версию и следуйте
инструкции по сборке Kotlin из исходников. После этого вы можете начать собирать
в ожидании
задачи в системе отслеживания проблем. Убедитесь, что вы ищете теги проблем с
Вверх
Для Grabs, так как это одни из самых простых способов начать работу.

Использование документации или веб-сайта

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

Использование учебных материалов или видео

Вы создали учебное пособие или видео по Kotlin? Пожалуйста дай нам знать. Мы были бы более чем счастливы
включить его в раздел «Контент сообщества».

Презентации

Если вы проводили или проводите презентации на Kotlin, дайте нам знать.Мы разместим это на
список.

Проекты Kotlin-x и общественные проекты

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

Переводы

Вы можете перевести документацию Kotlin на свой язык и опубликовать свой
перевод на вашем сайте. Однако учтите, что мы не сможем разместить ваш перевод в
этот репозиторий и опубликовать на kotlinlang.орг. Этот сайт является официальной документацией по
язык, и мы должны быть в состоянии убедиться, что вся информация здесь верна и
своевременно. К сожалению, делать это на языке, на котором никто в команде не говорит.
выполнимо в настоящее время.

Распространяйте слово

Котлин — новый язык, но мы возлагаем на него большие надежды, и нам нужны люди, которые верят в него, чтобы
распространить слово!

.