Замечания к переводу прошу слать в личку.
Много важного несёт с собой предстоящий релиз Rust 1.0, но самым главным в нём являются наши усилия по обеспечению стабильности, аналогичные нашей постоянной ориентации на безопасность.
Начиная с версии 1.0, мы перейдём на шестинедельный цикл релизов и к набору «каналов». Канал стабильных релизов обеспечит безболезненные обновления, а канал ночных сборок предоставит первопроходцам доступ к тому функционалу, над которым в данным момент ведётся работа.
Стремление к стабильности
С его самых первых дней в Rust были неизменны только две вещи — безопасность и изменения, а иногда — только второе. В процессе разработки Rust мы часто упирались в тупики, поэтому свобода менять язык была совершенна необходима.
Но с тех пор Rust «повзрослел», и его ключевые аспекты не менялись уже довольно длительное время. Его архитектура, наконец, кажется нам правильной. Кроме того, сейчас можно наблюдать неподдельный интерес к языку, сдержанный только в ожидании выхода стабильной версии 1.0.
Очень важно прояснить, что мы подразумеваем под стабильностью. Это не означает, что Rust прекратит развиваться. Мы будем регулярно выпускать новые версии языка и надеемся, что его пользователи будут обновлять окружения для своих проектов так же часто. Но для этого сам процесс обновления должен быть безболезненным.
Если совсем просто, то наша ответственность заключается в том, чтобы вы никогда не боялись обновлять Rust. Если ваш код компилируется стабильным релизом 1.0, он должен компилироваться и стабильным релизом 1.x с минимумом хлопот.
Наш план
Мы воспользуемся вариантом модели «поезда», впервые появившейся при разработке веб-браузеров и широко применяющейся сейчас для обеспечения стабильности и предотвращения застоя:
- Новая функциональность добавляется непосредственно в главную ветку.
- Каждый день последняя успешная сборка на основе главной ветки становится новым ночным релизом.
- Каждые шесть недель из текущего состояния главной ветки создаётся ветка бета-версии, а предыдущая бета-версия объявляется стабильной.
Другими словами, у нас будет три канала релизов — ночные сборки, бета-сборки и стабильные релизы, с регулярным продвижением из одного канала в последующий.
Новая функциональность и новый API будет помечаться как нестабильные с помощью фичегейтов (feature gate) и атрибутов стабильности, соответственно. Нестабильные фичи и API стандартных библиотек будут доступны только в канале ночных сборок и только если вы явно согласитесь их использовать.
Бета- и стабильные релизы, с другой стороны, будут включать в себя только те фичи и API, которые отмечены как стабильные. Это значит, что особое внимание будет уделяться тому, чтобы не сломать код, который их использует.
Часто задаваемые вопросы
В описанный процесс вовлечено множество деталей, и мы собираемся опубликовать RFC, в котором расскажем о них подробнее. Оставшаяся часть этого поста посвящена наиболее важным особенностям и потенциальным опасениям по поводу нашего плана.
Какие фичи будут стабилизированы в 1.0?
Мы проанализировали существующую инфраструктуру экосистемы Rust для того, чтобы определить наиболее используемые библиотеки (crates) и фичегейты, которые они используют, и построить на основе этого наш план стабилизации. Хорошая новость: подавляющее большинство функционала, что сейчас активно используется, будет помечено как стабильное в релизе 1.0:
- Некоторые фичи, которые уже практически закончены: структуры-варианты (перечислений), типовые параметры по умолчанию, индексация кортежей и синтаксис для создания срезов.
- Два ключевых элемента языка, над которыми ещё требуется много поработать — unboxed-замыкания и ассоциированные типы.
- И наконец, важные фичи, проблемы в которых мы уже не успеваем решить до 1.0 — это множественные (glob) импорты, макросы и синтаксические расширения. Здесь нам придётся принимать тяжёлые решения.
После долгих дискуссий мы решили оставить множественные импорты и макросы стабильными в релизе 1.0. Мы считаем, что проблемы с glob-импортами будет возможно решить в обратно-совместимой манере. Для макросов же мы, скорее всего, предоставим дополнительный способ определения (с улучшенной гигиеной) позднее, до тех пор постепенно улучшая существующие «макроопределения». В релизе 1.0 вся существующая поддержка макросов, включая их импорт/экспорт, будет стабилизирована.
С другой стороны, мы не можем объявить синтаксические расширения, которые являются плагинами компилятора с полным доступом ко его внутренностям, стабильными. Это будет означать, что всё внутреннее устройство компилятора будет навеки зафиксировано. Поэтому нам нужно разработать более продуманный интерфейс между расширениями и компилятором, и поэтому синтаксические расширения останутся за фичегейтом в 1.0.
Во многих важных случаях синтаксические расширения можно заменить традиционной генерацией кода, и в Cargo вскоре будет включена её поддержка. Мы собираемся помочь авторам библиотек уйти от синтаксических расширений до релиза 1.0. Но поскольку большое количество расширений не вписываются в эту модель, их стабилизация высокий приоритет после выпуска 1.0.
Какие части стандартной библиотеки будут стабильными в 1.0?
Мы постепенно стабилизируем стандартную библиотеку, и у нас есть планы почти по всем её модулям. Ожидается, что подавляющее большинство функциональности стандартной библиотеки будет помечено как стабильное к выходу 1.0. Кроме того, мы переносим наиболее экспериментальные части API в отдельные библиотеки (crates).
А как насчёт атрибутов стабильности вне стандартной библиотеки?
Разработчики библиотек, как и сегодня, смогут продолжить использовать атрибуты стабильности для своего кода. Эти атрибуты не будут связаны с релизными каналами Rust по умолчанию. Другими словами, если вы компилируете с помощью стабильного Rust, вы сможете использовать только стабильное API из стандартной библиотеки, но при этом вы свободны пробовать экспериментальные элементы других библиотек. Релизные каналы Rust предназначены для безболезненного обновления самого Rust (компилятора и стандартной библиотеки).
Предполагается, что авторы библиотек должны следовать спецификации семантических версий. Вскоре мы опубликуем RFC, определяющее взаимосвязь атрибутов стабильности и семантических версий.
Почему бы не разрешить использовать нестабильные фичи со стабильным релизом?
При использовании нестабильных элементов языка и библиотек в стабильных релизах возникает три проблемы.
Во-первых, как много раз можно было наблюдать в области веб-разработки, просто объявить что-нибудь нестабильным не помогает. Как только какие-либо фичи начинают использоваться хоть сколько-нибудь широко, их очень трудно поменять; а как только фичи становятся доступными в принципе, очень трудно предотвратить их использование. Механизмы вроде «вендор-префиксов» (vendor prefixes) в вебе, предназначенные изначально для экспериментирования с фичами, стали стандартом де-факто.
Во-вторых, нестабильные элементы по определению являются незавершёнными, над ними всё время ведётся работа. Однако бета- и стабильные релизы «замораживают» их в назначенные моменты времени, в то время когда разработчики библиотек хотели бы работать с их последней версией.
И наконец, мы просто не сможем обеспечить стабильность Rust, если мы не будем для этого настаивать на выполнении некоторых правил. Мы обещаем, что если вы используете стабильный релиз Rust, вы можете совершенно безбоязненно обновляться на следующий релиз. Если же сторонние библиотеки зависели бы от нестабильностей в Rust, то мы смогли бы сдержать это обещание только в том случае, если авторы этих библиотек гарантировали бы то же самое, поддерживая свои библиотеки для всех трёх каналов одновременно.
Заставлять всю экосистему решать эти проблемы совершенно нереалистично и в принципе не нужно. Вместо этого мы устанавливаем правило, что если что-то стабильно, то оно на самом деле стабильно, и стабильный канал предлагает только стабильные фичи.
Не произойдёт ли раскола экосистемы? Не будут ли все использовать nightly-сборки даже после релиза?
Нет, экосистема не будет разделяться: этот подход лишь выделяет её подмножество. Разработчики, работающие с nightly-каналом, смогут свободно использовать библиотеки, предназначенные для стабильной версии языка. Наиболее важные фичи и API так или иначе будут стабилизироваться, поэтому причин оставаться в нестабильном мире со временем будет меньше и меньше.
Мы спланировали релиз 1.0 таким образом, что большая часть существующей экосистемы попадёт в «стабильную» категорию, поэтому новички, только начинающие изучать Rust, смогут сразу же использовать подавляющее большинство существующих библиотек в стабильном релизе 1.0.
На каких условиях предоставляется стабильность?
Мы оставляем за собой право исправлять баги в компиляторе, закрывать дыры в безопасности и менять алгоритмы вывода типов так, что могут потребоваться дополнительные аннотации типов. Мы считаем, что такого рода изменения не должны вызывать серьёзной головной боли при обновлении Rust.
Особенности стабильности в API будут изложены в будущем RFC, но в целом они также задумываются таким образом, чтобы облегчить вам обновления.
Продолжит ли Rust и его экосистема развиваться так же активно, как и сейчас?
Определённо да! Поскольку свежие изменения попадают в главную ветку постоянно, модель «поезда» не замедлит темпа разработки и не привнесёт искусственных задержек. При содействии нашего потрясающего сообщества Rust всегда развивался очень быстро, и мы уверены, что в будущем темпы только ускорятся.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий