Хабрахабр

[Перевод] Мысли о Rust 2019

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

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

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

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

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

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

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

Язык Rust

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

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

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

Оснастка

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

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

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

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

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

SIMD

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

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

Аудио

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

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

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

GUI

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

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

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

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

Разметка

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть