Юкихиро Мацумото: «Естественная конкуренция — хорошая штука»

Вступление

Наш друг Юкихиро Мацумото, создатель языка программирования Ruby, смог присоединиться к нам для участия в интервью. Григорий Петров, DevRel компании Evrone, побеседовал с Юкихиро, чтобы получить из первых рук информацию о новых возможностях последнего крупного релиза Ruby. Юкихиро также поделился подробностями своего подхода к улучшению Ruby и дал нам представление о будущем языка.

Интервью

Григорий: Меня зовут Григорий Петров. Я нахожусь в офисе Evrone, чтобы взять интервью у Юкихиро Мацумото, автора языка программирования Ruby. Прошло всего несколько месяцев после выхода релиза Ruby 3.0 с его новыми крутыми возможностями.

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

Юкихиро: Мне нравится сопоставление с образцом, включая правостороннее присваивание. В то же время я в восторге от Ruby-акторов (ractors) и статической типизации — думаю, что это изменит культуру программирования на Ruby к лучшему.

Григорий: Да, статическая типизация — это замечательно. Мне не терпится увидеть, как сработает идея добавления типов в стандартную библиотеку и фреймворки. Сопоставление с образцом — тоже здорово! Мне его не хватает в Python, и хорошо, что можно использовать это в Ruby.

Ruby 3.0 обратно совместим. Это очень кстати, потому что разработчики ненавидят что-то ломать, и им нравится сохранение обратной совместимости. Можешь ли ты порекомендовать этот подход для других языков? Поддерживать обратную совместимость — это ведь удачная идея?

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

В прошлый раз, когда мы сломали совместимость в Ruby 1.9, мы поняли, что это может надолго расколоть сообщество. После Ruby 1.9 я принял решение, что мы будем стараться ничего не ломать даже при выпуске мажорных версий. У других языков, таких как Python 3 или PHP 6, была аналогичная проблема, которая показала важность обратной совместимости.

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

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

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

Я помню, какие трагедии разыгрывались 10 или 15 лет назад при переходе Python с версии 2 на 3. Это длилось несколько лет, и основные разработчики даже не были уверены, следует ли им продолжать разработку Python 3 или просто вернуться к версии 2 и успокоиться. Что-то подобное происходило и с PHP. Я рад, что сейчас мы находимся на такой стадии разработки, когда можно предложить потрясающие фичи, не огорчая миллионы разработчиков.

Давай поговорим об фичах. Языки программирования заимствуют удачные решения друг у друга. В Ruby теперь есть сопоставление с образцом; деструктуризация хэшей уже была в Python и JavaScript, а теперь появилась и в Ruby. Возможно, в будущем Python или JavaScript позаимствуют у Ruby правостороннее присваивание. Какие у тебя планы на следующие версии? У тебя уже есть смелые идеи, что-то хочешь позаимствовать или обкатать?

Юкихиро: Хороший вопрос! Но мы долго были сосредоточены на Ruby 3, а с момента релиза прошел всего месяц, так что у меня пока не сформировались безумные идеи на будущее. Это могло бы быть улучшение ractor’ов и системы модулей для Ruby. Java и Python имеют модульную систему. Кроме того, может было бы полезно предоставить структурированную систему пакетов. У меня возникают некоторые мысли, но пока недостаточно конкретные, чтобы их обсуждать. Может, тебе придется подождать год или около того.

Григорий: Не проблема. Я пишу код 20 лет и с удовольствием буду писать еще лет 20.

Кстати, система управления пакетами Ruby может быть не такая полнофункциональная, как, например, в Java, но Ruby позволяет пользователям устанавливать и использовать несколько версий одной и той же зависимости. И это действительно здорово, потому что в Python, например, придётся довольствоваться только одной версией зависимости, что создает множество проблем. А Javascript, Node.js просто помещают версии в определенный каталог. Итак, Ruby отлично себя чувствует с текущей системой, но мы всегда будем ждать новых улучшений.

Юкихиро: Да, мы могли бы подготовить какие-то контейнеры, чтобы разные версии gem’ов могли находиться в разных контейнерах, или что-то в этом роде.

Григорий: У вас еще много времени, чтобы это протестировать. Появляется очень много новых языков программирования. Как ты это отслеживаешь? У тебя есть подписки на RSS или разработчики приходят и рассказывают о новых фичах?

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

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

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

Григорий: Итак, если кто-то из наших читателей хочет предложить Юкихиро интересные идеи, он может сделать это с помощью Ruby Redmine. Что касается проблемы пандемии… как с твоей точки зрения повлиял на разработку и внедрение Ruby, а также на сообщество тот факт, что всё делается из дому, и все конференции проходят в онлайн?

