В преддверии начала подготовки (http://blog.rust-lang.org/2014/09/15/Rust-1.0.html) стабильного выпуска языка программирования Rust 1.0, переход к бета-тестированию которого ожидается в конце года, представлен (https://mail.mozilla.org/pipermail/rust-dev/2014-October/011... очередной экспериментальный выпуск Rust 0.12.0 (http://www.rust-lang.org/), продолжающий развитие функциональности и оттачивание языковых конструкций.Язык Rust развивается проектом Mozilla и сфокусирован на безопасной работе с памятью и обеспечении высокого параллелизма выполнения заданий (возможность порождать тысячи и даже миллионы подпроцессов). Исходные тексты проекта распространяются (https://github.com/mozilla/rust/) под лицензией MIT. Параллельно с Rust совместно с компанией Samsung развивается экспериментальный браузерный движок Servo (http://www.opennet.me/opennews/art.shtml?num=36576), написанный (https://github.com/servo/servo/) на языке Rust и отличающийся поддержкой многопоточного рендеринга web-страниц и распараллеливанием операций с DOM (Document Object Model).
По структуре язык Rust напоминает C++, но существенно отличается в некоторых деталях реализации синтаксиса и семантики, а также ориентацией на блочную организацию структуры кода, которая позволяет реализовать задачи в виде легковесных сопрограмм. Автоматическое управление памятью избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Rust поддерживает смесь императивных процедурных и объектно-ориентированных методов с такими парадигмами, как функциональное программирование и модель акторов, а также обобщённое программирование и метапрограммирование, в статических и динамических стилях.
С момента прошлого выпуска внесено около 1900 изменений (https://github.com/rust-lang/rust/wiki/Doc-detailed-release-... среди которых:- Большое внимание уделено подготовке документации. Полностью переписано руководство разработчика (The Rust Guide);
- Продолжено развитие пакетного менеджера Cargo, который в некоторых ситуациях уже вполне доведён до готовности;
- Переписаны и приведены в соответствие к требованиям по написанию кода реализации многих API в области std;
- Вторичные библиотеки вынесены из основного дерева исходных текстов и теперь должны быть установлены через пакетный менеджер Cargo. Среди таких библиотек: uuid, semver, glob, num, hexfloat, fourcc;- Возможность определения lifetime-аннотаций в определении функции;
- Поддержка работы в 64-разрядных версиях Windows;
- В компиляторе rustc реализована эксперментальная поддержка распараллеливания при указания опции "-C codegen-units";- Практически доведена до готовности реализация типов с динамически изменяемым размером (Dynamically-sized), для управления данными типами представлено новое свойство "Sized";
- Свойство "Share" переименовано в "Sync" для избежания ассоциаций с типом "shared reference";
- Добавлено новое ключевое слово "move" для индикации замыканий, захватывающих значения;
- Добавлено новый более эффективный тип замыканий - "unboxed closures";
- Для переименования выражений теперь следует использовать "use foo as bar" вместо "use bar = foo", а также "extern crate foo as bar" вместо "extern crate bar = foo";
- Изменён синтаксис (например, "[0..4]", "[a, b, c..]") определения блоков в "Slice" и "SliceMut". Для определения входящих диапазонов теперь следует использовать три точки вместо двух, т.е. "0...4" вместо "0..4";
- Расширены возможности стандартной библиотеки. Переработаны библиотеки Bit-vectors, collections::bitv и collections::btree. Проведена оптимизация в работе компонентов, связанных с вводом/выводом.Базовые возможности языка:
- Ориентация на безопасность:
- Аккуратная работа с памятью - никаких нулевых и потерянных указателей. Автоматическое управление памятью;- Контроль изменчивости. Объекты неизменяемы (Immutable) по умолчанию;
- Безопасность динамического выполнения: обработка сбоев, исключения, ведение лога, RAII / dtors;
- Typestate: возможность определения сложных инвариантов, контролирующих структуры данных.
- Ориентация на параллельность и эффективность кода:
- Явный контроль памяти, контролирование схемы распределения памяти;- Крайне лёгкие задачи, формируемые в виде сопрограмм. Лёгкость в порождении тысяч и миллионов подпроцессов;
- Итераторы в стэке (фактически лямбда-блоки без распределения кучи);
- Статическая, нативная компиляция с созданием исполняемых файлов ELF, PE, Mach-o;
- Прямой и простой интерфейс для кода на языке Си;
- Ориентация на практическое применение:
- Мультипарадигмальный, функциональный, императивно-процедурный, объектно-ориентированный, поддерживающий параллельную actor-модель;- Функции высшего порядка с биндингами;
- Нет номинальных типов (http://en.wikipedia.org/wiki/Nominative_type_system) или иерархии типов;
- Мультиплатформенный, поддерживается Windows, Linux, Mac OS X, *BSD;
- Хранение строк в UTF-8, разнообразие низкоуровневых типов;
- Работает с существующими нативными наборами инструментов: GDB, Valgrind, Shark и т.д.;
- Практическая возможность нарушения правил: возможность игнорирования правил безопасности, если чётко указано, когда и как их нарушать.
URL: https://mail.mozilla.org/pipermail/rust-dev/2014-October/011...
Новость: http://www.opennet.me/opennews/art.shtml?num=40791
systemd уже переписали на rust?
не, пока тлько core utils - https://github.com/uutils/coreutils
куда катится этот мир
Вы против безопасности в утилитах, которые установлены повсеместно?
Уязвимости обычно возникают, там где вносится много новой функциональности: Shellshock из-за специфичной возможности bash (функции в переменных окружения) и реализации heartbeat в OpenSSL, приведшей к Heartbleed-уязвимости.И если Rust - это и есть та самая новая функциональность, то cat'у у которого из изменений за последние пару лет - стиль я верю больше:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=histor...
Помимо перечисленного, есть специфичные для языков уязвимости. Выход за пределы массива, разыменование нулевого указателя.
Конечно, они есть. Но в случае с вылизанными coreutils - ИМХО они маловероятны.
> Вы против безопасности в утилитах, которые установлены повсеместно?Теперь давай сюда grep -ri "unsafe" по дереву исходников. Результат скормить wc -l.
А ты давай-ка посмотри какого размера блоки unsafe. Большинство однострочные, очень просто контролировать. Весь код на C/C++ в Rust считается unsafe. Всё ещё будем считать C++ безопасным?
Никто не гарантирует полной непробиваемости. Всегда найдётся тупица, который всё поломает. Но по умолчанию в Rust это сделать сложнее.
coreutils под лицензией mit? вот извращенцы
Чем это хуже coreutils под лицензией BSD?
Что-то мне кажется, что это какая-то несерьёзная реализация coreutils.
Если речь идёт об управлении памятью, то чем это лучше java?Что такое сопрограмма? Раньше такого термина не было. Я так понимаю, этот же термин есть в D. Зачем это придумано?
Оно более менее нормально компилируется в native приложение и не тянет за собой JRE. И оно более функционально даже чем Java 8. Хотя слово лучше/хуже это всегда холивар :)
> Если речь идёт об управлении памятью, то чем это лучше java?Дык ведь... что значит: "лучше"?
Насколько понимаю, задачи у этих языков слишком разные, чтобы ставить вопрос так.
Результат, касательно управления памятью, думаю, один и тот же, а вот цена за него отличается.
В этой статье есть графики производительности GC в java. http://www.oracle.com/technetwork/java/javase/gc-tuning-6-14...Вы можете легко оценить затраты на безопасное обращение с памятью в rust по сравнению с java разделив значения в графиках на 0.
> оценить затраты на безопасное обращение с памятью в rust по сравнению с java разделив значения в графиках на 0Хочешь сказать, что в Rust эти затраты стремятся к бесконечности?
>Что такое сопрограмма? Раньше такого термина не было.Ну зачем же так открыто признаваться в своём невежестве. Почитайте Кнута, что ли.
Причем тут невежество?
Это системная проблема современного образования.
Это системная проблема современной нехватки IT-специалистов и локальная проблема конкретного идиота. Благо, для самообразования в IT есть абсолютно все условия - от горы пособий и онлайн курсов до отсутствия нужды в каком-либо специальном оборудовании чтобы всему научиться на практике.
Вот дурачок. Сборщику мусора java до модели памяти Rust как до луны пешком.
> Вот дурачок.Ты, наверное, даже не догадываешься, как ты прав. Круче него только ваня-однобитный-флоат. Но ваню с год назад закрыли. А этого, похоже, выпустили из дурки (года два его тут не было).
Кстати да, ни разу не видел вот этого здесь.
> Если речь идёт об управлении памятью, то чем это лучше java?Вы ждёте что вам здесь лекцию о Rust прочитают? Сходите лучше на сайт Rust и посмотрите сами, чего они там напилили, чтобы обойтись без вызовов free, запусков GC и без счётчиков ссылок.
> Что такое сопрограмма? Раньше такого термина не было. Я так понимаю, этот же термин есть в D. Зачем это придумано?
А это чтобы вы спросили.
> посмотрите сами, чего они там напилили, чтобы обойтись
> без вызовов free, запусков GC и без счётчиков ссылок.В rust-е есть и Rc<T> и Gc<T>.
> Что такое сопрограмма? Раньше такого термина не было.а-а-а! как же я не заметил это чудо?!
вот и подросло поколение лоботомированых дятлов.
Если речь идёт об управлении памятью,
то это лучше чем в java тем, что не нужен сборщик мусора и расходы на него.
И это лучше чем в С тем, что не поработаешь случайно с освобожденной памятью,
и это проверяется во время компиляции.Сопрограммы придуманы очень давно.
Зачем они могут, например, пригодиться?
Как правило, программировать легче и надежней,
используя блокирующие поток исполнения вызовы:sync_a();
return sync_c(sync_b());
/**[VS]**/
async_a(function(err){
async_b(function(v){
async_c(v,function(w){
result_handler(w)
},error_handler)
},error_handler)
},error_handler)Второй вариант возникает не от хорошей жизни,
а от невозможности использовать первый, т. к. поток всего один,
либо затратности использовать первый, т. к. потоков нужно было бы очень много.
Например в java потоки соответствуют потокам ОС, которых можно сделать тысячи.
А сопрограммы (которых в стандартной java нет)
реализуются на уровне языка, и их можно сделать на порядки больше.
А поддержка динамически подключаемых библиотек там намечается?
Хотеть криптолибы на Rust.
Зачем нам безопасность, нам надо чтобы все само подгружалось!
Почему само? Я имею ввиду, чтобы можно было выносить разные возможности в отдельные модули (типа backend). И затем при загрузке подгружать нужную библитеку реализации.Как пример: разные варианты работы с дисплеем: Модуль для работы с X, wayland, mir, directfb....
Что-то типа такого. Ну и понятно, что при загрузке таких модулей должно проверяться ABI
> Ну и понятно, что при загрузке таких модулей должно проверяться ABIОго. Может быть, и "задачу останова" вы уже решили?
Или вы имеете в виду версию ABI? Но тогда ваша хотелка реализуется не на уровне языка исходных текстов, а на уровне имён файлов собранной библиотеки, реализуется динамическим загрузчиком ОС, и уже триста лет как.
"Практически доведена до готовности реализация типов с динамически изменяемым размером (Dynamically-sized)"а раньше динамические массивы не поддерживались??
Поддерживались.
>> возможность порождать тысячи и даже миллионы подпроцессовДа ну и что, даже аппаратная реализация многопоточности тут не нужна ?
>> аппаратная реализация многопоточностиа что это такое?
Это то, благодаря чему реализован механизм переключения между процессора путем интервального пика таймера, после которого один процесс меняет другой, сохраняя значения каждого регистра предыдущего.
процессами*
Речь не о процессах и даже не о нитях, это реализовано целиком в пространстве пользователя.
Я это знаю, но тут утверждается, что всё это целиком и полностью реализовано в Ruste'е, особенно "обеспечении высокого параллелизма выполнения заданий (возможность порождать тысячи и даже миллионы подпроцессов)". Что собственно и озадачило меня :)
Green threads же
то есть один процесс-нить сможет изменить глобальную переменную, в другой процессе-ните уже взять её измененной?
>> механизм переключения между процессора путем интервального пика таймера, после которого один процесс меняет другойт.е. прерывания вы называете аппаратной реализацией многопоточности?
Вы хотите предложить какую-либо альтернативную реализацию многопоточности, которая бы обходилась без прерываний ?
Так уже давно предлагали. В виндах 3.x это был основной метод организации многозадачности.
Чягоо ?
хе-хе.. имеется ввиду кооперативная многозадачность, в терминологии ветки обсуждения - программная :)
А что с GCCRS (Rust для GCC)? Готово для использования?
Едва ли. Впервые о нём слышу, хотя языком интересуюсь.
После 1.0 можно будет говорить, что что-то готово для использования.
Зачем надо было пилить Ржавого, когда до этого уже несколько лет существовал Ди? Если бы у мозилофилов было чуть меньше амбиций и чуть больше мозгов, они бы помогли Ди с библиотеками и язык популяризовался гораздо быстрее.
Им захотелось немного хаскелльщины, а ди, это скорее питонщина.
Ты коммиты смотрел у Руста? там Рубистов и ЯваСкриптоПисателей гора.
Это-то и пугает! :)
У статического языка должны быть статические же реализаторы.
Ди это что угодно, но не питонщина. По многим причинам, начиная прежде всего с любви к TIMTOWDI. Там у них в рассылке много лет сидит ярый питонист и очень хорошо заметно, как дишные концепции ему всё время не по нраву - то хочет беззнаковые целые убрать, то bounds checks обязательные, то ещё что...Собственно, ближе всего к правде то, что и написано на сайте - D is a C++ done right. С хорошим метапрограммированием (которого в Rust вообще нет) и кучей удобств для программиста.
http://doc.rust-lang.org/0.12.0/guide-macros.html
> http://doc.rust-lang.org/0.12.0/guide-macros.htmlА можно на макрах исключения забацать?
> уже несколько лет существовал Ди?
> ...
> они бы помогли Ди с библиотекамипокажите мне green threads в этом переусложнённом монстре.
А зачем они там? Есть Fibers, есть Tasks, есть libasync. А делать свой менеджер потоков в языке - это ни разу не в стиле D. Вот это как раз было бы переусложнением.
Это всё и в Ruby есть. Green threads таки круче.Речь не о "менеджере потоков", речь о том, что параллельный софт удобнее разрабатывать на ерланговских green threads, чем на всех этих велосипедах из твоего сообщения. Разработчики Rust это поняли, D -- нет, об чём и речь.
О. Ещё бонусный вопрос, раз уж вы отрицаете переусложнённость D. Цель: написать UTF-8 в консоль (мы же в 21 веке знаем и про локали, и про юникод, и про винду). В Go это просто как `Println("что надо"). Приведите не более сложный код на D, если он и правда не переусложнён.
> Зачем надо было пилить Ржавого, когда до этого уже несколько лет существовал
> Ди? Если бы у мозилофилов было чуть меньше амбиций и чуть
> больше мозгов, они бы помогли Ди с библиотеками и язык популяризовался
> гораздо быстрее.У мозилловцев NIH рекордных размеров. От pdf.js до Daala.
э… а ничего, что Daala — это рыбка?
В D нету borrow checker-а, обеспечивающего Rust дополнительную безопасность. К тому же стандартные библиотеки D больше заточены под сборку мусора и нет разграничения памяти между задачами.
> В D нету borrow checker-а, обеспечивающего Rust дополнительную безопасность.об этом думают, есть даже DIP.
> К тому же стандартные библиотеки D больше заточены под сборку мусора
об этом тоже очень сильно думают, в git-е достаточно много подвижек в сторону @nogc-кода. также Александреску выкатил предварительный вариант refcounted строк, и идут обсуждения про то, как и рыбку, и ёлку: и mark/sweep GC иметь, и при необходимости rc GC. пока что ругаются.
> и нет разграничения памяти между задачами.
э? если ты про фиберы (то бишь, сопрограммы) — то да, нет. это, в общем-то, by design, а не flaw. хотя возможно, что из DIP про scoped values такое разграничение получится само собой.
пока что с escape analysis всё не очень весело, потому так.
> > и нет разграничения памяти между задачами.
> э? если ты про фиберы (то бишь, сопрограммы) — то да, нет.
> это, в общем-то, by design, а не flaw. хотя возможно, что из DIP про scoped values
> такое разграничение получится само собой.
> пока что с escape analysis всё не очень весело, потому так.В Rust это называется task (задача), и она даже не фиберная а обычный поток пока что. Но зато сборщик мусора, когда он появится, будет собирать мусор отдельно в каждой задаче, а не во всем процессе. По моему опыту это охуенно важно.
Речь не о том, flaw это или не flaw, а о том что дизайн языков довольно разный, поэтому мем о том что Мозилле надо было использовать D, вместо выдумывания нового языка Rust - не совсем верный.
> Речь не о том, flaw это или не flaw, а о том
> что дизайн языков довольно разный, поэтому мем о том что Мозилле
> надо было использовать D, вместо выдумывания нового языка Rust - не
> совсем верный.а, в этом смысле. тут не спорю. впрочем, я до сих пор не уверен, что сами авторы rust в курсе, что хотят получить на выходе и как это должно выглядеть. но не уверен, что это такой уж огромный недостаток: общая идея у них есть, а что они по дороге насочиняют… может, оно и лучше получится, чем если бы изначально план на скрижалях имелся.
p.s. с другой стороны, обмениваться данными между задачами придётся или явно указывая на смену владельца, или надеяться, что компилятор сможет сам это разрулить (тоже не лучший вариант, на самом деле), или жёстко message passing (это, собственно, подвид первого варианта). то есть, создать экземпляр какой-то фигни и расшарить её с другим потоком будет уже не просто присваиванием.поэтому, например, в D и не внедряют task-local heaps: не очень ясно, как это разруливать так, чтобы и безопасно было, и не надо было ручной код делать, и при этом не потерялась возможность «низкоуровневости».
> p.s. с другой стороны, обмениваться данными между задачами придётся или явно указывая
> на смену владельцаВ Rust "=" - это move, кстати.
Для копирования надо явно указывать clone.