LINUX.ORG.RU

Сообщения ozkriff

 

Rust 1.29

Новости — Mozilla
Группа Mozilla

Команда разработчиков Rust сообщает о выпуске новой версии 1.29. Rust — это системный язык программирования, нацеленный на безопасность, скорость и параллельное выполнение кода.

Что вошло в стабильную версию 1.29.0

1.29 привносит не очень много изменений. Ожидается что Rust 1.30 и 1.31 будут очень значительными, так что большая часть 1.29 итерации ушла на подготовку к будущим изменениям. Два самых заметных нововведения этого выпуска даже не касаются самого языка: это две новые возможности Cargo и обе они касаются предупреждений.

  • cargo fix автоматически исправляет предупреждения в коде
  • cargo clippy - статический анализатор Rust кода, помогающий поймать распространенные ошибки и просто улучшить код

cargo fix

С выпуском Rust 1.29 у Cargo появляется новая подкоманда: cargo fix. Если вы когда-либо писали на Rust, то скорее всего уже сталкивались с предупреждениями компилятора. Например, рассмотрим такой код:

fn do_something() {}

fn main() {
    for i in 0..100 {
        do_something();
    }
}

В нем мы вызываем do_something сто раз, но никогда не используем переменную i. Rust предупреждает нас об этом:

