Мысли о Rust 2019

Коллеги, доброго вечера всем!

Мы с радостью предлагаем вам перевод по-настоящему программной статьи от Рафа Левина ^[1], чей титанический труд над развитием языка Rust вызывает уважение и пиетет:

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

Недавно команда Rust Core Team предложила писать статьи ^[2] с мнениями о том, как Rust должен развиваться в 2019 году. Вот мое мнение.

Жизненный цикл созревания

В этой статье я рассмотрю жизненный цикл созревания в предельно упрощенном виде. Пусть он состоит всего из трех этапов: исследования, разработка, шлифовка. Различные элементы Rust отличаются разной степенью зрелости. Это важно учитывать, пытаясь точно охарактеризовать актуальный этап развития языка, а в идеале – вывести его на следующий этап. Например, мне представляется, что язык в основном находится в стадии «шлифовки». Если упорствовать в том, что стадия «исследования» еще не пройдена, то язык можно обогатить зависимыми типами, виртуальными структурами ^[3] и т.д., что было бы интересно, но контрпродуктивно. Верно и обратное: мы не можем точно сформулировать, чего нам не хватает в графическом пользовательском интерфейсе, поэтому преждевременные попытки привести эти поиски к стандартному решению, скорее всего, обернутся неоптимальными результатами.

Во многих зрелых продуктах перемежаются релизы, одни из которых посвящены обкатке новых возможностей, а другие – их стабилизации. Такова, например, система tick-tock у Intel. Версии Android Kit Kat и Marshmallow были стабильными, и в то же время Lollipop активно перелопачивали). В 2018 году Rust обогатился множеством новых возможностей, поэтому я считаю, что пришло время для этапа стабилизации. В этом я согласен с Джонатаном Тёрнером ^[4], а также со многими другими.

Язык Rust

Думаю, что в общем и целом язык Rust готов. Создается впечатление, что сообщество достигло согласия по поводу необходимости «приземлять» те фичи, которые до сих пор остаются «на лету» (в стадии разработки): речь об async/await, const generics, и интерпретаторе (что, вероятно, обеспечит нам доработку обобщенных ассоциированных типов ^[5]). Однако, думаю, что сверх этого мы не должны чрезмерно усердствовать с наполнением конвейера новыми фичами.

Изменения стоят денег. По состоянию на 2018 год о Rust написаны две отличные книги, но обе уже слегка устарели. Соглашения для квалифицированных путей в них отличаются, теперь мы используем dyn Trait, т.д. Чем динамичнее изменения, тем больше неудобств для пользователей.

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

Оснастка

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

Естественно, RLS лишь наполовину этому соответствует, пользователи взаимодействуют с ней через редактор. Работать с xi-editor ^[6] удобно, хотя, при этом обычно требуется некоторое руководство и поддержка. Эту работу взяло на себя сообщество во главе с Колином Рофлзом ^[7], и мне просто радостно смотреть, как этот редактор улучшается (он уже стал у меня основным). Там предусмотрена поддержка языкового сервера, а также новые возможности, например, общий механизм аннотаций, будут значительно лучше доработаны в 2019 году.

Библиотечная экосистема

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

Одна из тем, которую я хотел бы поднять – это «когерентность», которая, на мой взгляд, является одной из самых ценных черт Rust, наряду с технической составляющей его системы типажей ^[8]. Многие составляющие «игрового движка» в пределах C++ — это тщательно подготовленная подборка библиотек, отлично взаимодействующих друг с другом. Но в Rust многие подобные вещи происходят органически. Контейнеры действительно обычно заточены на использование в связках, а если грамотно применять такие вещи как into, то все тем более налаживается. Особенно убедительный пример второго рода — mint ^[9], обеспечивающий интероперабельность множества математических контейнеров, даже притом, что в них не совпадают соглашения, применяемые при определении векторных типов и т.д.

SIMD

Думаю, SIMD-библиотеки пока находятся на стадии исследования. Есть множество библиотек-оберток, каждая из которых предлагает немного иную перспективу и иной ряд компромиссов: simdeez ^[10], packed_simd ^[11], faster ^[12] и, конечно же, моя собственная fearless_simd ^[13]. Эти компромиссы далеко не безусловны, ведь некоторым пользователям потребуется выжать из языка всю производительность до последней капли и, если вы тяготеете к таким крайностям, то придется прибегать к наилучшим инструкциям для конкретных процессоров. Другие в большей степени оценят портируемость и безопасность.

