Comments 34
И procedural macro API стабилизировали.
steveklabnik1: 1.29 stabilizes parts of the proc_macro crate, but you can’t actually bring proc macros into scope without use, which was what I was referring to and lands in 1.30. As such we’re not really advertising the 1.29 stabilization broadly; it can be used by some crates, like serde, for better error messages, but that’s about it, making it minor enough for to not talk much about.
Т.е. в текущей итерации стабилизации процедурные макросы еще почти бесполезны. Ждем стабилизации остальной нужной для их использования обвязки в 1.30, тогда и в новости про них расписано будет.
#[proc_macro_derive] давно стабилен и использует proc macro API, прямо или через инфраструктурные крейты типа syn/proc-macro2.
До 1.29 всё делалось через строки, а 1.29 стабилизировал полноценное API для токенов, на которое все инфраструктурные крейты, например, сразу же перешли, это большое дело на самом деле.
Обычно все добавления в библиотеку анонсируются, даже крошечные, а в этом случае начались какое-то маневры ¯_(ツ)_/¯
Как я это вижу:
Это важное изменение, но пока только для авторов хардкорных библиотек. А они и так в курсе этих изменений, потому что точно следят за разработкой языка хотя бы на уровне чтения TWIRов.
Посты же в официальном журнале Ржавчины, как я понимаю, ориентированы на максимально широкую аудиторию, включая тех кто вообще не сильно в язык погружен. Такой ЦА прямой пользы от вышеописанной стабилизации пока нет, а вот запутаться в объяснениях "это стабилизировано, но вот только такое, а тут надо через это, а вот это пока нельзя и вот тут три нюанса" — раз плюнуть.
Rust 1.30 и 1.31 будут очень значительными
Точного списка пока нет, но насколько я понял, ожидается что:
- в 1.30 войдет частичная стабилизация процедурных макросов;
- в 1.31 войдут Rust 2018 + non-lexical lifetimes (NLL).
Вроде бы, мой комментарий с обзорной подборкой ссылок к прошлой новости зашел хорошо, так что к концу сентября я попробую в примерно том же формате написать пост с новостями за месяц и, может, начну делать это регулярно.
Ибо толку, если я перейду, а все остальные разработчики на работе — нет?
Эта проблема от платформы и библиотек не сильно зависит.
"Остальные разработчики" в принципе редко хотять переходить на что-то другое если то что есть и так работает.
«Остальные разработчики» в принципе редко хотять переходить на что-то другое если то что есть и так работает.
Тут согласен, но дело в том, что прямо сейчас пересаживаться на Rust я тоже не вижу смысла, к своему сожалению.
Начать пересаживаться на Rust сейчас — значит вывести разработчиков из рабочего процесса на… неопределённое время, учить язык и переписывать кодовую базу.
Можно новые проекты начать потихоньку пилить на Rust, но… надо учить язык, а он окончательно ещё не устоялся.
В итоге — для хобби, где время жизни проекта редко превышает год — сойдёт.
Для кровавого энтерпрайза — извините, но пока что нет, как бы язык ни был хорош :(
переписывать кодовую базу
Не уверен, может это и имелось в виду, но обычно советуют c уже написанными проектами переходить по схеме "в целом проект остается на чем он и был написан, но новую функциональность мы реализуем на Rust, переписывая только самый минимум нужных для этого модулей". И постепенно-инкрементально проект и разработчики перебираются на ржавую сторону.
По этой теме недавно доклад от разработчиков Tor'а был на растконфе:
https://www.youtube.com/watch?v=WI4ApeHH9QE
Это все раво не так просто как с самого начала проект на расте начать, конечно, но уже намного более реальный путь чем "просто берем и RIIR!!! переписываем разом весь код ржавчину", о котором многие думают в первую очередь.
надо учить язык, а он окончательно ещё не устоялся
Этот момент немного смутил. Если речь о том что какой-то конкретной вещи в языке еще не хатает (async/await того же) — может и имеет смысл подождать ее выпуска и стабилизации.
Но в целом, 1.0 с гарантиями обратной совместимости давно уже вышел и однажды написанный корректный код так и продолжит работать, а какие-то доработки в язык так и будут вноситься до самой его смерти скорее всего.
Мы, кстати, энтерпрайз кровавее некуда (healthcare) на Rust делаем (Commure). С чистого листа.
rust-embedded/wg + rust-embedded/awesome-embedded-rust — тут вот довольно много ссылок есть как на библиотеки/инстурменты, так и на связанные ресурсы.
Не так давно своими глазами видел живое демо на питерской сходке, процесс выглядел не сильно костыльно.
Из телеграма подсказывают:
http://embedonomicon.rust-embedded.org/preface.html — небольшая дока чисто для понимания no_std и линковки.
стоит почитать блог Japaric: https://blog.japaric.io/
ну и как обычно, жапариковские крейты bare-metal, cortex-m, cortex-m-rt, stm32f103xx и так далее, там много полезного для себя можно откопать.
https://github.com/m-labs/smoltcp — ip стек, но это для хардкорных парней уже
"… блог одного товарища..." — Скорее всего это и есть журнал Japaric'а :)
Спасибо за ссылки, обязательно поковыряю )
Там за последний год огромный прогресс. Хотя пока полноценно на stable собирать бинарники под embedded пока нельзя, это ожидается в районе 1.31 (т. е. через полтора месяца). В целом, библиотеки под no_std (т. е. для bare metal) уже некоторое время вполне пишутся на stable rust.
Я делал небольшой доклад про текущее состояние в этой области на примере arm с демонстрацией того, что это работает на stm32f4discovery (там f407) с простым blinky и semihosting io. Но большой фрагмент, связанный с embedded-hal и разными bsp не затрагивал.
Пока на stable можно писать no_std библиотеки, но не готовые приложения. Из ограничений, про которые я помню:
#[panic_handler]пока только в beta (1.30);- аллокаторы пока заехали только частично;
#[used]для указания, что результирующий символ не надо выкидывать как unused (обходится черезEXTERN+KEEPв линкер-скрипте), тоже в beta.
Т. е. если вы не библиотеку аллокации или обработки паники, то жить можно. При использовании аллокации на стеке/в глобальных переменных уже можно собирать бинарники на beta. Надеюсь, что alloc и heap стабилизируют скоро. Для многих в embedded bare metal мире использование динамической памяти не сильно актуально, так что жизнь-жизнь уже вполне приближается.
Вот беру первую попавшуюся либу, пытаюсь собрать на стейбле, получаю
cargo +stable-x86_64-pc-windows-gnu build
Compiling crunchy v0.1.6
Compiling byteorder v1.2.3
Compiling rustc-hex v1.0.0
Compiling bigint v4.4.0
Compiling parity-hash v1.2.0
Compiling pwasm-abi v0.1.4 (file:///C:/Users/Alex/Documents/Repo/pwasm-abi)
error[E0554]: #![feature] may not be used on the stable release channel
--> src\lib.rs:4:33
|
4 | #![cfg_attr(not(feature="std"), feature(alloc))]
| ^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0554`.
error: Could not compile `pwasm-abi`.И так в реальных проектах происходит очень и очень часто
Ну, nightly-only библиотеки это отдельный вопрос. Некоторые прячут nightly-only под фичами в Cargo.toml, но далеко не все. И часть библиотек, базирующиеся на edge-фичах, будут сидеть на nightly.
Отдельный вопрос, зачем wasm-библиотеку собирать под нативный таргет?
Второе, пожалуй, то что я говорил в первую очередь про embedded мир (*-*-none target'ы). И ветка была про embedded/bare-metal (как минимум, упоминался Jorge Aparicio, что кагбэ намекаэ).
Отдельный вопрос, зачем wasm-библиотеку собирать под нативный таргет?
Там таргет выставлен wasm32-unknown-unknown, я указатл только компилятор.
Ну, nightly-only библиотеки это отдельный вопрос. Некоторые прячут nightly-only под фичами в Cargo.toml, но далеко не все. И часть библиотек, базирующиеся на edge-фичах, будут сидеть на nightly.
Почти все либы, что я видел, сидят на найтли, как и приложения. Исключения крайне редки, всякие суперстабильные вещи вроде serde, и всё.
Второе, пожалуй, то что я говорил в первую очередь про embedded мир (--none target'ы). И ветка была про embedded/bare-metal (как минимум, упоминался Jorge Aparicio, что кагбэ намекаэ).
И что для них меняется? Библиотеки-то все одни и те же. Да, я использовал не none, но и там гарантирую куда не ткни — на стейбле не собрать.
И что для них меняется? Библиотеки-то все одни и те же.
Какие "одни и те же"? Всякие cortex-m-rt, embedded-hal и подобные? Библиотеки, опирающиеся на std просто идут лесом на bare metal target'ах.
Почти все либы, что я видел, сидят на найтли, как и приложения. Исключения крайне редки, всякие суперстабильные вещи вроде serde, и всё.
Скорее всего, особенности вашей области применения. Стабилизируется со временем.
Боюсь, весьма не скоро. Давеча общался с товарищем, который пилит прошивки для медтехники. Компилятор С самопальный от вендора, местами я так понимаю даже не ANSI. IDE — какая-то сборка на базе эклипса.
Но там всё постоянно меняется — это один из рисков. С тех пор они там какие-то HAL-ы напилили — про это ничего не знаю.
Моя оценка примерно такая:
1) Для хобби — сойдёт (проекты относительно маленькие), если есть желание. Мне понравился мой опыт, причём это был мой первый проект на Rust.
2) Для новых крупных проектов — если есть желание рискнуть, можно сделать ставку на Rust. Я слышал разные страшные истории от одного разработчика в одной всем известной компании про то, как у них низкоуровневый софт пишется (Raspberry PI, хотя это уже не совсем «микроконтроллер») — Rust бы там, как мне кажется, пришёлся бы в тему.
3) Для средних проектов — не знаю, там, наверное, проще взять готовые библиотеки. Хотя с другой стороны, Rust хорошо встраивается в C, наверное, можно кусочно на Rust делать (но FFI — это вдвойне опасная тема).
Благо, для arm xargo уже не нужен, необходимые куски ставятся через rustup target add уже несколько месяцев. CLion у меня с отладкой через swd+openocd+gdb нормально работал. Вообще, сейчас рабочие и gdb, и lldb, хотя первый появился чуток раньше.
Про "всё постоянно меняется — это один из рисков" сложно не согласиться. Именно поэтому одна из целей этого года стабилизировать no_std разработку, чтобы она была на stable и не требовала жить на фиксированной версии компилятора, как иногда бывало раньше.
Ну и про встраивание через ffi: учитывая что rust позволяет использовать обычный человеческий C ABI, проблемы нет. Оно не сильно отличается от написание библиотек на си или плюсах с теми же развлечениями типа ручного контроля времени жизни объектов. Кто писал библиотеки с управлением какими-либо внешними ресурсами (будь-то файл, внутренний контекст, соединения etc) на этом поле граблей уже танцевал.
Ага, поэтому с ним сейчас много и возятся:
Я летом игрался немного с rust2018 — уже тогда процесс первичного перехода с rustfix более-менее работал (там в первую очередь пути надо было поправить). Вот если включить #![warn(rust_2018_idioms)], то rustfix огда не помогал. правят сейчас .
Судя по наличию флагов
--allow-no-vcs Fix code even if a VCS was not detected
--allow-dirty Fix code even if the working directory is dirty предполагается что у тебя код живет под гитом и ты его легко откатить можешь, если что-то не устроило.
Почему не идет? Я теперь не уверен что понял изначальный вопрос.
Вроде как мы запускаем rustfix, смотрим через git diff что он сделал — если не нравится, то откатываем или частично, или целиком до последнего комита репозитория.
Хм, мне не кажется что оно сильно имеет смысл, но вот спросил — https://github.com/rust-lang-nursery/rustfix/issues/146 — можно подписаться.
Выпуск Rust 1.29