Сегодня мне удалось немного с другой стороны посмотреть на Rust, что дало интересную пищу для размышлений. В общем случае я склонялся к мнению, что Rust – это, конечно, прекрасно, но по уровню сложности он мало чем уступает C++, а при таком раскладе зачем нужно разбираться с еще одним монстром? Но, похоже что, эта позиция может быть довольно большим заблуждением.
Posts Tagged → Rust programming language
Rust и социальные факторы
Так сложилось, что вчера, с одной стороны, Евгений провел довольно интересную аналогию между моделью памяти Rust и книгой и это была, наверное, самая наглядная иллюстрация различий в отличиях управления памятью между Rust и C++. А с другой стороны я прочитал “Memory Management Patterns in Business-Level Programs” из 148 выпуска Overload в которой вскользь затронут этот же вопрос. В обоих случаях отношение к изменениям принесенным Rust на мой взгляд очень разумное: изменения на выдающиеся не тянут и решают уже решенную со времен C++14 (хотел бы написать со времен C++11, но
При этом, все мы живем в обществе, работаем в командах и не можем игнорировать вау эффекты и стадные инстинкты. По не очень понятным мне причинам я со всех сторон наблюдаю щенячий восторг по поводу Rust от людей которых я бы ну никак не заподозрил в таком. Например сегодня был диалог с очень продвинутым Python-разработчиком и не менее продвинутым C# разработчиком о том, что Rust – это круто, Rust – это нам надо и мы уже начали затягивать его в нашу кодовую базу. При этом какие-либо аргументы в пользу того, что то же самое можно сделать в меньшее количество легче воспринимающихся строк кода на C++14 (так как код не будет изобиловать модификаторами времени жизни) отбрасываются сразу с аргументами “я 15 лет назад на C++ писал – жуткое убожество”.
Наблюдая за скоростью продвижения Rust исключительно (как мне кажется) за счет этого загадочного вау-эффекта начинаешь задумываться, а может всё же стоит вложиться в него временем более серьезно? Не по тому, что такое большое количество народу не может ошибаться, а потому, что когда говоришь с фанатиками и понимаешь предмет их фанатизма, легче “продать” что-то кажущееся правильным и нужным лично тебе. И пусть логически проект проще и быстрее выполнить на C++, желание сделать на чем-то ином очень важный стимул который довольно часто положительно сказывается на качестве готового решения. Единственная и самая главная неизвестная для меня в этом вопросе, а на как долго хватит этого Растоманского запала? Что же будет после него? Понятно, что C++ был, есть и будет, но вот Rust…
Rust и Я
У меня, как наверное и у многих других C++ разработчиков какие-то сложные отношения с Rust. Этот язык вроде как и очень сильно нравится и в то же время всё сложно. На сей раз моя попытка заняться Rust в серьез зашла куда дальше чем обычно (обычно я после нескольких небольших тестиков удовлетворенно забрасывал изучение) – я нашел компанию которой нужны Rust разработчики, связался с ними и взял тестовое задание. Тестовое задание просто восхитительное, не сложное, но помогает понять главное – хочешь ли ты связываться с языком или нет?
На тестовое задание я честно потратил часов 8 и за это время успел заглянуть в tokio, которая, как я понимаю, является образцово-показательной библиотекой для написания асинхронных сетевых приложений. Честно говоря, я до сих пор в состоянии смятении, но точно знаю одно – видеть такое и не дай бог поддерживать на постоянной основе я точно не хочу. К примеру, вот кусок кода, который читает данные из канала и шлет их по TCP:
Box::new(tcp.map(move |stream| {
let (sink, stream) = stream.framed(Bytes).split();
pool.execute(stdin.forward(sink).then(|result| {
if let Err(e) = result {
panic!("failed to write to socket: {}", e)
}
Ok(())
})).unwrap();
stream
}).flatten_stream())
let (sink, stream) = stream.framed(Bytes).split();
pool.execute(stdin.forward(sink).then(|result| {
if let Err(e) = result {
panic!("failed to write to socket: {}", e)
}
Ok(())
})).unwrap();
stream
}).flatten_stream())
Несколькими месяцами раньше я баловался с биндингами к libClang, где было всё читабельно и очевидно, что наводит на мысли, что написать на Rust можно писать как в адекватном и легко поддерживаемом стиле, так и городить write-only код в духе приведенного выше. И надо отметить что в примере выше чувствуется и стиль и задумка. Если в него какое-то время повтыкать (желательно в IDE с навигацией, очень рекомендую IntelliJ Rust), то становится понятно что хотел сказать автор и почему. Только вот “НУ ЗАЧЕМ?!?!” не покидает.
В итоге мне в очередной раз стало казаться, что за пределами небольших сообществ гиков Rust взлететь не может, так как поддерживать столь неочевидные решения должно быть даже дороже чем решения на C++ с ручным управлением памятью (в конце концов, санитайзерами можно отловить практически всё). Не знаю чем это вызвано, скорей всего тем, что Rust развивает комьюнити гиков, а C++ комитет старперов. В результате в Rust тянут все, что круто выглядит, а в C++ только то, что “мегамозги” одобрили. Побочным эффектом этого выступает то, что в Rust многие удобные вещи доступны сразу или почти сразу, а в C++ это “наверное будет реализовано после C++20” (да-да, это я про Meta).
Наверное, меня всё равно не отпустит и баловаться с Rust я не перестану. Но вот подаваться на позицию “Rust разработчик” я довольно долгое время точно не буду, сообщество должно наиграться в “zero cost abstractions” для начала
Эксперименты с Rust
В течении последних лет я время от времени с интересом поглядывал на Rust, наверное, с версии 0.3. За это время язык претерпел много изменений, за счет чего он то нравился, то совсем не нравился, то вызывал сомнения. Но не смотреть на него было никак нельзя, так как языков, подходящих для “коробочной” разработки и не генерирующих байт-код, по пальцам одной руки пересчитать можно и еще свободные пальцы останутся.
Плотно поработав с Go в течении последнего года, я вновь подумал о том, что Rust довольно интересен, и стоит попробовать решить с его помощью практическую задачу. Мне как раз нужно было приложение для генерации оператора вывода всех членов класса/структуры в поток, на этой задаче я и решил остановиться. Мелочь, конечно, но полезно, нужно лично мне и позволяет сделать как минимум поверхностные выводы о пригодности языка для повседневного использования.
Подготовка к работе
Rust, конечно, не может похвастаться таким изобилием редакторов, как C++ или Go, но для относительно квалифицированного разработчика, привыкшего к командной строке, того, что есть, более чем достаточно. При этом управление зависимостями, создание проектов, установка внешних утилит выше всяких похвал.
Установка
Сам компилятор и набор утилит типа cargo устанавливается и обновляется очень легко и удобно, особенно на UNIX-ах. Всего одна консольная команда в соответствии с официальной документацией. Windows никогда особо дружелюбным для разработчиков не был, хотя и тут разработчики Rust постарались и сделали как поддержку GNU toolchains, так и поддержку MSVC. Всё заработало “из коробки”, что несказанно меня удивило. Ощущение зрелости как минимум системы доставки и развертывания однозначно присутствует.
Редактор
В моём случае с редактором было всё просто: взять Vim да установить пару-тройку дополнений к нему. Подсветка и форматирование работают отлично, автодополнение, базирующееся на racer, работает сносно. Как я понял, все остальные редакторы и IDE также используют racer для автодополнения и ожидать какого-то чуда за пределами VIM не следует. Понадобилось всего два плагина: rust.vim и vim-racer. В обоих случаях они снабжены достаточно подробной документацией и никакой сложности установка и настройка не вызывает.
Особо хотелось бы отметить наличие rustfmt, который позволяет форматировать код в едином стиле. Впервые я проникся любовью к такого рода приложениям, начав работать с Go, где весь код автоматически форматируется одним единственным правильным способом. В командной работе практика оказалась невероятно удобной, так как из “стандарта кодирования” команды полностью исчезает пункт про форматирование, при этом весь код выглядит одинаково, что облегчает понимание и работу с чужими фрагментами/модулями. После этого я внедрил у нас использование clangformat на C++ проектах (правда уже с единым набором правил для форматирования), что также сделало разработку ощутимо комфортнее.
Также в Vim большой популярностью пользуется плагин Tagbar, который не умеет работать с Rust из коробки, но это очень легко исправляется.
Еще одним потенциально полезным компонентом экосистемы Rust мне показался cargo-outdated, позволяющий отслеживать устаревшие зависимости. Ну просто мечта разработчика C++ какая-то, особенно учитывая то, что сторонние компоненты (дополнения) Rust устанавливаются при помощи cargo очень простым способом:
cargo install rustfmt
cargo install racer
cargo install cargo-outdated
cargo install racer
cargo install cargo-outdated
Создание проекта
Я не раз сталкивался с мнением, что Rust можно полюбить хотя бы за наличие Cargo в нём. Попробовал и не могу не согласиться: всё очень просто и удобно.
cargo new --bin ddump-gen
И у меня есть новый проект, в котором, путем добавления всего двух строчек, я могу работать с libclang:
[dependencies]
clang = "0.16.0"
clang = "0.16.0"
Это интересно само по себе хотя бы тем, что изначально я порывался написать тот же проект на C++, но бросил уже на стадии написания cmake-файла для этой же самой libclang.
Разработка
Теперь о самом главном: насколько удобно писать и поддерживать код на Rust. Для меня вопрос показался относительно сложным и полностью зависящим от текущих привычек и рабочих инструментов.
Доступные библиотеки
То, что Rust активно пиарится Mozilla и Samsung в течении последних лет, очень положительно сказалось на количестве доступных новых библиотек, а также оберток для уже существующих библиотек из мира C/C++. В результате очень быстро подобралась подходящая обертка над libClang, был найден удобный парсер командной строки и подходящий логгер. Довольно удивительно, но на решение тех же вопросов на C++ я бы потратил даже больше времени, чем в совершенно незнакомой экосистеме.
Про язык
С самим языком всё не столь однозначно и прекрасно. Наверное, если бы не опыт последних месяцев с Go, я бы просто подивился тому, почему же так неудобно обрабатывать ошибки, и отложил бы эксперименты до “лучших времен”. Но вот после того, как желание обязательно иметь в языке исключение прошло, оказалось, что с кодами возврата, особенно при наличии сопоставления с образцом, жить можно довольно комфортно.
Собственно говоря, к чему весь этот разговор про обработку ошибок. При отсутствии исключений в языке размер кода растет, так как, во-первых, появляется необходимость проверять коды возврата и не ожидать, что “исполнилось корректно либо выполнение было прервано”, а во-вторых, теряется возможность сделать обобщенную обработку нескольких потенциальных ошибок в одном блоке. Если задуматься над причиной, то её можно сформулировать как “мне нужно писать больше кода, но лень”. Есть ли в такой необходимости что-то хорошее? Опыт с Go подсказывает, что есть! Адресная обработка ошибок, т.е. сразу после возникновения ошибочной ситуации, обычно более качественно продумана и лучше покрыта диагностикой по сравнению с обобщенными исключениями. Кроме того, в стандартной библиотеке Rust пошли чуть дальше и добавили немного синтаксического сахара. Особо полезными, на мой взгляд, являются функции семейства
let path = matches.value_of("SRC_FILE").unwrap();
Смело потому, что попытка
let std = matches.value_of("STD_VER").unwrap_or("11");
Среди относительно новых изменений языка числится `?`-синтаксис, которым я так и не решился воспользоваться, так как, на мой взгляд, он делает код просто невероятно сложно поддерживаемым и является злом по определению. Лучше уж отдать предпочтение макросу
Ужас прошлых версий с временем жизни объектов разработчики спрятали, и теперь код можно, обычно, писать, особо не задумываясь о том, как удовлетворить компилятор. В версиях около 1.0 это был невероятно сильный отталкивающий фактор, так как вместо решения проблемы ты занимался удовлетворением хотелок компилятора буквально с первой линии кода. Само собой, правила никуда не делись, но компилятор стал ощутимо умнее.
В то же время мне сильно не нравится количество смысловой нагрузки на одну линию кода. Даже в простейшем примере выше с
Кому может быть интересен
В интернете можно найти довольно много мнений и споров на тему того, является ли Rust “убийцей C++” или нет. Смешные дискуссии, особенно с учетом того, сколько своих “убийц” C++ пережил. Поэтому я не буду говорить о том, кого же Rust вытеснит, только время рассудит, но вот кому и когда он может пригодиться, уже более интересно.
Во-первых, на современном Rust писать удобно и комфортно, инфраструктура хороша и проблем не вызывает. Во-вторых, появилось много библиотек в разной степени готовности (зачастую полностью готовых к коммерческому использованию), которые можно использовать и не заниматься решением утилитарных задач. В-третьих, детские болезни компилятора и языковой стилистики в основном исправлены. В-четвертых, сообщество Rust очень-очень активное и доступно большое количество вводных сайтов и полезной документации.
По моим ощущениям, при помощи современного Rust проблемы могут быть решены как минимум не хуже, чем при помощи современного C++, и более качественно, чем на современном Go. Так, для C++ программиста, активно использующего C++11 с STL и BOOST в повседневной работе, Rust может показаться ограниченным языком, особенно за счет куда как более бедной системы метапрограммирования и особенностей обработки ошибок. В то же время, для разработчика, активно использующего C++ с Qt или тот же Go, всё должно быть наоборот, приятно и комфортно. Если говорить про порог входа, то, с одной стороны, он однозначно выше, чем в случае с Go, начать писать на котором можно через 3-4 дня активного изучения документации и лучших практик. С другой стороны, информация, с которой придется ознакомиться, куда менее объемная и запутанная, чем даже минимальное вводное чтиво по C++.
Для себя я сделал вывод, что буду и дальше использовать Rust в “домашних проектах” и, при возможности, протолкну его продуктовую разработку в команде. Жизнь будет проще, жизнь будет веселее!
FFI и Rust
Продолжаю бороться с типами. Есть надежда, что FFI (Foreign Function Interface) – это самая сложная и последняя часть, где система типов в Rust будет доставлять серьезные неудобства. Пока что, главное выстраданное правило гласит: если тебе Rust не дает написать какую-то конструкцию, то эта конструкция зло. То есть не надо пытаться обмануть систему типов и писать “как привык в C++”. Довольно простой, если верить документации на сайте Rust, интерфейс FFI оказался с заковырками. Даже пришлось создать маленькую песочницу для игр именно с FFI.
Наверное самая поразившая меня фича в этой области Rust-а – преобразование типов, особенно при работе с массивами. Простейший пример (
let array: &[u8] = unsafe { mem::transmute("Rust") }; // (1)
println!("type: {}, ptr: 0x{:x}, len {}",
type_of(&array), array.as_ptr() as u64, array.len());
let new_array: &[u32] = unsafe { mem::transmute(array) }; // (2)
println!("type: {}, ptr: 0x{:x}, len {}",
type_of(&new_array), new_array.as_ptr() as u64, new_array.len());
println!("type: {}, ptr: 0x{:x}, len {}",
type_of(&array), array.as_ptr() as u64, array.len());
let new_array: &[u32] = unsafe { mem::transmute(array) }; // (2)
println!("type: {}, ptr: 0x{:x}, len {}",
type_of(&new_array), new_array.as_ptr() as u64, new_array.len());
Классический вопрос из разряда “а что оно напечатает?”. Кажется что всё невероятно просто, создаем массив
type: &'static [u8], ptr: 0x1037a1414, len 4
type: &'static [u32], ptr: 0x1037a1414, len 4
type: &'static [u32], ptr: 0x1037a1414, len 4
Но был сильно удивлен. Дело в том, что по мнению компилятора Rust второй массив хоть и является массивом uint32, но по прежнему содержит 4 элемента, т.е. конверсия делается в лоб и только для типа, но не размера и физический размер “вырос” в 4 раза без перераспределения памяти.
При этом вроде как правильное решение будет выглядеть следующим образом:
let new_array_2 = unsafe {
slice::from_raw_parts_mut(array.as_ptr() as *mut u32,
array.len() / mem::size_of::<u32>())
};
println!("type: {}, ptr: 0x{:x}, len {}",
type_of(new_array_2), new_array_2.as_ptr() as u64, new_array_2.len());
slice::from_raw_parts_mut(array.as_ptr() as *mut u32,
array.len() / mem::size_of::<u32>())
};
println!("type: {}, ptr: 0x{:x}, len {}",
type_of(new_array_2), new_array_2.as_ptr() as u64, new_array_2.len());
Хотя меня гложут сомнения на тему того, что я правильно всё делаю, так как вывести новый размер массива вроде очень просто из чего следует что я вызвал какую-то неправильную функцию, или правильную, но криво…
Мелкие пакости: время жизни переменной в Rust
Допустим, хочется получить текстовое представление типа переменной в Rust. При этом в язык входит такая замечательная функция как
fn type_of<'a, T>(_: T) -> &'a str {
unsafe { std::intrinsics::type_name::<T>() }
}
unsafe { std::intrinsics::type_name::<T>() }
}
Но тут возникнет довольно занятная проблема, так как переменная становится недоступной после (с некоторыми ньюансами в зависимости от типа) получения её имени:
error: use of moved value: `*variable_name` [E0382]
После небольшой фрустрации понимаешь, что в принципе это ж фича и компилятор не должен догадываться о моих намерениях только лишь получить тип, а не реально использовать значение. Но делать что-то нужно. Единственным подходящим решением оказывается передача по ссылке (ссылке в понимании Rust, а не C++), что ожидаемо, но немного странно для C++ разработчика.
fn type_of<'a, T>(_: &T) -> &'a str {
unsafe { std::intrinsics::type_name::<T>() }
}
unsafe { std::intrinsics::type_name::<T>() }
}
Вообще, все эти мелкие пакости модели памяти постоянно преследуют при программировании на Rust. Никак не могу понять, это реально зло или я просто еще не привык и просто мыслю моделью памяти C++?
Rust в Dropbox
Как мне кажется, не так давно произошло довольно знаковое событие для мира C++: Dropbox заявил о том, что перевел часть своей инфраструктуры на компоненты написанные на Rust. Чуть позже программисты из Dropbox ответили на вопросы интересующихся посвященные этой миграции. Немного интересных ответов:
> Are you happy using rust ?
Yes, overall the team has been very pleased with it. Compile times are the only serious complaint.
> How many lines of rust code are you using in production?
About 60k of our own, about 300k incl crates.
> Are you using nightly? or just stable version of rust?
We’re pinned to a particular nightly right now, as we rely on a fair amount of features that are still stabilizing. I imagine we’ll be on a stable by this summer.
> What drove the move to Rust precisely? Most of the players in the industry are somewhat reluctant about moving to Rust.
Well, we basically needed C++, but:
1) Dropbox doesn’t have a strong C++ ecosystem on the backend, and it takes a lot of work to build one.
2) Given (1), we had basically a blank slate, and our team is C++ and Haskell type folks, we decided to use Rust so we could get C++ with better type safety and fewer sharp corners.
So realistically, if we had been at a place with an awesome preexisting set of C++ libraries, practices, etc, we probably never would have used Rust.
Что наиболее показательно, так этот тот факт, что C++ перестал быть выбором по умолчанию для таких ситуаций, хотя еще несколько лет назад он был бы просто безальтернативным решением. С одной стороны немного грустно, мой основной рабочий инструмент продолжает уходить даже из тех областей, где он всегда был невероятно силен, с другой стороны, уход C++ из продуктовой разработки должен положительно сказаться на качестве и легкости поддержки сложных решений.
Релиз Rust 1.0. Возможности и сомнения
Разработчики Rust прошли долгий путь и 15 мая ожидается выпуск первой версии языка с вечеринкой по случаю новорожденного. Лично я долго ждал этого события, хотя и вызывает оно довольно смешанные чувства. Вроде что-то и родилось, но хочу ли я это что-то использовать и стоит ли оно того? Вот в чем вопрос. Дело в том, что в процессе развития Rust претерпел довольно сильные изменения и теперь это далеко не тот же язык, о котором я писал в 2013.
Continue reading
Приближение выхода Rust 1.0
Судя по записи в официальном блоге Rust, ожидать выхода Rust 1.0 осталось всего ничего:
We plan to ship the 1.0 beta around the end of the year.
Что на мой взгляд просто отличная новость! А дальше еще интереснее:
After 1.0 is released, future 1.x releases will be backwards compatible
Что недвусмысленно намекает на то, что разработчики языка Rust куда более вменяемые по сравнению с разработчиками D. Как следствие, возлагаемые на язык надежды в плане использования в промышленной среде становятся все более и более оправданными.
А вот заключительное утверждение:
In many ways, Rust 1.0 is not so much an endpoint as it is a starting point.
Напоминает мне шутку о том, что C++ разработчики скоро разделятся на две группы: те кто успел выучить язык до выхода C++17 и те кто уже не выучит %)
Rust 0.10
Сегодня вышел, на мой взгляд, интереснейший релиз Rust 0.10. Ломающих изменений в нем не очень много, зато был проведен просто грандиозный рефакторинг: две основные библиотеки libstd и libextra были разделены на полтора десятка библиотек “одной функции” в процессе чего libextra перестала существовать. Это хорошо в первую очередь тем, что появилась реальная возможность начать использовать Rust практически в пределах libstd (все же необходимо еще немного порезать libstd для отключения работы с задачами), а не только самого компилятора, на низком уровне, к примеру в драйверах. Сейчас как раз занимаюсь подобным экспериментом, выглядит ну очень заманчиво!
Ну, все изучать Rust!