Одна из важнейших закавык SIMD заключается в том, что гораздо больше работы приходится делать в компиляторе, во многом ради взаимодействия с архитектурами AVX-512 и не -x86 SIMD. Также возможно, что библиотеки-обертки требуют внести некоторые изменения на уровне языка, чтобы работать стало максимально удобно; так, на настоящий момент встраивание и cfg(target_feature = ...) взаимодействуют плохо. На мой взгляд, это еще один вопрос, требующий исследования. Интересно понять, как далеко мы сможем зайти без дополнительной поддержки на уровне языка, и какие именно возможности помогут принципиально повысить удобство работы с ним?

Аудио

Есть удобные низкоуровневые аудио-контейнеры, среди которых следует особо отметить cpal ^[14]. Однако, с ним возможны сложности на уровне производительности (контейнер не всегда использует поток реального времени), каких-то возможностей. Необходимо найти оптимальный путь: либо доработать cpal, либо разработать новый контейнер, который позволил бы исправить конкретные проблемы. Для этого, в частности, нужно внимательно присмотреться к библиотекам C++, например, RtAudio ^[15], хорошо решающим эти проблемы.

Для более высокоуровневого аудио-синтеза у меня большие планы на synthesize-rs ^[16]. Этот вариант подойдет не всем, но, думаю, это хороший базис для разнообразных приемов синтеза и аудиоэффектов. Представляется, что сегодня этот участок работы находится где-то между этапами исследования и разработки.

Чтобы следить за этой работой, ознакомьтесь с потоком #synthesizer ^[17] в нашем чате Zulip. В ноябре я читал лекцию об этом, на основе которой вскоре планирую написать пост.

GUI

В настоящее время графические пользовательские интерфейсы – одно из самых слабых мест Rust. Думаю, в 2019 году мы увидим в Rust-сообществе достаточно много статей на эту тему.
Лично мне кажется, что растовские GUI в настоящее время следует отнести к фазе «исследования». Прорабатывается множество альтернативных подходов, и пока нет общего мнения о том, который из них лучший. Насколько активно в системной архитектуре должна использоваться 2D-графика и другие примитивы пользовательского интерфейса, либо нам стоит реализовать весь этот стек самостоятельно? Является ли необходимым развертывание в веб (при помощи wasm)? Должен ли весь процесс программирования восприниматься “Rust-нативный”, либо лучше приспособиться к соглашениям, устоявшимся в каком-нибудь зрелом GUI? Хватит ли у Rust-сообщества ресурсов, чтобы создать новый GUI-инструментарий, и если так – то стоит ли это делать?

Я начал проект Druid ^[18], чтобы сделать GUI для моего синтезатора и игры, но этот проект – исследовательский. В нем представлена моя точка зрения, мои ответы на все вопросы, сформулированные выше, и, на мой взгляд, этот проект развивается хорошо. Но, повторюсь, это исследовательский проект, и было бы весьма глупо на данном этапе внедрять его в другие проекты.

Кроме того, ведется и ряд других проектов по разработке GUI. На мой взгляд, наиболее многообещающим из них является Azul ^[19], поскольку WebRender нравится мне в качестве основы для построения GUI. Другой очень перспективный проект — OrbTK ^[20], сделанный на основе Redox, но кроссплатформенный и реально продвинутый. Многому можно научиться и на примерах Conrod ^[21], ggez ^[22], а также на обертках инструментариев из других языков.

Неудивительно, что наиболее бурная деятельность по разработке GUI в Rust тесно связана с играми, и мне кажется, что это хорошо. Инновации лучше приживаются в сегменте игр, а необходимость в зрелых инструментариях здесь стоит не так остро. Но, как только появится отличный подход к реализации GUI в Rust, думаю, он найдет самое широкое применение. Также отмечу, что мой Druid зародился на основе GUI-уровня из клиентского редактора xi для Windows ^[23].

Разметка

Библиотека pulldown-cmark ^[24] используется достаточно хорошо, в частности, для rustdoc, но в некоторых отношениях подустарела. Ее эволюция не успевает за развитием спецификации CommonMark. Одна из причин, по которой она немного застряла, связана с алгоритмом парсинга; у меня уже есть идея, как написать новый алгоритм для этой цели, гораздо лучше прежнего; но детали я пока не проработал. В последнее время я вновь вернулся к этой работе ^[25] и готовлюсь выпустить алгоритм. Когда ветка new_algo добавится в master, думаю, сообществу стоит взяться за его дальнейшую доработку, обогащать его новыми фичами. Я размышляю о полной GFM-совместимости, математике и, возможно, о чем-нибудь еще в этом духе.

Спасибо всем в сообществе Rust за доработку языка, с которым мне так нравится жить.

Автор: ph_piter

Источник ^[26]