Тут как-то была тема про то, что хочется нормальное сравнение 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.
Ну как, это тянет на «нормальное» сравнение? По-моему, в любом случае интересно почитать.
