Как я понял, там какую-то мета-информацию rustup'а исправить нужно. В деталях сильно не копался, потому что способ выше занял десять секунд и все исправил.
Меня тоже, если честно, немного тревожит этот аспект NLL — что оно более хитрое теперь все. Но 1) не так и просто придумать более-менее реалистичный пример, когда реально из-за этого сильно наступить на грабли 2) очень много людей просто отказывались пользоваться языком с до-NLL проверками, считая язык просто недоработанным (даже на хабре к прошлым статьям десятки таких коментов были).
Всех поздравляю с самым важым после 1.0 выпуском Rust. Уже успел перетащить свою поделку на новую редакцию, это было не больно, так что всем советую. :)
Предвидя два популярных вопроса:
1) rustup немного косячит с компонентами при обноввлении до новой версии. Есл иу вас раньше столи rustfmt-preview и clippy-preview компоненты, то теперь новые clippy и rustfmt компоненты нельзя будет поставить без переустановки тулчейна (URLO тема):
На всякий оговорюсь, что не прям сильно в теме и для ржавой встройки я скорее просто сочувствующий, чем реально имеющий опыт.
… всё это оставляет ощущение глубокой альфы, на которую ещё несколько лет можно даже не смотреть.
С этим особо и спорить не стану — ржавая встройка в текущий момент это и правда еще удел энтузиастов и экспериментаторов, которые пытаются развить экосистему и довести до ума инструментарий. До серьезного "взял и в продакшн" тут еще море работы.
И как, повысили? И про это можно прочитать где-то в объёме большем, нежели «наши доблестные разработчики всё исправили»?
Можно, но за подробностями это с уровня таких больших "корпоративных релизов" надо спускаться на уровень конкретных Embedded WG ежемесячников (например, вот) или даже конкретных задач на гитхабе (например вот или вот).
"Для встроенной разработки необходимо было повысить стабильность существующей функциональности."
Обожаю такие фразы. Звучит весомо, не значит ничего.
Почему ничего? Есть всякие нестабильные флаги и возможности компилятора, очень полезные для разработки под встройку, но еще не доступные в стабильном канале. Где-то в Embedded WG ресурсах список был — потихоньку дело толкают к стабилизации всего этого хозяйства.
Для встраиваемой разработки необходимо было сделать так, чтобы без плясок с многочисленными бубнами бинарник занимал какое-то разумное место, сравнимое с написанным на C.
Так разница ж принципиальная, аналогично как между написанием кода на ЯП со статической типизацией и на языке с динамической типизацией, но где мы при вызове функций в рантайме спрашиваем тип аргументов, возвращая ошибку, если нам вместо строки число передали.
Но тут даже скорее вопрос в просто другом фокусе. В "альфа версии" этих ежемесячников написано, какую примерно ЦА я себе представляю:
Я тут подумал, что на хабре довольно много сочувствующих ржавчине, но не прям сильно следящих за происходящим в экосистеме (не подписанных на TWIR?).
Т.е. я это все пишу или для тех крабообразных, которые слишком заняты полезной работой, что бы пристально следить за новостями, или для тех кто растом вообще не сильно пользуется, но подумывает/сочувствующий. Ни тем, ни другим от вышеописанного новороченного информационного портала пользы все равно почти никакой не будет.
Ну и в целом, даже если и вопрос ЦА вынести за скобки, я сильно не уверен в жизнеспособности такого портала даже для основного раст сообщества, потому что практические потребности всех активных членов карго-культа покрываются или хорошо структурированным TWIR еженедельниками, или всезнающим /r/rust, оба которых уже всем знакомы и привычны.
Спокойно, просто вместо let a = 5; надо написать let mut a = 5; и она станет изменяемой.
Про идентификаторы — я подозреваю что в серьезных международных проектах просто будет включено предупреждение об использовании не-ascii идентификаторов (#![forbid(non_ascii_idents)]) и все.
В Ржавчине от функциональщины в целом только мощные конвейеры итераторов да неизменяемость переменных по умолчанию. Функции первого порядка есть, но из-за особенностей работы с памятью на практике с их помощью делать хитрые функциональные финты не очень-то просто.
Обычно говорят что раст императивный, но с вывертом: чистые функциональные языки стараются не допускать общего изменяемого состояния (shared mutable state), запрещая изменения, а Ржавчина запрещает именно одновременность общего и изменяемого состояния. Т.е. в один момент времени состояние может быть или общим (много & указателей на переменную, например), или изменяемым, но с уникальным доступом (&mut указатель требует эксклюзивности доступа). Т.е. цель сходная с чистой функциональщиной, но путь к ней другой из-за необходимости быть более низкоуровневым.
https://doc.rust-lang.org/std/option/enum.Option.html#method.as_ref
Как я понял, там какую-то мета-информацию rustup'а исправить нужно. В деталях сильно не копался, потому что способ выше занял десять секунд и все исправил.
Классический https://ru.wikipedia.org/wiki/Ни_один_истинный_шотландец в чистом виде.
Есть ссылка откуда такие числа, особенно в контексте Rust'а?
Меня тоже, если честно, немного тревожит этот аспект NLL — что оно более хитрое теперь все. Но 1) не так и просто придумать более-менее реалистичный пример, когда реально из-за этого сильно наступить на грабли 2) очень много людей просто отказывались пользоваться языком с до-NLL проверками, считая язык просто недоработанным (даже на хабре к прошлым статьям десятки таких коментов были).
Да, с
edition = "2018"вCargo.tomlNLL включается.Всех поздравляю с самым важым после 1.0 выпуском Rust. Уже успел перетащить свою поделку на новую редакцию, это было не больно, так что всем советую. :)
Предвидя два популярных вопроса:
1) rustup немного косячит с компонентами при обноввлении до новой версии. Есл иу вас раньше столи
rustfmt-previewиclippy-previewкомпоненты, то теперь новыеclippyиrustfmtкомпоненты нельзя будет поставить без переустановки тулчейна (URLO тема):2) Новый дизайн https://www.rust-lang.org очень спорное явление, сразу могу сказать что вот текущая активная тема для его обсуждения, а старый сайт можно найти тут: https://prev.rust-lang.org
Это писал не член команды раста. Мозилла большая, в ней много людей с разными мнениями и умением дипломатично формулировать мысли.
На всякий оговорюсь, что не прям сильно в теме и для ржавой встройки я скорее просто сочувствующий, чем реально имеющий опыт.
С этим особо и спорить не стану — ржавая встройка в текущий момент это и правда еще удел энтузиастов и экспериментаторов, которые пытаются развить экосистему и довести до ума инструментарий. До серьезного "взял и в продакшн" тут еще море работы.
Можно, но за подробностями это с уровня таких больших "корпоративных релизов" надо спускаться на уровень конкретных Embedded WG ежемесячников (например, вот) или даже конкретных задач на гитхабе (например вот или вот).
Почему ничего? Есть всякие нестабильные флаги и возможности компилятора, очень полезные для разработки под встройку, но еще не доступные в стабильном канале. Где-то в Embedded WG ресурсах список был — потихоньку дело толкают к стабилизации всего этого хозяйства.
А no_std бинари много места занимают? Вроде не должны бы.
Так разница ж принципиальная, аналогично как между написанием кода на ЯП со статической типизацией и на языке с динамической типизацией, но где мы при вызове функций в рантайме спрашиваем тип аргументов, возвращая ошибку, если нам вместо строки число передали.
+1, это совсем другой уровень временных затрат.
Но тут даже скорее вопрос в просто другом фокусе. В "альфа версии" этих ежемесячников написано, какую примерно ЦА я себе представляю:
Т.е. я это все пишу или для тех крабообразных, которые слишком заняты полезной работой, что бы пристально следить за новостями, или для тех кто растом вообще не сильно пользуется, но подумывает/сочувствующий. Ни тем, ни другим от вышеописанного новороченного информационного портала пользы все равно почти никакой не будет.
Ну и в целом, даже если и вопрос ЦА вынести за скобки, я сильно не уверен в жизнеспособности такого портала даже для основного раст сообщества, потому что практические потребности всех активных членов карго-культа покрываются или хорошо структурированным TWIR еженедельниками, или всезнающим /r/rust, оба которых уже всем знакомы и привычны.
Шпаргалка и правда больше информации содержит, но не так что бы на порядок же.
Это звучит как Appendix A: Keywords, но есть же еще и Appendix B: Operators and Symbols, в котором как раз весь основной синтаксис разобран.
Кстати, в книгах всегда была глава с синтаксическим индексом — https://doc.rust-lang.org/book/syntax-index.html — но про нее почти никто не знал (и не знает, видимо).
Ни телеграмовское, ни rustycrate.ru/gitter сообщества не официальные.
Пример показывает, что тесты писать просто — нашлепнул на функцию
#[test]и готово, остальное встроено в стандартный cargo.Спокойно, просто вместо
let a = 5;надо написатьlet mut a = 5;и она станет изменяемой.Про идентификаторы — я подозреваю что в серьезных международных проектах просто будет включено предупреждение об использовании не-ascii идентификаторов (
#![forbid(non_ascii_idents)]) и все.Скоро можно будет. RFC о юникодных идентификаторах приняли не так давно, срачей вокруг него куча была.
В Ржавчине от функциональщины в целом только мощные конвейеры итераторов да неизменяемость переменных по умолчанию. Функции первого порядка есть, но из-за особенностей работы с памятью на практике с их помощью делать хитрые функциональные финты не очень-то просто.
Обычно говорят что раст императивный, но с вывертом: чистые функциональные языки стараются не допускать общего изменяемого состояния (shared mutable state), запрещая изменения, а Ржавчина запрещает именно одновременность общего и изменяемого состояния. Т.е. в один момент времени состояние может быть или общим (много
&указателей на переменную, например), или изменяемым, но с уникальным доступом (&mutуказатель требует эксклюзивности доступа). Т.е. цель сходная с чистой функциональщиной, но путь к ней другой из-за необходимости быть более низкоуровневым.P.S. недавняя статья на тему
https://habr.com/tag/exonum :)