Open source
Rust
Компиляторы
Программирование
Системное программирование
Комментарии 34
+2
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, тогда и в новости про них расписано будет.

+1

#[proc_macro_derive] давно стабилен и использует proc macro API, прямо или через инфраструктурные крейты типа syn/proc-macro2.
До 1.29 всё делалось через строки, а 1.29 стабилизировал полноценное API для токенов, на которое все инфраструктурные крейты, например, сразу же перешли, это большое дело на самом деле.
Обычно все добавления в библиотеку анонсируются, даже крошечные, а в этом случае начались какое-то маневры ¯_(ツ)_/¯

0

Как я это вижу:


Это важное изменение, но пока только для авторов хардкорных библиотек. А они и так в курсе этих изменений, потому что точно следят за разработкой языка хотя бы на уровне чтения TWIRов.


Посты же в официальном журнале Ржавчины, как я понимаю, ориентированы на максимально широкую аудиторию, включая тех кто вообще не сильно в язык погружен. Такой ЦА прямой пользы от вышеописанной стабилизации пока нет, а вот запутаться в объяснениях "это стабилизировано, но вот только такое, а тут надо через это, а вот это пока нельзя и вот тут три нюанса" — раз плюнуть.

+3
Rust 1.30 и 1.31 будут очень значительными

Точного списка пока нет, но насколько я понял, ожидается что:





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

+2
Когда уже rust приедет на микроконтроллеры? Пока все что я нашел — это упоминание что раст можно компилировать под контроллеры и блог одного товарища, который с костылями и доработками это вроде как сделал… Может я не туда смотрю?
0
ИМХО, чтобы rust приехал на МК — под него должны быть адаптированы популярные библиотеки. Пока не будут FreeRTOS и lwip заводиться без костылей — лично я и не подумаю переходить. Ибо толку, если я перейду, а все остальные разработчики на работе — нет?
+2
Ибо толку, если я перейду, а все остальные разработчики на работе — нет?

Эта проблема от платформы и библиотек не сильно зависит.
"Остальные разработчики" в принципе редко хотять переходить на что-то другое если то что есть и так работает.

0
«Остальные разработчики» в принципе редко хотять переходить на что-то другое если то что есть и так работает.