Юкихиро: Повседневная разработка не очень изменилась. Я ведь живу далеко от Токио, встречи и общение наших разработчиков в основном проводились через интернет и до пандемии. Но то, что сейчас нет «настоящих» конференций — это плохо.

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

Григорий: Кстати, в 2020 мы организовали и участвовали во множестве онлайн-конференций, и ты тоже. Что ты думаешь об онлайн-конференциях? Полезны ли они? Можешь ли ты получать с их помощью обратную связь и общаться с другими разработчиками Ruby?

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

Григорий: Кстати, хочешь присоединиться к нашей онлайн-конференции  RubyRussia, не выходя из дома?

Юкихиро: Конечно!

Григорий: Отлично, через несколько месяцев пришлю тебе приглашение.

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

И каковы плюсы и минусы такого подхода, когда вы даете сотням тысяч разработчиков что-то попробовать, а если не получается, забираете обратно?

Юкихиро: Когда сообщество Ruby было маленьким, и его не волновали изменения, был широкий простор для экспериментов. Если что-то не срабатывало, то это «что-то» просто удаляли, совместимость никого не волновала. Но те старые добрые времена миновали, теперь у нас огромное сообщество.

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

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

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

Поэтому при проведении экспериментов с фичами Ruby приходится идти на компромисс, учитывая текущий размер сообщества разработчиков Ruby. Большое сообщество рубистов не простит сделанных ошибок, но размер сообщества разработчиков языка не даёт нам провести все эксперименты внутри. Нам приходится просить всё сообщество опробовать новые изменения.

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

Так бывает с другими языками. В отличие от Ruby, сообщества Python и PHP достаточно велики, чтобы экспериментировать в среде разработчиков языков.

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

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

Григорий: Точно, или пользователей, которые хотят заниматься разработкой самого Ruby. Они смогут присоединиться к разработчиками языка и доказать, что готовы участвовать в экспериментах.

Юкихиро: Большинство пользователей Ruby даже не рассматривают возможность присоединиться к процессу проектирования, хотя это было бы полезно.

Григорий: У меня каверзный вопрос по поводу все ractor’ов и асинхронных fibers. Мне нравится асинхронность: как параллелизм, так и многозадачность. И сейчас в Ruby 3 у разработчиков есть широкий выбор. Для параллелизма можно использовать процессы или ractor’ы, а для многозадачности — потоки или асинхронные fiber’ы. Как обычному Ruby-разработчику правильно сделать выбор?

Юкихиро: Разработчикам веб-приложений не нужно заботиться об асинхронности, потому что серверы приложений, такие как Unicorn, Puma и Falcon, сами о ней позаботятся. Unicorn использует процессы, Puma — потоки, а Falcon — fiber’ы. Выбор сервера приложений напрямую влияет на выбор модели асинхронности. Может быть, в будущем у нас появится сервер приложений на основе ractor’ов.

Обычный разработчик экспериментирует с асинхронностью, исследуя узкие места производительности приложения. Если узким местом является ввод/вывод, разумно выбрать асинхронные fiber’ы. Они оптимизированы для мультиплексирования ввода-вывода. Так что выбирайте их, если ваша программа использует много операций ввода-вывода. А если вы хотите поэкспериментировать с многоядерностью и задачами с высокой нагрузкой на процессор, то лучше подойдут ractor’ы.

Это базовый выбор, потому что текущая реализация ractor’ов сопоставляет один ractor с одним потоком операционной системы. Вы пока что не сможете создать миллионы ractor’ов, потому что каждый из них потребляет несколько мегабайт памяти стека. Это очень много. А fiber’ы потребляют всего несколько килобайт памяти или даже меньше. Таким образом, с fiber’ами вам не нужно беспокоиться о расходе памяти, вы можете создать столько fiber’ов, сколько захотите. Это второй критерий выбора. Коичи Сасада (Sasada Koichi), который отвечает за ractor’ы, работает над их улучшением. Вероятно, в будущем ractor’ы не будут потреблять столько памяти.

Возможно, позже мы сможем использовать их так же, как горутины в Go. Но это дело будущего.

Григорий: Да, и это, похоже, светлое будущее.

Мне нравится, что авторы фреймворков придерживаются известной концепции «convention over configuration» и разработчики могут использовать модель асинхронности, уже выбранную и правильно организованную автором фреймворка. А после этого, если что-то работает медленно, разработчики могут копнуть глубже и переключиться на другую модель работы с асинхронностью. Хорошо, когда есть выбор.

Еще один вопрос по скорости.