> cargo build
   Compiling myprogram v0.1.0 (file:///path/to/myprogram)
warning: unused variable: `i`
 --> src\main.rs:4:9
  |
4 |     for i in 1..100 {
  |         ^ help: consider using `_i` instead
  |
  = note: #[warn(unused_variables)] on by default

    Finished dev [unoptimized + debuginfo] target(s) in 0.50s

Видите подсказку о переименовании в _i? Мы можем автоматически применить ее при помощи cargo fix:

> cargo fix
    Checking myprogram v0.1.0 (file:///C:/Users/steve/tmp/fix)
      Fixing src\main.rs (1 fix)
    Finished dev [unoptimized + debuginfo] target(s) in 0.59s

Если теперь мы откроем src\main.rs, то увидим исправленный код:

fn do_something() {}

fn main() {
    for _i in 0..100 {
        do_something();
    }
}

Теперь в коде используется _i, и предупреждение больше не выдается.

Первая версия cargo fix исправляет далеко не все предупреждения. Для своей работы cargo fix использует специальный API компилятора, который предлагает исправлять только те предупреждения, в которых мы абсолютно уверены. Со временем их список будет расширяться.

cargo clippy

Еще о предупреждениях: теперь вы можете попробовать cargo-clippy через Rustup. Clippy это статический анализатор, который выполняет много дополнительных проверок вашего кода.

Например:

let mut lock_guard = mutex.lock();

std::mem::drop(&lock_guard)

operation_that_requires_mutex_to_be_unlocked();

Синтаксически это правильный код, но мы можем получить дедлок, потому что вызвали drop для ссылки на lock_guard, а не самого lock_guard. Вызов drop для ссылки имеет мало смысла и почти наверняка является ошибкой.

Установим предварительную версию Clippy через Rustup:

$ rustup component add clippy-preview

и запустим ее:

$ cargo clippy
error: calls to `std::mem::drop` with a reference instead of an owned value. Dropping a reference does nothing.
 --> src\main.rs:5:5
  |
5 |     std::mem::drop(&lock_guard);
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[deny(drop_ref)] on by default
note: argument has type &std::result::Result<std::sync::MutexGuard<'_, i32>, std::sync::PoisonError<std::sync::MutexGuard<'_, i32>>>
 --> src\main.rs:5:20
  |
5 |     std::mem::drop(&lock_guard);
  |                    ^^^^^^^^^^^
  = help: for further information visit https://rust-lang-nursery.github.io/rust-clippy/v0.0.212/index.html#drop_ref

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

Обратите внимание, что это только ознакомительная версия; Clippy еще не достиг 1.0, поэтому набор и поведение проверок еще могут меняться. Мы выпустим компонент clippy, как только он будет стабилизирован, а пока просим вас посмотреть на деле предварительную версию и рассказать нам о своем опыте.

Да, есть еще нюанс: к сожалению, пока что нельзя использовать clippy вместе с cargo-fix. Работа над этим ведется.

Подробности смотрите в примечаниях к выпуску.

Стабилизация стандартной библиотеки

В этом выпуске были стабилизированы следующие API:

Также, теперь вы можете сравнивать &str и OsString.

Подробности смотрите в примечаниях к выпуску.

Улучшения в Cargo

Выше мы уже описали две новые подкоманды Cargo. Так же, Cargo теперь будет автоматически пытаться починить Cargo.lock файлы, испорченные git mergeом. Это поведение можно отключить флагом --locked.

cargo doc обзавелся новым флагом: --document-private-items. По умолчанию, cargo doc документирует только публичные части API, потому что предназначен для генерации пользовательской документации. Но если вы работаете над своим пакетом и в нем есть внутренняя документация, то --document-private-items включит генерацию документации вообще для всего.

>>> Примечания к выпуску

>>> Подробности

 ,

ozkriff
()

glium - безопасная обертка над OpenGL на Rust

Форум — Development

Томака написал довольно развернутый пост о своей библиотеке - https://medium.com/@tomaka/the-glium-library-5be149d87dc1.

glium - безопасная обертка средней толщины над OpenGL на Rust.

https://github.com/tomaka/glium

Цели glium:

  • Автоматическое управление многими тонкостями OpenGL, которые при неправильном использовании могли бы привести к падениям.
  • Предоставление интерфейса, который навязывает хорошие практики, вроде RAII или отсуствия состояния.
  • Совместимость со всеми версиями OpenGL, где есть шейдеры, и сглаживание различий между ними.
  • Раннее обнаружение ошибок. В идеале - во время сборки.
  • Оптимизация/реорганизация порядка вызовов OpenGL и упрощение использования современного OpenGL.

Даже несколько сыроватых уроков есть - 1, 2, 3.

Комменты к посту в реддите - /r/rust, /r/programming

Лично я им пока особо не пользовался, но подумываю заменить им часть своих кривых наколенных оберток над голым gl-rs. С виду оно немного громоздкое (хотя это вина OpenGl`ей) и долго собирается, но интересное. И, что важно, Томака активно занят его развитием.

Этот же чувак написал, например, glutin - альтернативу sdl/glfw на ржавчине и hlua - привязки к Lua.

Отзыв Томаки о ржавчине - https://internals.rust-lang.org/t/production-user-research-summary/2530/9. Кстати, там вообще интересное обсуждение.

 , , ,

ozkriff
()

The Advanced Rust Programming Language (книга)

Форум — Development

Выложили черновик книги «The Advanced Rust Programming Language».

https://doc.rust-lang.org/nightly/adv-book

Все сырое, конечно, но даже сейчас есть вполне полезная информация.

 

ozkriff
()

Сравнение Rust и C++ на примере трассировщика путей

Форум — Development

Тут как-то была тема про то, что хочется нормальное сравнение C++ и Rust. Вот эта серия статей, как мне кажется, вполне себе кандидат:

На днях вышла последняя часть, и я ее зачем-то перевел, пока читал. Выложу тут, чего пропадать. Ошибок и неточностей много, но мне очень лениво, извиняюсь. Вооот:

Разработка трассироващика путей на Rust`е, часть 7: Заключение

Чтобы изучить Rust, я портировал свой спекртальный трассировщик путей Luculentus на язык Rust. Результат я выложил на Github. В процессе я также немного обновил Luculentus, переведя его на более современный C++. Детали вы можете прочитать в прошлых постах. В этом же посте я хочу подвести итоги и сравнить результаты.

Картинка

Для начала, пример вывода трассировщика путей! Захардкоженная сцена выглядит вот так:

http://ruudvanasseldonk.com/images/robigo-luculenta.png

Если вам интересно что-то в ней изменить, то смотрите set_up_scene в app.rs.

Начало работы с Rust

В настоящий момент, вы можете установить компилятор Rust`а и Cargo за пару минут, даже в Windows. Да и заставить их работать было намного проще, чем, например, Scala и sbt.

Сообщество Rust`а показалось мне очень дружелюбным. Когда я не знал что делать, мне очень помогали IRC канал и /r/rust. Члены основной команды разработки языка есть и там и там, так что часто советы были весьма профессиональными.

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

Владение

Если бы мне надо было описать Rust одним словом, это было бы «владение». Для меня, это то, что отличает Rust от остальных языков. В большинстве языков владение неявно и это приводит к нескольким типам ошибок. Когда в Си функция возвращает указатель, кто ответственен за освобождение памяти? Вы можете ответить на этот вопрос без подглядывания в документацию? И даже если вы знаете ответ, то все равно легко забыть освободить память или освободить ее дважды.

Проблема относится не только к указателям, она касается все ресурсов. Может показаться, что сборка мусора это отличное решение, но она работает только для памяти. Тогда вам нужен другой способ для освобождения ресурсов (вроде файловых дескрипторов) и все проблемы возвращаются. Например, сборщик мусора в C# спасает от ошибок «использования после освобождения» (use after free), но ничего не спасает вас от ошибок «использования после удаления» (use after dispose). Разве ObjectDisposedException намного лучше сегфолта? Из-за явного времени жизни и системы владения в Rust нет этих типов ошибок.

прим. ozkriff: поскольку я с C# знаком мало, то пришлось загуглить про этот ObjectDisposedException. Вот пример кода:

using System;
using System.IO;

public class ObjectDisposedExceptionTest 
{
   public static void Main()
   {     
      MemoryStream ms = new MemoryStream(16);
      ms.Close();
      try 
      {
         ms.ReadByte();
      }
      catch (ObjectDisposedException e) 
      {
         Console.WriteLine("Caught: {0}", e.Message);
      }
   }
}

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

Обновление Luculentus

Сами по себе достоинства явного владения не уникальны для Rust`а. Такой же код можно написать на современном C++, который очень сильно отличается от С++ до-2011. Когда я писал Luculentus, C++11 поддерживался только частично. Я использовал много простых указателей, которые сегодня уже не нужны. Я заменил большинство простых указателей в Luculentus на shared_ptr или unique_ptr, а массивы на векторы. Как следствие, все ручные деструкторы пропали. (Раньше их было шесть). Раньше было 11 операторов удаления, теперь их нет. Все управление памятью стало автоматическим. Это сделало код не только короче, но и снизило вероятность появления ошибок.

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

Но все же, обновление демонстрирует, что возможно писать относительно безопасный код и на С++. Вы получаете безопасность и автоматическое управление памятью практически без накладных расходов. Единственной проблемой является то, что вы должны очень настойчиво стремиться к этому. Вы можете использовать unique_ptr, но так же можете и простой указатель. Все опасные инструменты «старого» С++ все еще доступны и вы можете смешивать их с новым С++. Конечно, есть определенная ценность в возможности собирать старый код (Бьерн называет это достоинством), но я бы предпочел не смешивать неявно эти две парадигмы и не поддерживать старые ошибочные решения. Требуется некоторое время, что бы разучиться использовать new и delete, но даже тогда старые API останутся с нами на очень долгое время.

Новое начало

Хорошим моментом в Rust является то, что он может начать все практически с чистого листа и учиться на ошибках старых языков. C++11 немного лучше своего предшественника, но он только добавляет новое и обязан поддерживать обратную совместимость. Одна из вещей, на которой это хорошо видно - синтаксис. В Rust, типы идут после имени и возвращаемый функцией тип идет после списка аргументов, что очень разумно. Синтаксис анонимных функций в Rust короток и в нем меньше повторения. Но я так и не могу привыкнуть к египетским скобкам, они до сих пор выглядят как-то не так.

Другим моментов, в котором Rust сделал правильный выбор, является мутабельность. В Rust`е все по-умолчанию неизменяемо, когда как в C++ наоборот. В коде Luculentus 535 раз появляется «const» (на момент написания). В Robigo Luculenta всего 97 «mut». Конечно, в C++ больше дублирования, но это все равно показывает, что неизменяемость по-умолчанию - лучше. Так же, компилятор Rust выдает предупреждение о переменных, которым не нужно быть изменяемыми, это тоже хорошо.

Несмотря на то, что синтаксис является делом вкуса, есть и измеряемые величины. Если я сравню количество непробельных символов в коде, то у С++ будет примерно 109 тысяч символов (не считая файлы, которые я не портировал на Rust), а у Rust - 74 тысячи. Почти на треть меньше.

C++ славится своими информативными и понятными сообщениями об ошибках, когда что-то идет не так в шаблонном коде. Ошибки в Rust`е, в основном, намного более понятны, но некоторые тоже могут напугать:

error: binary operation `/` cannot be applied to type `core::iter::Map<'_,f32,f32,core::iter::Map<'_,&[f32],f32,core::slice::Chunks<'_,f32>>>`

Производительность

Я добавил базовые счетчики производительности в Luculentus и Robigo Luculenta. Они считают количество завершившихся задач трассировки (trace tasks) в секунду. Вот результаты:

Компилятор              платформа           производительность

GCC 4.9.1*              Arch Linux x64      0.35 ± 0.04
GCC 4.9.1               Arch Linux x64      0.33 ± 0.06
rustc 0.12 2014-09-25   Arch Linux x64      0.32 ± 0.01
Clang 3.5.0             Arch Linux x64      0.30 ± 0.05
msvc 110                Windows 7 x64       0.23 ± 0.03
msvc 110*               Windows 7 x64       0.23 ± 0.02
rustc 0.12 2014-09-23   Windows 7 x64       0.23 ± 0.01

Везде выставлены самые высокие уровни оптимизации. Компиляторы со звездочкой использовали PGO (Profile-guided optimization - оптимизация, управляемая профилированием https://ru.wikipedia.org/wiki/Profile-guided_optimization). Единственный вывод, который я могу сделать из этого, что вам, наверное, не стоит использовать Windows для сильно нагружающих процессор приложений.

Во второй статье из этой серии я отметил, что код на Rust`е собирается очень быстро, но тогда было не много кода. Сейчас время сборки вот такое (в секундах):

Компилятор             Время

rustc 0.12 2014-09-26  7.31 ± 0.05
Clang 3.5.0            13.39 ± 0.03
GCC 4.9.1              17.3 ± 0.5
msvc 110               20.4 ± 0.3

Сборка теперь не так быстра, но все равно быстрее С++.

Заключение

Изучать Rust было интересно. Мне понравился язык и портирование привело к нескольким озарениям, которые могут улучшить и оригинальный код. Владение часто неявно в других языках, что увеличивает чувствительность кода к человеческим ошибкам. Rust делает владение явным, убирая возможность допущения подобных ошибок. Все безопасно по умолчанию. Все это сдвигает Rust намного ближе к краю «стабильность» на спектре, чем к краю «быстрая разработка». Я не написал на Rust`е достаточно кода, что бы быть на 100% уверенным, но пока что достоинства Rust`а перевешивали его недостатки. Если бы я выбирал между C++ и Rust`ом для своего следующего проекта, то выбрал бы Rust.

Ну как, это тянет на «нормальное» сравнение? По-моему, в любом случае интересно почитать.

 ,

ozkriff
()

Road to Rust 1.0

Форум — Development

Нико опубликовал новый пост в официальном блоге Rust про выпуск стабильной версии:

http://blog.rust-lang.org/2014/09/15/Rust-1.0.html

Вроде, никаких особых сюрпризов, все по плану.

Если коротко, то:

В конце года собираются выпустить бета-версию языка, которая, по прошествии некоторого времени, должна стать версией 1.0. Если во время бета-тестирования будут обнаружены серьезные недостатки, то выпуск 1.0 отложат. Последующие версии 1.* будут обратно совместимы.

Язык очень сильно упростили за последний год, ядром языка стали концепций владения и одалживания (ownership and borrowing). Обращают внимание, что версия 1.0 это не финальный и законченный продукт, а скорее минимальная стабильная основа, на которой можно уже наращивать экосистему. Для последнего очень важным шагом было создание и внедрение в существующие программы и библиотеки пакетного менеджера Cargo, который будет активно улучшаться.

Из комментариев к статье:

1.0 will not be done, complete, useful or production-ready in the sense you'd expect from a modern batteries-included language/platform. It will be «nothing left to take away».

Планируемые к версии 1.0 значительные изменения в самом языке (в статье есть ссылки на подробности по каждому пункту):

  • Типы переменного размера (DST);
  • Упрощение замыканий (Unboxed closures);
  • Ассоциативные типы (Associated types);
  • Конструкция 'where' (Where clauses);
  • Трейты с множественной диспечеризацией (Multidispatch traits);
  • Улучшение деструкторов;
  • Вынос зеленых потоков из стандартной библиотеки;

(Кстати, большая часть даже этих изменений не ломает уже написанный код)

Обсуждения:

 ,

ozkriff
()

Статья «What does Rust's „unsafe“ mean?»

Форум — Development

Huon Wilson выложил в своем блоге небольшую статью о unsafe в языке Rust «What does Rust's „unsafe“ mean?».

Обсуждения в реддите: в /r/rust и в /r/programming

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

Кстати, в статье есть ссылки на интересную серию статей из блога LLVM про неопределённое поведение часть 1 часть 2 часть 3. Как по мне, из них интереснее всего третья часть, где говорится о том, почему нельзя просто так взять и выдавать ошибку компиляции при любом UB.

 , ,

ozkriff
()

Презентация «Rust - лучше, чем C++» на русском языке от разработчика из Яндекса

Форум — Development

http://tech.yandex.ru/events/cpp-party/june-minsk/talks/1978

Степан Кольцов

Яндекс

Rust — это современный, практический, быстрый и безопасный язык программирования. Некоторые говорят, что Rust — это как C++, если бы его писал человек, знающий Haskell.

Система типов Rust решает главную проблему C++ — небезопасность. C++ очень легко сделать ошибки, которые приведут к поломкам (например, use after free). Rust позволяет писать безопасный код, сохраняя при этом выразительность и околонулевые накладные расходы C++. В докладе будут подробно описаны механизмы языка, которые контролируют безопасность программы.

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

 

ozkriff
()

«Rust by Example» и «Rust for C++ programmers»

Форум — Development

Привет лор. Это опять я и опять с Ржавчиной, точнее с парочкой ссылок по этой теме :) .

http://rustbyexample.com - изучение языка на основе очень коротких примеров с минимумом комментариев (очевидно влияние gobyexample.com).

Rust for C++ programmers - постепенно растущий цикл статей для С++ программистов.

На данный момент 7 статей:

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

P.S.: и между делом упомяну, что все-таки решили добавить оптимизацию хвостовых вызовов, но уже после выпуска стабильной версии:

Rust, tail call optimization (комментарий)

 

ozkriff
()

В Rust хотят заменить &mut на &uniq и убрать константность по умолчанию

Форум — Development

Я тут на днях постил ссылку про значительные изменения в синтаксисе Ржавчины - заменили тильду на «box» - В Rust убрали ~ синтаксис . Так вот это микроскопическое изменение, по сравнению со свежими эпическими идеями разработчиков.

One sentence summary

I would like to remove the distinction between immutable and mutable locals and rename &mut pointers to &my, &only, or &uniq (I don’t care). There would be no mut keyword.

Серьезно подумывают убрать классную и всеми любимую константность по-умолчанию и вообще ключевое слово «mut» и вместо этого сосредоточиться на концепции владения и ввести ключевое слово «uniq» или «only».

Краткий пересказ мотивации затрудняюсь сделать, лучше просто прочитать пост:

http://smallcultfollowing.com/babysteps/blog/2014/05/13/focusing-on-ownership

Срач в реддите:

http://www.reddit.com/r/rust/comments/25i544/babysteps_focusing_on_ownership_...

Я пока не определился с мнением по этому вопросу. Вроде как мотивация вполне разумная, но мне как-то стремно думать о жизни без иммутабельности по-умолчанию.

P.S.: Если кто-то раньше думал и сейчас думает «Rust не нужен», то можно это не писать, я и так предполагаю «ненужна!» точкой зрения по-умолчанию каждого лоровца по любому вопросу.

 

ozkriff
()

В Rust убрали ~ синтаксис

Форум — Development

Тут многие в комментариях ругались на тильда-синтаксис. Вот, его на днях (уже есть в ночных сборках) заменили на более гибкий box-синтаксис.

Для тех, кто в танке и ленится проглядеть RFC: тильда синтаксис использовался для выделения памяти в куче. Box-синтаксис делает то же самое по умолчанию, но еще и поддерживает произвольные аллокаторы.

RFC с подробностями: https://github.com/rust-lang/rfcs/blob/8ec267f2feb24d5/active/0014-remove-til...

«issue: Remove ~, add Box»: https://github.com/mozilla/rust/issues/13885

Обсуждение в r/rust: http://www.reddit.com/r/rust/comments/24elup/rfc_remove_in_favor_of_box_and_box

Срач^WОбсуждение в Hacker News: https://news.ycombinator.com/item?id=7687351

Вдруг кому интересно, а не просто «ненужно! ненужно!».

 

ozkriff
()

В Rust добавлены compile-time регулярные выражения

Форум — Development

В стандартную библиотеку языка Rust добавлены регулярные выражения, реализованные через макросы (компилируются во время компиляции программы).

Подробности:

http://blog.burntsushi.net/rust-regex-syntax-extensions

Обсуждения:

http://www.reddit.com/r/rust/comments/243bw9/syntax_extensions_and_regular_ex...

http://www.reddit.com/r/programming/comments/2441r9/syntax_extensions_and_reg...

https://news.ycombinator.com/item?id=7654361

 , ,

ozkriff
()

Презентация «Rust Me, I'm a Developer!»

Форум — Development

Если ты не смог осилить официальное введение в Rust, потому что там не было смешных картинок, то вот твой шанс! Презентация «Rust Me, I'm a Developer!» от Greg Malcolm (130 слайдов):

https://speakerdeck.com/gregmalcolm/rust-me-im-a-developer

PDF

 

ozkriff
()

оцените код

Форум — Development

Доброго времени суток.

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

Хотелось бы услышать конструктивную критику и советы по поводу общей адекватности программы, читаемости кода и т.п.

Собственно, сам код(~1700 строчек, не стал разбивать): http://pastebin.com/Jn6M2ZAi (другой пастбин)

Выглядит у меня это безобразие как то так(vim, lubuntu):
http://a.imageshack.us/img802/7849/201008151605161024x768s.png
http://a.imageshack.us/img405/6287/201008151603291024x768s.png
http://a.imageshack.us/img121/5639/201008151604391024x768s.png

ozkriff
()

RSS подписка на новые темы