Мысли о Rust 2019

https://raphlinus.github.io/rust/2018/12/16/rust-2019.html
  • Перевод
Коллеги, доброго вечера всем!

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



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


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

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

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

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

Язык Rust

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

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

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

Оснастка

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

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

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

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

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

SIMD

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

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

Аудио

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

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

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

GUI

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

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

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

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

Разметка

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

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

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

Скриншот с Гитхаба — быть или не быть?

Издательский дом «Питер»
215,00
Компания
Поделиться публикацией

Похожие публикации

Комментарии 13

    +10
    Спасибо за перевод, было интересно прочитать.
    Рост числа статей про раст на хабре в последнее время радует.
      +1
      Возможно, это как-то связано с прошедшим недавно RustRush.
      Но в целом, да, радует.
        0

        Возможно, это никак не связано. Рост числа статей был и до конфы.

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

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

        –4
        О, это оказывается известный чувак, а я с ним пиво пил на раст-митапе, думал обычный такой сотрудник гугла ;-)
          0
          Мне кажеться разговоры о GUI сродне разговоров о GUI в сообществе Golang. Только никто пока не обосновал их целесообразность, я сомневаюсь что Rust или Go займёт эту нишу. Да, JavaScript'у это удалось (Electron, Win8 Metro App, Gnome, etc), но и программистов и хайпа вокруг JavaScript в разы больше, а разработка в разы проще (так как HTML+CSS)
            0
            Этот чувак рассказывал про свою GUI прослойку на расте для своего редактора youtu.be/Pc6ednHfsQg?t=2392
            Он бы как то очень сфокусирован на скорости.
            0
            1. Можно ли Lua использовать с Rust также как с Си ?
            2. можно ли будет в Rust использовать национальные (в нашем случае кириллические) имена переменных и функций? Пару статей о Rust назад в комментариях написали что вопрос решается и и дёт живое обсуждение.
              +1
              1. А почему нет? https://github.com/kyren/rlua/blob/master/examples/guided_tour.rs
              2. Можно: https://github.com/kpp/kkk/blob/master/src/main.rs, kekeke

              Пользуйтесь на здоровье.

                +3
                Можете рассказать зачем вам это нужно? Мне кажется лучше использовать только латиницу, так как не возникнет проблем с чтением, нет необходимости переключать раскладку и все символы присутствуют на клавиатуре, но к примеру книги про golang очень часто упоминают, что можно использовать любые алфавитные символы (в том числе всякие гаммы, теты, альфы), и меня это смущает.
                  +1
                  Вот в этой ветке с таким же вопросом обговорены, как мне кажется, основные кейсы и причины, а также границы применения на практике. Кратко — есть те, кому нужно, и это стоит использовать только в таких случаях.
                +2
                Работать с xi-editor удобно, хотя, при этом обычно требуется некоторое руководство и поддержка.

                xi-editor на github собрал много звезд, вокруг него много шума. Проект имеет клиент-серверную архитектуру, основная ветка это backend server, есть несколько ссылок на реализации frontend. Я перепробовал все frontend на системах *nix и darwin(на которых работаю) и ни разу не получил полноценный инструмент. Как этим люди пользуются, что я упустил?

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

                Самое читаемое