Недавно я наткнулся на короткую статью Давида Хайнемейера Хансона (David Heinemeier Hansson), где встретилось интересное наблюдение: для всего парка его серверов, обеспечивающих работу Basecamp и почтового сервиса Hey.com, только 15% бюджета тратится на выполнение кода Ruby. Если даже ускорить Ruby в 10 раз, это ничего существенно не поменяет. Насколько важна чистая скорость для Ruby?

Юкихиро: Непростой вопрос. Для большинства веб-приложений Ruby и бизнес-логика не являются узким местом. Львиная доля времени приходится на работу с базами данных, сетевыми соединениями и работой с операционными системами. Shopify и GitHub используют Ruby, видимо, скорость не имеет большого значения. Количество их пользователей очень велико, а они работают без проблем. Если речь идёт о производительности труда программиста, то производительность языка — не самая большая проблема.

Я долго так считал, пока несколько лет назад не понял, что многие судят по микро-бенчмаркам.

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

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

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

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

Григорий: Точно, JIT помогает. В прошлый раз, когда я проверял искусственный микро-бенчмарк, простое включение JIT для Ruby ускорило его в десять раз. Это действительно работает.

Юкихиро: Да, мы не боремся с инстинктами.

Григорий: Последний технический вопрос касается функций, включенных в стандартную библиотеку. Есть два подхода. Первый — это то, чем знаменит Python. Огромная стандартная библиотека, включающая всё, например FTP-клиент, почтовый клиент и zip-архиватор. Начинающим разработчикам это нравится, потому что они могут посмотреть в руководства и получить всё без установки зависимостей. И это «всё» работает «из коробки».

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

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

Юкихиро: Для Ruby 1.8 использовался подход «толстой» стандартной библиотеки, но со временем некоторые библиотеки остались без поддержки. Мы изменили подход, разделив библиотеку на gem’ы.

Очень немногие использовали RubyGems с Ruby 1.9, но во времена Ruby 2.0 RubyGems был настроен для общего доступа. С появлением Ruby 2.0 сообщество RubyGems становилось все больше и больше, каждый использовал RubyGems. Если все используют gem’ы, нам не нужно добавлять все в поставку языка программирования. Так что мы постепенно разделили стандартную библиотеку на gem’ы, сделав дистрибутив легким и удобным для поддержки.

Ты помнишь, что наше сообщество разработчиков языка недостаточно велико, чтобы в нём были эксперты по всем вопросам. В основном, наши разработчики Ruby не являются веб-разработчиками. Мы не очень умеем поддерживать такие веб-технологии, как webrick, http-клиенты или даже обработку xml.

Было удачной идеей убрать эти неподдерживаемые части из стандартных дистрибутивов языка в gem’ы. Теперь другие разработчики могут создавать конкурентоспособные, лучше поддерживаемые gems. Естественная конкуренция — хорошая штука!

Григорий: Понятно. Из-за пандемии обучение и образование также были переведены в онлайн. За последние два года я просмотрел множество курсов, блогов и мест, где разработчики могут изучать Ruby. Появились новые сервисы, и мне особенно нравится Real Python для языка Python, и я надеюсь, что для Ruby будет создано что-то столь же крутое.

Что ты порекомендуешь начинающим разработчикам, изучающим Ruby, или опытным разработчикам, которые хотят освежить свои знания для Ruby 3? Какие книги, блоги или учебные платформы ты порекомендовал бы в 2021 году?

Юкихиро: Лучшие учебные материалы 2021 г. для начинающих программистов находятся на railstutorial.org и guides.rubyonrails.org. Создание веб-приложения — хороший урок программирования, это близко к реальному продукту. В наше время достаточно запустить Scaffolding и написать несколько строк кода на Ruby, чтобы получить простое веб-приложение. За считанные секунды вы можете это веб-приложение обновить и улучшить.

Короткий цикл разработки побуждает разработчиков узнавать больше. После того, как разработчик разберется в Rails и Ruby, он может изучать всё, что захочет: машинное обучение, встроенные системы. Для новичков веб-приложение является хорошей отправной точкой.

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

Является ли эта признательность правительства и все мероприятия, проводимые правительством для Ruby, чем-то специфическим для Японии и японской культуры? Или в Ruby есть что-то особенное, или причина и в том и в другом?

Юкихиро: Сообщества разработчиков очень похожи как в Японии, так и за ее пределами, например, в России, США и Европе. Но считается, что Ruby родился в Японии, и некоторым людям в Японии, особенно в секторах местного самоуправления, хочется поощрить его.

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

Григорий: Потрясающе. Я надеюсь когда-нибудь побывать в Японии! Увидимся осенью 2021 года на Ruby Russia. Большое тебе спасибо. Я надеюсь, что наши вопросы и твои ответы помогут разработчикам стать лучше, писать хороший код и получать от этого удовольствие. Аригато.

Заключение

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

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