Mozilla наметила план для выпуска Rust 1.0

    Организация Mozilla вышла на финишную прямую в подготовке языка программирования Rust 1.0. Разработчики говорят, что это торжественное событие состоится примерно в конце года. После бета-тестирования выйдет финальный релиз. С этого момента перспективный язык программирования можно использовать в боевых условиях: код гарантированно будет компилироваться в следующих версиях.

    Дело не только в компиляции. Mozilla считает, что дизайн Rust наконец-то приобретает желаемую минималистичную форму. К примеру, раньше было несколько типов указателей, сейчас остались только &T, и &mut T. Упрощение затронуло и другие аспекты, в том числе замыкания, которые вызывали много споров.

    Rust сочетает в себе эффективность С и С++ с безопасностью Java.

    Весь дизайн построен на концепции «владения и заимствования» (ownership and borrowing). Изначально предполагалось использовать механизм владения для быстрого и безопасного переноса данных между процессами. Но потом пришло понимание, что этот же механизм можно использовать для передачи значительной части функций в библиотеки. В итоге, Rust получился даже более низкоуровневым, чем разработчики предполагали, и без ущерба для безопасности. На минимальной конфигурации Rust можно даже написать ядро операционной системы (примеры: 1, 2, 3)!

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

    • Типы с динамическим размером (dynamically sized types). Расширение системы типизации позволяет использовать типы данных, размер которых неизвестен на момент компиляции, например, массивы. Вместо этого проставляется хитроумный указатель, содержащий массивы или объекты.
    • Распакованные замыкания (unboxed closures). В новом дизайне замыканий они объединены с типами объектов.
    • Ассоциативные типы (associated types) в системе признаков значительно облегчают написание аннотаций для библиотек, первая реализация уже готова.
    • Где-клозы (where clauses). Планируется внедрить гибкую новую форму элементарной дизъюнкции. Работа над этой функцией уже закончена, скоро её добавят в основную ветку кода.
    • Типаж с множественной отсылкой (multidispatch traits). Функции типажей расширены, так что они могут указывать более чем один тип одновременно, это открывает возможности для более эргономичных API и для использования ассоциативных типов, упомянутых выше.
    • Деструкторы. Семантика деструкторов улучшена, так что ему не нужно теперь обязательно обнулять память, что должно повысить скорость компиляции и исполнения программ. Сейчас заканчивается анализ условий для обнуления памяти, после чего эту часть тоже добавят в основную ветку.
    • Зелёные потоки (green threading) убирают из основной библиотеки в дополнительные, чтобы оптимизировать их эффективность на конкретной операционной системе. Это тоже приведёт к ускорению исполнения программ.

    Параллельно создаётся пакетный менеджер Cargo и будет организован центральный репозиторий ПО.

    Из лекции Степана Кольцова, которую недавно публиковали на Хабре:

    «Rust решает проблемы Java и C++: программы, написанные на Rust, одновременно быстрые и безопасные. Rust является таким же низкоуровневым (в смысле close-to-metal) языком программирования, как и C++, однако в язык встроены конструкции, позволяющие на этапе компиляции доказывать, что в программе не случатся ошибки работы с памятью, как то обращение после использования, двойное удаление, использование неинициализированной памяти и т.п.

    Кроме того, Rust исправляет многие ошибки, допущенные при проектировании C++ и Java. Например, шаблоны в Rust, в отличие от C++, статически типизированы, а вместо дженериков Java используется механизм, похожий на тайпклассы Haskell».

    Примеры кода на Rust см. на официальном сайте.

    UPD. Полный перевод статьи «На пути к Rust 1.0» от Googolplex
    Support the author
    Share post

    Similar posts

    Comments 70

      +4
      <мечты>Была бы ещё для Rust удобная среда разработки</мечты>
        +5
        Еще релиза не было, а Вы про среду)
        Будет развитие языка — будет и среда
          +2
          Как по мне Rust уже развит настолько, насколько можно желать для комфортного решения задач. Субьективно оценивая, больше половины использующих Rust не будут использовать (а возможно даже знать) все возможности, предоставляемые нам компилятором этого замечательного языка. Так почему же нельзя обратить внимание в сторону того, чтобы на язык было проще переключиться с другого (C++ или новомодного и любимого мной Go к примеру)?
            +2
            У раста, при всей моей симпатии к нему как к языку и целям разработчиков, пока есть некоторые существенные проблемы, которые несколько ограничивают его широкое использование на данный момент: далеко не всегда оптимальный генерируемый код по сравнению с другими языками (по скорости), великоватые бинарники (собранный версией 0.11.0 «hello world» для x64 занимает что-то типа 1.7M unstripped супротив ~150K у окамла например) и отсутствие компилятора (как и эмит-бэкенда) для не-интел платформ, а это важно для языка, который по идее должен заменить си/плюсы в том числе в ембеддеде.

            В то же время, раст выглядит очень привлекательным именно за счет того, за что его ругают функциональщики — если на первых порах он был скорее больше похож на «ML с плюсами», то сейчас все чаще говорят о «C++ done the right way». Спорить с этом тяжело, ибо история показывает, что императивно-ориентированный синтаксис — очень сильный буст к популярности. (Тут уместно вспомнить ремарки о чутье Гвидо по поводу того, как должен выглядеть питон.)
              +2
              Немного занудства :)

              далеко не всегда оптимальный генерируемый код по сравнению с другими языками (по скорости)

              Справедливо для всех языков, в принципе. С -O2 Rust очень близок к C и регулярно переплёвывает разрекламированный Go.

              великоватые бинарники

              Есть такое — из-за того, что в бинарник статически линкуется рантайм. Отключите рантайм и получите размер чуть больше, чем соответствующая программа на C. В целом, это не видится разработчикам языка (да и не только им) такой уж большой проблемой, с учётом того, сколько сейчас стоит дисковая память.

              отсутствие компилятора (как и эмит-бэкенда) для не-интел платформ

              Странное утверждение. Rust работает поверх LLVM, что, в частности, означает свободную поддержку ARM. Версия для Android, кстати, официально поддерживается разработчиками языка. А ещё см. здесь.
                0
                В целом, мне кажется, с современными объёмами дискового пространства, статически скомпилированные бинарники очень удобны, потому что их просто переносить и разворачивать. Так что я бы вообще не относил это к минусам.
                  +1
                  Rust работает поверх LLVM, что, в частности, означает свободную поддержку ARM. Версия для Android, кстати, официально поддерживается разработчиками языка.
                  Да, это все хорошо. Но я немного о другом: пока что для раста очень мало готовых бутстрап-компиляторов под разные платформы и операционные системы. То есть я могу, конечно, сказать ./configure --target=arm-unknown-linux-gnueabi, но мне в любом случае понадобится нативный rustc. Еще пример: lang/rust есть в портах FreeBSD, но он amd64-only и более того:
                  .if ${OPSYS} == FreeBSD && ${OSVERSION} < 1000000
                  BROKEN= Only compiles on FreeBSD 10 and 11
                  .endif
                  Можно, конечно, попробовать собрать rustс+LLVM самостоятельно, но это не самый тривиальный процесс, и я совсем не уверен, что мне удастся получить работающий компилятор, скажем, для powerpc или спарка. А у того же окамла такой проблемы нет.
                    +1
                    Да, всё так как вы говорите. Но вы сравните время, сколько существует OCaml и сколько существует Rust, который даже до стабильной версии ещё не добрался. Задатки есть, поэтому добавить поддержку дополнительных платформ будет, по крайней мере, не невозможно. Кроме того, процесс разработки языка очень открытый, поэтому если кому-то это действительно надо и есть желание поучаствовать в развитии языка, всегда можно присылать патчи и RFC.
            +8
            Может будет кому интересно. Ведётся разработка плагина для VisualStudio.
            Проект открытый, код доступен на GitHub: PistonDevelopers/VisualRust. Плагин, также, представлен в галерее VisualStudio, т.е. его можно установить через менеджер дополнений.
              +4
              Плагин под IDEA уже начали писать, лексер есть, грамматики для парсера в разработке. Думаю к релизу минимальный функционал разработчики допилят (go-to-symbol, минимальное авто-дополнение)
                +1
                Плагин для IDEA смотрел примерно месяц назад. Осталось впечатление, что кроме подсветки ключевых слов там больше и нету ничего. Но радует, что хотя бы начало положено, будем надеятся, что получится что-то хотя бы уровня плагина для Go в той же IDEA.
                  0
                  Есть повод поконтрибьютить. Жаль только что лишь на JVM языках плагины к IDEA пишутся.
                    0
                    Автор об этом и так честно сообщает. Но там уже есть некоторые грамматики, поэтому я делаю вывод, что он не остановится на лексере (подсветке)
                      0
                      Получается и подстветка не полноценная, лексера ведь не достаточно, чтобы определить семантику символа.
                        0
                        Ну, для подсветки ключевых слов вполне достаточно.
                          –1
                          что вы подразумеваете под семантикой символа?
                          можно конкретные слова (ключевые) подсвечивать, можно по регуряркам искать (комментарии, док-блоки).
                          Грамматика никак не влияет на подсветку, она дает возможность анализировать код для более умных фич.
                          В контексте раста одним только лексером вполне можно искать unsafe блоки и подсвечивать их красным, на пример.
                            0
                            Я не говорил явно про грамматику, а про семантику. Значение некоторых символов (возможно, не в Rust) и грамматикой вывести нельзя.
                            Простой пример:
                            PairМожет ли лексер в одиночку решить, имя типа ли это или же выражение, в котором Pair сравнивается на «меньше» с char, результат которых сравнивается с чем-то, что еще не было прочитано? Не может.
                            На мой взгляд подсветка в случае имени типа и в случае выражения должна быть разной. Возможно с этим можно поспорить.
                              0
                              Теги потерялись, я говорю о таком случае:
                              Pair<char>
                                0
                                Я немного слукавил про парсер, конечно им можно и такое найти — но не стоит. А вот грамматикой — конечно можно. Ровно как внутри компилятора выполняется разбор языка — аналогичные грамматики пишутся в плагине.
                      +2
                      Из всего что я перепробовал, на данный момент есть одно работоспобное и не требующее самостоятельной сборки решение для винды — на основе среды разработки geany.

                      1. Скачиваем mingw, gtk2, geany, исходники geany c github.com/geany/geany; устанавливаем все это, а также сам rust.
                      2. В PATH прописываем пути к mingw/bin, gtk/bin и rust/bin
                      3. Из исходников geany берем папку data и целиком копируем ее с заменой той папки data которая была при установке geany. Там множество настроек для различных языков, включая rust
                      4. Создаем проект, в нем создаем файл с расширением .rs, пишем код!

                      Работает подсветка синтаксиса, компиляция и запуск прямо из среды, дерево символов, вывод сообщений компилятора в специальное окно среды, по щелчку на сообщении открывается соответствующая строка в коде. То есть стандартный набор возможностей, для начала более чем достаточно.
                        +1
                        Уже есть неплохой Rust-плагин для Sublime Text 3.
                          +2
                          В комплекте с Rust идет плагин для Vim
                        • UFO just landed and posted this here
                            +30
                            Вы на кого тут замыкание распаковываете?
                            +12
                            Я сейчас перевожу пост, опубликованный разработчиками, в течении нескольких дней будет готово — выложу на Хабр. Вслед за ним авторы языка планируют написать ещё несколько статей, посвящённых основным фичам языка и экосистемы. Rust наконец-то выходит в большой мир :)
                            –2
                            Кажется я понял суть Rust, разница между Go и Rust примерно как между мечом и магией.
                              +1
                              Их не надо сранивать.
                                +3
                                А какая разница между мечем и магией? Не уловил аллегорию. Кроме типа урона ничего на ум не приходит.
                                  +1
                                  Melee/ranged? :)
                                    +1
                                    Магия бывает вполне себе ближнего боя, взять например Геральта из Ривии
                                      +1
                                      Да какая там у него магия-то, низкоуровневая =) Не буду сейчас искать цитату, но Йэннифер неплохо так прошлась по магии ведьмаков =)
                                  0
                                  Комментарии про Go в постах про Rust традиционно минусуются.
                                    +1
                                    Меня не столько волнуют минусы комментария, сколько комментаторы, не понимающие фундаментальную разницу между мечом и магией. >_<
                                      0
                                      Меч — реальность, магия фантастика? Но Кольт-Ассемблер, АК-Си и Малыш-Python все равно рулят.
                                        +1
                                        Фундаментальная разница в том, что меч это практически обычная палка, которой надо много и усердно бить. Магия состоит из заклинаний, которые требуют сильной умственной деятельности, звучат стремно, зато можно скастовать большой взрыв.

                                        Go проектировался как прагматичный язык с несложным и компактным стандартом. И никаких «магических» штук вроде multidispatch traits там нет. Я конечно понимаю, что программирование это сама по себе магия с точки зрения рядового человека, но на нашем девелоперском поле тоже есть некие магические направления, Rust я вынужден отнести к одному из них. Особенно глядя на синтаксис.
                                  +3
                                  Рад, что не сошёлся свет клином на C/++ и Java. Хорошая альтернатива, через пару лет, при должном развитии, можно будет внедрять в серьёзные серьёзности.
                                    +2
                                    Они еще там же объявили о том, что разработка будет вестись подобно тому, как разрабатывается разрабатывается Firefox или Chrome: 3 канала с шестинедельными итерациями. Стабильный релиз каждые 6 недель.
                                      0
                                      лишь бы качество не страдало
                                        0
                                        Это, конечно, круто. Но только при условии, что после версии 1.0, между постоянно выходящими релизами не будет ломаться совместимость, как она ломается сейчас.
                                        • UFO just landed and posted this here
                                        0
                                        Хочется чтобы книгу по Rust выпустили. Документация это конечно хорошо, она не заменяет хорошую книгу…
                                          0
                                          На днях, кстати, они закончили переписывание с нуля туториала и сделали более подробный и актуальный Guide: doc.rust-lang.org/guide.html
                                            0
                                            Если я правильно понял, они вообще заменили туториал гайдом.
                                              0
                                              Ну я это и имел в виду, когда говорил, что переписали с нуля туториал и сделали гайд, неудачно сформулировал.
                                              Это не книжка, конечно, но неплохой задел для нее.
                                          +4
                                          Если руки дойдут, попробую написать несколько UEFI-драйверов на Rust, заодно проверю степень интеграции с C и напишу интеграцию со сборочной системой UDK2014.
                                          На первый взгляд системного программиста на С — язык однозначно торт, остается попробовать его в реальных проектах.
                                            0
                                            Rust сочетает в себе эффективность С и С++ с безопасностью Java
                                            .
                                            Не совсем понимаю что значит «безопасность Java».
                                              0
                                              Речь идет как минимум о безопасности работы с памятью.
                                                0
                                                Rust пожалуй даже безопаснее, чем какая-нибудь Java, но менее удобен и порог входа выше.
                                                –1
                                                Вот может кто то объяснить, можно ли сделать такое на Rust?

                                                template<class Point>
                                                void callMe(Point &&p){
                                                  ...
                                                }
                                                
                                                callMe( Point(1,2) );
                                                Point p(1,2);
                                                callMe(p);
                                                


                                                Тоесть, чтобы функция могла как временный объект принять, так и ссылку.
                                                • UFO just landed and posted this here
                                                    +1
                                                    Угу. s.draw(Point{x: 10, y: 11,}); Он здесь как — копирует Point (аля memcpy)? Или как в случае с С++ Point создается раз, данные не memcpy'тся?

                                                    P.S. Ассемблерный код конечно страшыйн выдает:))
                                                      0
                                                      Уверяют, что лишних копий не будет, и что move семантика в расте более бесшовная, чем в C++.
                                                      Вообще надо проверить, о результатах доложу.
                                                        +1
                                                        В FAQ написано что move как в С++11 в rust нет.
                                                        move Rust'a рабоает через memcpy :)) doc.rust-lang.org/complement-design-faq.html#no-move-constructors
                                                          0
                                                          то есть оптимальным образом) в C++ в лучшем случае будет memcpy. (поля нужно скопировать в любом случае, если есть указатели, то memcpy то будет применён к непосредственно ним, а не к данным по указателю)
                                                            0
                                                            Не совсем, в приведенном примере работает perfect forwarding, и в случае если ссылка Point&& p привяжется к rvalue-expression, даже memcpy не будет. Будет применен copy/move elision. На этом принципе работают всякие emplace/emplace_back/emplace_front в стандартных контейнерах.
                                                              0
                                                              elision как раз равносилен memcpy. Одно всегда можно заменить другим, при этом наблюдаемое поведение не изменится. Это чисто техническая оптимизация, и ребята из rust ее сделают, если это будет необходимо, как мне кажется.
                                                                0
                                                                Я говорю о том, что копирования не будет вообще никакого. Конечно же это оптимизация (причем прописанная в стандарте). Вопрос ведь был в том, насколько это дешево. Отсутствие memcpy точно дешевле, чем его присутствие.
                                                                  0
                                                                  А про наличие copy/move elision у них ничего не сказано? Если Вы, конечно, читали их доки целенаправленно.
                                                        • UFO just landed and posted this here
                                                            0
                                                            Тоесть s.draw(&Point{x: 10, y: 11}); — эта форма аналог C++ universal reference? И всегда предпочтительнее?
                                                            Ну, если конечно не совсем мелочь интовая какая-то.
                                                      –1
                                                      Прочёл статью и стало интересно, что такого можно сделать на Rust, чего нельзя сделать на Haskell? Гуру просветите. И кстати, а как в чудо Rust'е контроллируются побочные эффекты?
                                                        +2
                                                        В Rust у вас zero-cost-абстракции. В Haskell этого нет, к сожалению, а если и есть — то за гранью возможностей большинства программистов. Также в Rust безопасность работы с памятью обеспечивается не за счёт сборщика мусора, а за счёт мощного статического анализа.

                                                        Побочные эффекты в Rust не контролируются в том смысле, что в Haskell. Монад здесь нет :) На типы высшего порядка очень большой запрос в сообществе, но в версии 1.0 их не случится. Однако система типов позволяет контролировать определённые паттерны, которые в языках вроде C и C++ ведут к сегфолтам и гонкам.

                                                        В целом, бессмысленно сравнивать Haskell и Rust, у них совершенно разные ниши. Haskell не является системным языком, он не живёт без рантайма и сборки мусора, в отличие от Rust, поэтому их области применения различны.
                                                          –1
                                                          1) Насколько я знаю без трассирующего сборщика мусора нельзя собрать некоторые «частные» случаи, например циклические ссылки. Непонятно как в Rust решили эту проблему. Но если решили, определённо тянет на открытие.
                                                          2) Не контроллируются побочные эффекты? Это затрудняет формальную верификацию программы. + Огромное поле для потенциальных ошибок. То есть, в итоге мы получаем тот же C++ только задизайненный чуть более на современный лад.

                                                          В общем сложилось впечатление, что лучше бы они к Haskell написали ключик компилятора, который бы делал результат компиляции «ближе» к железу, чем пилить ещё один 100500-й язык программирования.
                                                            +2
                                                            Давайте будем объективными. Haskell непригоден для системного программирования в силу своей высокоуровневости и необходимости рантайма, и никакие «ключики компилятора» это не исправят. Другая проблема (опять же, будем объективными) — Haskell слишком отличается от привычных языков, и аудиторию системщиков на него не перетянуть, несмотря на все потенциальные гарантии и даже если бы Haskell и работал без рантайма. Попытка уже есть — видели ATS? На benchmarksgame он валил C по скорости, хотя потом его оттуда почему-то убрали. Тем не менее, им никто не пользуется, именно из-за того, что ML-подобный язык с соответствующей системой типов непрактичен для низкоуровневого программирования.

                                                            Насколько я знаю без трассирующего сборщика мусора нельзя собрать некоторые «частные» случаи, например циклические ссылки. Непонятно как в Rust решили эту проблему. Но если решили, определённо тянет на открытие.

                                                            В Rust возможно реализовать умные указатели, которые будут использовать сборку мусора. Сейчас же в Rust есть тип Rc<T>, который предоставляет указатель с подсчётом ссылок, и да, для него есть специальный тип Weak<T>, который решает проблему циклических ссылок. Поэтому да, делать ссылающиеся на себя структуры немного неудобно.

                                                            Тут вопрос в том, насколько часто вам нужны графоподобные структуры объектов. Да, если вам нужно много работать с такими структурами, вам сейчас придётся писать больше кода, чем потребовалось бы в языке типа C++, Java или Haskell. Но я бы не сказал, что такие ситуации встречаются часто, особенно в системном программировании, где существуют типы-значения.

                                                            Кроме того, циклические ссылки — это далеко не самая главная проблема работы с памятью на низком уровне. Утечки памяти, use-after-free, double free, многопоточные гонки данных гораздо страшнее, и их гораздо сложнее отлавливать. С последними, например, никакой сборщик мусора вам не поможет в принципе. И с этими проблемами Rust справляется на ура благодаря статическому анализу. Сейчас не существует языка, в котором есть похожий статический анализатор. Есть Cyclone, но он больше исследовательский, а не практический язык, и насколько я знаю, анализ в Rust всё-таки мощнее.
                                                          0
                                                          Все тьюринг-полные языки эквивалентны в в смысле того, что на них можно сделать, так что вопрос в такой формулировке некорректный. Другое дело — что на Rust что-то делать удобнее, чем на Haskell. Языки-то сильно отличаются на самом деле, Rust не функциональный, ближе к железу, обладает другой моделью памяти, не ленив.
                                                          +1
                                                          шаблоны в Rust, в отличие от C++, статически типизированы

                                                          Эм, что? Это про концепты (которые всё грозятся впилить в C++)?
                                                            0
                                                            Да, дженерики в Rust похожи на концепты, как и на классы типов в Haskell.
                                                            +2
                                                            В Rust отсутствуют исключения, и вместо них есть тип Result. Не значит ли это, что в любой мало-мальски сложной программе везде прийдётся писать try!(...) при вызове каждой функции, которая может завершиться с ошибкой?
                                                              +3
                                                              Да, есть такая проблема. Частично решение уже есть — можно использовать комбинаторы вроде and_then(). В обсуждении есть ещё несколько RFC, которые предлагают различные варианты решения.

                                                            Only users with full accounts can post comments. Log in, please.