Тут согласен, но дело в том, что прямо сейчас пересаживаться на Rust я тоже не вижу смысла, к своему сожалению.
Начать пересаживаться на Rust сейчас — значит вывести разработчиков из рабочего процесса на… неопределённое время, учить язык и переписывать кодовую базу.
Можно новые проекты начать потихоньку пилить на Rust, но… надо учить язык, а он окончательно ещё не устоялся.
В итоге — для хобби, где время жизни проекта редко превышает год — сойдёт.
Для кровавого энтерпрайза — извините, но пока что нет, как бы язык ни был хорош :(
0
переписывать кодовую базу

Не уверен, может это и имелось в виду, но обычно советуют c уже написанными проектами переходить по схеме "в целом проект остается на чем он и был написан, но новую функциональность мы реализуем на Rust, переписывая только самый минимум нужных для этого модулей". И постепенно-инкрементально проект и разработчики перебираются на ржавую сторону.


По этой теме недавно доклад от разработчиков Tor'а был на растконфе:


https://www.youtube.com/watch?v=WI4ApeHH9QE


Это все раво не так просто как с самого начала проект на расте начать, конечно, но уже намного более реальный путь чем "просто берем и RIIR!!! переписываем разом весь код ржавчину", о котором многие думают в первую очередь.


надо учить язык, а он окончательно ещё не устоялся

Этот момент немного смутил. Если речь о том что какой-то конкретной вещи в языке еще не хатает (async/await того же) — может и имеет смысл подождать ее выпуска и стабилизации.


Но в целом, 1.0 с гарантиями обратной совместимости давно уже вышел и однажды написанный корректный код так и продолжит работать, а какие-то доработки в язык так и будут вноситься до самой его смерти скорее всего.

+1
>Для кровавого энтерпрайза — извините, но пока что нет, как бы язык ни был хорош :(

Мы, кстати, энтерпрайз кровавее некуда (healthcare) на Rust делаем (Commure). С чистого листа.
+2

Из телеграма подсказывают:


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'а :)

0
Да, именно про этого шведа(кажется) я и говорил. По английски понимаю плохо, но из того что я понял, дабы запустить все это дело, надо очень сложный танец с бубном исполнить.
Спасибо за ссылки, обязательно поковыряю )
+1

Там за последний год огромный прогресс. Хотя пока полноценно на stable собирать бинарники под embedded пока нельзя, это ожидается в районе 1.31 (т. е. через полтора месяца). В целом, библиотеки под no_std (т. е. для bare metal) уже некоторое время вполне пишутся на stable rust.


Я делал небольшой доклад про текущее состояние в этой области на примере arm с демонстрацией того, что это работает на stm32f4discovery (там f407) с простым blinky и semihosting io. Но большой фрагмент, связанный с embedded-hal и разными bsp не затрагивал.

0
Поясните, как можно писать на no_std на стейбле? А то лично у меня совсем не получается, т.к. для его работы нужно определять различные lang_item'ы вроде oom, а это nightly-only фича.
0

Пока на stable можно писать no_std библиотеки, но не готовые приложения. Из ограничений, про которые я помню:


  • #[panic_handler] пока только в beta (1.30);
  • аллокаторы пока заехали только частично;
  • #[used] для указания, что результирующий символ не надо выкидывать как unused (обходится через EXTERN+KEEP в линкер-скрипте), тоже в beta.

Т. е. если вы не библиотеку аллокации или обработки паники, то жить можно. При использовании аллокации на стеке/в глобальных переменных уже можно собирать бинарники на beta. Надеюсь, что alloc и heap стабилизируют скоро. Для многих в embedded bare metal мире использование динамической памяти не сильно актуально, так что жизнь-жизнь уже вполне приближается.

0
Ну, на практике так не очень получается.

Вот беру первую попавшуюся либу, пытаюсь собрать на стейбле, получаю

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`.


И так в реальных проектах происходит очень и очень часто
0

Ну, nightly-only библиотеки это отдельный вопрос. Некоторые прячут nightly-only под фичами в Cargo.toml, но далеко не все. И часть библиотек, базирующиеся на edge-фичах, будут сидеть на nightly.


Отдельный вопрос, зачем wasm-библиотеку собирать под нативный таргет?


Второе, пожалуй, то что я говорил в первую очередь про embedded мир (*-*-none target'ы). И ветка была про embedded/bare-metal (как минимум, упоминался Jorge Aparicio, что кагбэ намекаэ).

0
Отдельный вопрос, зачем wasm-библиотеку собирать под нативный таргет?

Там таргет выставлен wasm32-unknown-unknown, я указатл только компилятор.


Ну, nightly-only библиотеки это отдельный вопрос. Некоторые прячут nightly-only под фичами в Cargo.toml, но далеко не все. И часть библиотек, базирующиеся на edge-фичах, будут сидеть на nightly.

Почти все либы, что я видел, сидят на найтли, как и приложения. Исключения крайне редки, всякие суперстабильные вещи вроде serde, и всё.


Второе, пожалуй, то что я говорил в первую очередь про embedded мир (--none target'ы). И ветка была про embedded/bare-metal (как минимум, упоминался Jorge Aparicio, что кагбэ намекаэ).

И что для них меняется? Библиотеки-то все одни и те же. Да, я использовал не none, но и там гарантирую куда не ткни — на стейбле не собрать.

0
И что для них меняется? Библиотеки-то все одни и те же.

Какие "одни и те же"? Всякие cortex-m-rt, embedded-hal и подобные? Библиотеки, опирающиеся на std просто идут лесом на bare metal target'ах.


Почти все либы, что я видел, сидят на найтли, как и приложения. Исключения крайне редки, всякие суперстабильные вещи вроде serde, и всё.

Скорее всего, особенности вашей области применения. Стабилизируется со временем.

0

Боюсь, весьма не скоро. Давеча общался с товарищем, который пилит прошивки для медтехники. Компилятор С самопальный от вендора, местами я так понимаю даже не ANSI. IDE — какая-то сборка на базе эклипса.

+1

Эта проблема есть и у тех кто хочет что-то выше корявого неполного C89 от вендора. Но rust целится на широкую аудиторию: ARM (в первую очередь Cortex-M, но не забывая про Cortex-R и Cortex-A), MSP430, RISCV, AVR (в меньшей степени, пока даже не в основной ветке).

+1
Я год назад делал маленький проект, было плюс-минус без костылей (хотя, наверное, xargo можно за костыль посчитать). Всё компилировалось, прошивалось, отлаживалось, под STM32. По-моему, даже прямо из CLion-а у меня получалось отлаживать, но это не точно. gdb точно работал (или lldb? один из них :) ).

Но там всё постоянно меняется — это один из рисков. С тех пор они там какие-то HAL-ы напилили — про это ничего не знаю.

Моя оценка примерно такая:
1) Для хобби — сойдёт (проекты относительно маленькие), если есть желание. Мне понравился мой опыт, причём это был мой первый проект на Rust.
2) Для новых крупных проектов — если есть желание рискнуть, можно сделать ставку на Rust. Я слышал разные страшные истории от одного разработчика в одной всем известной компании про то, как у них низкоуровневый софт пишется (Raspberry PI, хотя это уже не совсем «микроконтроллер») — Rust бы там, как мне кажется, пришёлся бы в тему.
3) Для средних проектов — не знаю, там, наверное, проще взять готовые библиотеки. Хотя с другой стороны, Rust хорошо встраивается в C, наверное, можно кусочно на Rust делать (но FFI — это вдвойне опасная тема).
0

Благо, для arm xargo уже не нужен, необходимые куски ставятся через rustup target add уже несколько месяцев. CLion у меня с отладкой через swd+openocd+gdb нормально работал. Вообще, сейчас рабочие и gdb, и lldb, хотя первый появился чуток раньше.


Про "всё постоянно меняется — это один из рисков" сложно не согласиться. Именно поэтому одна из целей этого года стабилизировать no_std разработку, чтобы она была на stable и не требовала жить на фиксированной версии компилятора, как иногда бывало раньше.


Ну и про встраивание через ffi: учитывая что rust позволяет использовать обычный человеческий C ABI, проблемы нет. Оно не сильно отличается от написание библиотек на си или плюсах с теми же развлечениями типа ручного контроля времени жизни объектов. Кто писал библиотеки с управлением какими-либо внешними ресурсами (будь-то файл, внутренний контекст, соединения etc) на этом поле граблей уже танцевал.

+1

Ага, поэтому с ним сейчас много и возятся:


https://rust-lang-nursery.github.io/edition-guide/editions/transitioning-your-code-to-a-new-edition.html


Я летом игрался немного с rust2018 — уже тогда процесс первичного перехода с rustfix более-менее работал (там в первую очередь пути надо было поправить). Вот если включить #![warn(rust_2018_idioms)], то rustfix огда не помогал. правят сейчас .

0
Возможно плохо искал, но не увидел: планируется возможность увидеть список исправлений без накатывания cargo fix сразу на весь проект? Каким бы умным анализатор ни был, всегда есть место для сомнений.
0

Судя по наличию флагов


        --allow-no-vcs              Fix code even if a VCS was not detected                 
        --allow-dirty               Fix code even if the working directory is dirty  

предполагается что у тебя код живет под гитом и ты его легко откатить можешь, если что-то не устроило.

0
Наличие гита означает хорошие шансы не потерять проект, но про «сделать его лучше» речи не идет.
0

Почему не идет? Я теперь не уверен что понял изначальный вопрос.


Вроде как мы запускаем rustfix, смотрим через git diff что он сделал — если не нравится, то откатываем или частично, или целиком до последнего комита репозитория.

Только полноправные пользователи могут оставлять комментарии. , пожалуйста.