Планирование редакции Rust 2021

Автор оригинала: Ryan Levick от лица The Rust 2021 Edition Working Group
  • Перевод

Рабочая группа Rust 2021 Edition рада сообщить, что следующая редакция Rust — Rust 2021 — запланирована на этот год. Пока что формально описывающий её RFC остаётся открытым, но мы ожидаем, что в скором времени он будет принят. Планирование и подготовка уже начались, и мы идём по графику!


Если вам интересно, какие новшества появятся в Rust 2021 или когда эта редакция выйдет в стабильной версии, — читайте нашу статью!


Что входит в эту редакцию?


Конечный список нововведений, которые войдут в Rust 2021, ещё не определён до конца. В целом мы планируем, что выпуск Rust 2021 будет намного меньше, чем Rust 2018, по следующим причинам:


  • Ритм выпусков стал регулярным Это значит, что мы будем активно использовать плюсы "цепочечной" модели на уровне редакций Rust.
  • Редакция Rust 2018 выбилась из модели "минимального стресса" выпусков.
  • Сейчас просто нужно меньше фундаментальных изменений, чтобы язык продолжал развиваться.

Более подробно о развитии концепции редакций вы можете почитать в RFC.


Решение, войдёт ли та или иная функциональность в Rust 2021, является частью процесса RFC — поэтому список ожидаемых функций может и будет меняться. Это будет происходить до самого момента выпуска, но тем не менее, уже сейчас мы можем рассмотреть список функций, которые, скорее всего, в неё войдут.


Изменения в прелюдии


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


Сейчас в редакцию Rust 2021 предложено включить следующие трейты:


  • TryFrom/TryInto
  • FromIterator

RFC с этими изменениями можно найти тут. Обратите внимание, что RFC ещё не принят — состав новой прелюдии активно обсуждается.


Новые правила захвата


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


Новый распознаватель функциональности в Cargo по умолчанию


В Rust 1.51 будет стабилизирован новый распознаватель функциональности в Cargo, который разрешит зависимостям пакета использовать разную функциональность в разных контекстах. Например, пакет с #[no_std] сможет использовать одну и ту же зависимость и во время сборки (build-dependencies с включённым std), и как обычную зависимость (без std). Пока что это приводит к тому, что std будет включена в обоих случаях, так как функциональность находится в глобальном пространстве имён.


В Rust 2021 этот распознаватель будет включён по умолчанию, но его можно использовать и в старых версиях, просто выбрав вручную.


Прочие изменения


Другие предложенные изменения включают унификацию работы panic в std и core и обновление уровня некоторых проверок с предупреждений до ошибок.


Полный список обсуждаемых функций вы можете найти здесь.


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


Примерный график


Итак, когда же мы планируем выпустить новую редакцию? Вот график основных этапов, к которому мы стремимся:


  • 1 апреля — все релевантные редакции RFC или приняты, или в хорошем состоянии (т. е. все основные вопросы решены, и принятие RFC произойдёт в ближайшие недели).
  • 1 мая — все нововведения, включённые в Rust 2021, находятся в Nightly с соответствующими feature-флагами.
  • 1 июня — все проверки добавлены в Nightly.
  • 1 сентября — редакция стабилизирована в Nightly.
  • 21 октября — редакция полностью стабилизирована.

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


Приглашаем к участию


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


  • rustfix миграции для всех соответствующих функций,
  • тестирование всех функций и путей их миграции,
  • сообщения в блогах и другие маркетинговые материалы.

От переводчиков


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


Данную статью совместными усилиями перевели blandger, TelegaOvoshey, funkill и andreevlex.

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

    0

    А как продвижение с GPU и CUDA в частности?
    Может кто подскажет современный фреймворк как все это увязать? да, есть например вариант просто линковать библиотеку и вызывать С функции, но это не то. Есть RustaCUDA — уже лучше, но там нужно иметь подгружать ptx файлы ядер. Скомилить сами ядра можно и nvcc, но как так сделать чтоб эти ptx "линковались" а не таскать их вместе с исполняемым файлом?

      +2

      А макрос std::include_bytes чем не устраивает?


      Там в RustaCUDA, кстати, есть пример "линковки" через std::include_str прямо в Readme.md, как вы его пропустили?

        +1

        Да, действительно, std::include_str "вшивает" ptx код в исполняемый файл. Пропустил так как только начал разбираться с rust и подумал что это функция и работает в рантайме.

        +1

        Вот к примеру, буквально вчера зарелизили: https://github.com/EmbarkStudios/rust-gpu/releases/tag/v0.3.0


        Но это из разряда перспектив. Compute шейдеры они пока не умеют, как и многое другое. Если надо прямо сейчас, то есть привязки к OpenCL

        0

        А какие там планы по скорости копиляции? gcc собирается в два раза быстрее с поддержкой c, c++ и fortran, чем rustc. И это ещё с предварительно собраной llvm.


        Проект уровня firefox/chromum потребует колоссальных ресурсов.

          –3
          У анализа потоков данных (DFA) квадратичная метрика сложности. Так что принципиального ускорения не может случиться.
          В других языках с DFA та же проблема, разве что он может применяться выборочно, а в Расте так невозможно.
            0
            gcc собирается в два раза быстрее с поддержкой c, c++ и fortran, чем rustc.

            Нет?


                 Tue Feb 16 19:19:43 2021 >>> dev-lang/rust-1.50.0
                   merge time: 33 minutes and 44 seconds.
            
                 Wed Feb 24 01:11:56 2021 >>> sys-devel/gcc-10.2.0-r5
                   merge time: 29 minutes and 32 seconds.

            Проект уровня firefox/chromum потребует колоссальных ресурсов.

            Ну будет firefox компилироваться 40 минут вместо 20, что дальше? И это еще десктопное железо, а не серверное, на котором обычно собирают билды браузеров.


                 Wed Feb 24 02:26:06 2021 >>> www-client/firefox-86.0
                   merge time: 21 minutes and 53 seconds.
              0

              У меня gcc 57 минут, rust 1:36 + llvm 0:40
              Chromium около 8 часов.


              Но это но 8 летнем ноутбуке.
              Возможно разница из-за размера кэшей процессора.

                0

                Твой ноутбук точно устарел. rustc + llvm собираются за час/полтора на райзене.
                А вообще много параметров нужно учесть чтоб сказать кто и при каких условиях быстрее. Да и для компаний которые используют rust, или любые другие компилируемые ЯП, не особо важно скорость компиляции (например дольше на 20-40мин) при билде релизной версии.

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

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