Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск Rust 1.96. Оценка пригодности Rust для создания прошивок к микроконтроллерам"	+/–
Сообщение от opennews (??), 29-Май-26, 20:23
Опубликован релиз языка программирования  Rust 1.96, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=65574
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 29-Май-26, 20:23	+2 +/–
>для микроконтроллеров STM32U585AI https://www.st.com/en/microcontrollers-microprocessors/stm32... Интересный эксперимент.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #67

2. Сообщение от Аноним (2), 29-Май-26, 20:33	–3 +/–
Лучше производность, быстрее код писать, меньше оперативной памяти нужно и чуть больше места занимает. Выбор очевиден.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #6, #15, #40, #49, #66

3. Сообщение от НяшМяш (ok), 29-Май-26, 20:33	+4 +/–
Под микроконтроллер в 160 мегагерц можно было хоть на бидоне писать, в чём смысл делать какие-то сравнения под эту лошадь. Сообщество на тот же 16-мегагерцовый nRF51 на embassy фигачит со свистом уже много лет, открыли они Америку.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #7, #89

4. Сообщение от Аноним (4), 29-Май-26, 20:49	+3 +/–
Выбираю SPARK.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #68, #140

5. Сообщение от Аноним (5), 29-Май-26, 20:54	+/–
Во, точняк! Раст -- низкоуровневый питон!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #14

6. Сообщение от Аноним (6), 29-Май-26, 21:00	+/–
Быстрее код писать, воюя с чекером боровов? Ах да, для микроконтроллеров же - сплошной @unsafe.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

7. Сообщение от Аноним (1), 29-Май-26, 21:05	+/–
Ну они для себя же делали опыт, что и описано в посте, значит им нужнее. Да и остальные языки никуда не деваются: https://opennet.ru/64135-github
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

8. Сообщение от Аноним (6), 29-Май-26, 21:05	+8 +/–
Что-то мне кажется, что если для микроконтроллеров писать на Algol68 с POSIX-расширениями (ga68), то тоже производительность будет не сильно отличаться.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20

9. Сообщение от Аноним (9), 29-Май-26, 21:06	+/–
Интересно, во сколько раз при этом будет больше ошибок, чем в uutils?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #95

10. Сообщение от Аноним (15), 29-Май-26, 21:07	+3 +/–
В эмбедном байтодрочестве rust равных нет уже за счёт упаковки структур и нишевой оптимизации. А так-то без экспериментов было понятно что как минимум если писать на нём в C/плюсовом стиле, то и результаты будут примерно такими же. Вот было бы гораздо интереснее сравнить rust с C/плюсовым стилем и идиоматический rust с Option, Result, итераторами, монадическими конструкциями, лямбдами и трейтами, а желательно с ещё более высокоуровневыми штуками типа разбора протоколов через serde или хотя бы nom. Пока мой опыт в портировании сишного кода, правда не для эмбеддовки, но как раз разбор строк и протоколов и прочее битодрочество показывает что получается в 3 раза меньше (исходного) кода и он намного понятнее, и работает это быстрее (и юнит тесты рядом с кодом очень удобная штука), но на размер машинного кода я не смотрел. А давний опыт в эмбеддовке (AVR) показал что на полноценном C++ со всякими `unique_ptr`, `<algorithm>` и повсеместными шаблонами (когда разные реализации таймеров и экранчиков прокидываются как шаблонные аргументы, реализация I2C мокается для тестов и т.д.) получает прошивки компактнее дубового сишного кода, после чего про C в нашеё команде вообще забыли. Вот на rust такое будет ещё проще и там где в плюсах ещё был возможен какой-то оверхед, то гарантированно без него, но хочется чтобы это красиво показали. Потому что кто-то, как даже в новости написано, до сих пор пишет эмбеддовку на C!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #18, #28

12. Сообщение от Аноним (12), 29-Май-26, 21:14	+/–
Ничего интересного в этом нет. Вопрос применения раста в плоскости практического применения вообще не лежит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #16, #29

14. Сообщение от Аноним (14), 29-Май-26, 21:19	–4 +/–
Низкоуровневый питон называется forth. Это низкоуровневый сишарп.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

15. Сообщение от Аноним (15), 29-Май-26, 21:24	+13 +/–
> Быстрее код писать, воюя с чекером боровов? Завязывайте позориться. Если у вас проблемы с БЧ при написании кода, значит вы не понимаете сколько у вас живут объекты и плодите UB, на сях с такой квалификацией вы будете вместо "войны с БЧ" который вас тыкает в проблему ещё до того как вы даже код собрали, сидеть неделями в отладчике. > Ах да, для микроконтроллеров же - сплошной @unsafe Ни на йоту не больше чем в программировании под большие машины - там у вас в unsafe обёрнуты обращения к системным вызовам, а тут к портам. В остальном разницы нет, поверх этого можете писать только safe логику, можете пользоваться штуками использующими unsafe под капотом для эффективности, но эти штуки опциональны и одинаковы на любых платформах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #31

16. Сообщение от Аноним (15), 29-Май-26, 21:25	–2 +/–
Какой интересный тейк. Даже интересно в какой плоскости лежит вопрос применения если не в плоскости применения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #19

18. Сообщение от Сладкая булочка (?), 29-Май-26, 21:32	+5 +/–
> (и юнит тесты рядом с кодом очень удобная штука) В си никто не мешает положить тесты рядом с кодом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #22, #155

19. Сообщение от анонимс (?), 29-Май-26, 21:36	–1 +/–
Идеологическом. Rust компилируется LLVM написанным на C++ бэкэндом rustc так что машинный код совершенно одинаков
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #21

20. Сообщение от Аноним (15), 29-Май-26, 21:44	+/–
Это скорее правда. Под железо без изысков (типа всяких SIMD) компилировать чистую математику (а что ещё в эмбеддовке может быть CPU-bound) компиляторы давно уже научились, и язык тут можно вообще любой взять. Если у него конечно бэкенд gcc/llvm, а не самодельное музейное гoвнo из прошлого века. Сейчас скорее интересно другое, а именно возможность написать взрослый асинхронный код типа ```rust task::spawn(async ||     loop {         button.await;         i2c.send(0x12, b"button pressed").await.unwrap();     } ); ``` и чтобы он скомпилился в те же 276 байт которые я напишу на ассемблере с ручным диспатчем прерываний и конечным автоматом для состояний. Хотя даже тут интерес уже даже не практический, а фановый, поскольку нет давно железа где было бы принципиально скомпилится это в 276 или 27600 байт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #27, #47, #169

21. Сообщение от Аноним (15), 29-Май-26, 21:48	–1 +/–
Машинный код одинаков только если писать на общем подмножестве двух языков, на нахрена это кому-то нужно? На rust можно писать на порядок выразительнее, и ответ на вопрос будет ли полученный код компактнее и быстрее не для всех очевиден, а даже без учёта этого, вопросы компайл-тайм проверок и более качественного тулинга - сугубо практические.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #41

22. Сообщение от Аноним (15), 29-Май-26, 21:53	–3 +/–
Тесты рядом с кодом это, если что так и ни строчкой больше, даже если это первый тест в проекте: ``` fn inc(a: u32) -> u32 {      a + 1 } +#[test] +fn test_inc() { +    assert_eq!(inc(1), 2); +} ```
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #26

23. Сообщение от Аноним (15), 29-Май-26, 21:57	+4 +/–
Жаль про размер исходников ничего не сказано.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25, #64, #90

25. Сообщение от Аноним (25), 29-Май-26, 22:07	+1 +/–
А может и сказано...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #55

26. Сообщение от Аноним (9), 29-Май-26, 22:34	+1 +/–
И что тут такого особенного, чего не было нигде в других языках?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #54

27. Сообщение от Аноним (9), 29-Май-26, 22:38	+3 +/–
> скомпилится это в 276 или 27600 байт Вся суть растерманов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #32

28. Сообщение от Аноним83 (?), 29-Май-26, 22:44	+1 +/–
> писать на нём в C/плюсовом стиле, то и результаты будут примерно такими же. Вот было бы гораздо интереснее сравнить rust с C/плюсовым стилем и идиоматический rust с Option, Result, итераторами, монадическими конструкциями, лямбдами и трейтами, а желательно с ещё более высокоуровневыми штуками типа разбора протоколов через serde или хотя бы nom. Столько буков и ни слова о конечном результате, только какие то бесполезные языковые абстракции. > А давний опыт в эмбеддовке (AVR) показал что на полноценном C++ со всякими `unique_ptr`, `<algorithm>` и повсеместными шаблонами (когда разные реализации таймеров и экранчиков прокидываются как шаблонные аргументы, реализация I2C мокается для тестов и т.д.) получает прошивки компактнее дубового сишного кода, после чего про C в нашеё команде вообще забыли. Потому что видимо на С не пробовали даже делать плагины и абстракции, как оно сделано в том же линухе/бсд в дровах для всего того же самого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #58

29. Сообщение от Аноним (1), 29-Май-26, 23:10	+/–
>практического применения https://github.com/discord
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #116

31. Сообщение от Аноним (31), 29-Май-26, 23:18    Скрыто ботом-модератором	+/–
А зачем на это отвечать? Чувак выучил 2 слова (БЧ и unsafe) и носит их из треда в тред, не включая бошку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

32. Сообщение от Аноним (31), 29-Май-26, 23:20	–1 +/–
А в чем суть? Или пока сам не понял?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #79

33. Сообщение от Аноним (33), 29-Май-26, 23:22	+2 +/–
Нашел! Я нашел! https://github.com/FluxSysLang/Flux
Ответить | Правка | Наверх | Cообщить модератору

35. Сообщение от localhostadmin (ok), 30-Май-26, 00:06	+/–
Сейчас далеко не под все контроллеры можно сишный код собрать. Поэтому я слабо представляю, как в такую нишу ещё и раст запихнуть можно
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37

36. Сообщение от Аноним (37), 30-Май-26, 00:07	+7 +/–
"Тестирование выполненной работы не выявило заметных преимуществ в использовании языка Rust вместо C" Поправил
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #73, #91

37. Сообщение от Аноним (37), 30-Май-26, 00:09	+6 +/–
Если в микроконтроллер залазит Rust, то это уже не микроконтроллер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #46, #109

38. Сообщение от Аноним (37), 30-Май-26, 00:16	+6 +/–
>В пакетном менеджере Cargo устранена уязвимость С каждой новой версией Rust всё усложняется, расширяется, а значит программирование на нём становится менее надёжным. А Cи остаётся таким же простым.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52, #96, #161

39. Сообщение от Аноним (39), 30-Май-26, 00:27	+3 +/–
Авторы исследования забыли указать, что сишники в эмбедовке разбираются в шинах данных, iommu, dma и тд. А эти на расте ни в чем не разбираются. Так что все-таки сишка под МК лучше уже хотя бы поэтому.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #43, #56, #57, #104

40. Сообщение от Аноним (40), 30-Май-26, 00:54	+1 +/–
Ну тогда Паскаль лучше обоих)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

41. Сообщение от Аноним (40), 30-Май-26, 01:00	+1 +/–
> На rust можно писать на порядок выразительнее Тогда вы выбрали не тот язык. На порядок выразительнее писать на языке из 2000ых (а автор раста начал разрабатывать его в начале 2000ых) с синтаксисом из языков 80ых (для сравнение python это начало 90ых) вряд ли получится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #53

43. Сообщение от Я (??), 30-Май-26, 01:06	+4 +/–
Плюс на Си куча отлаженного и переносимого кода под любую платформу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #78

44. Сообщение от Аноним (44), 30-Май-26, 01:08	+3 +/–
У меня совершенно другой вопрос соберется ли этот же код на расте спустя года 3... У раста до сих пор нет стейбл версии и на обратную совместимость они тоже положили, так что такое.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #50, #77, #92, #170, #184

45. Сообщение от Аноним (44), 30-Май-26, 01:10	+3 +/–
Одного не пойму, зачем изобретать новый яп, привинтите к си все те же безопасные указатели да проверки....
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #48, #75

46. Сообщение от Аноним (59), 30-Май-26, 01:50	+/–
Машкод на Rust весит примерно столько же сколько аналогичный код на C. Можно было бы и под AVR'ки писать, но вроде поддержки в llvm нет. Но в любом случае AVR'ки уже отмерли, микроконтроллеры сейчас поголовно такие что туда и микропитон влезет, но rust и приятнее, и эффективнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

47. Сообщение от anonymous (??), 30-Май-26, 01:52	–2 +/–
Особенно будет весело, когда ваш раст захочет сделать прерывание (для await) в контексте с заблокированными перываниями...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #59

48. Сообщение от Аноним (59), 30-Май-26, 01:53	+1 +/–
Чтобы это понять, надо программировать, а если вы не программируете, вам зачем это понимание? > привинтите к си все те же безопасные указатели да проверки Да, ещё лайфтаймы, БЧ, нормальную систему типов, экосистему, тулинг. Собственно Rust и получится. Ну или zig, если вам он ближе, правда в нём ничего этого нет и он экспериментальная поделка. В любом случае, без нового языка программирования не обойтись.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #85

49. Сообщение от Аноним (49), 30-Май-26, 01:54	+2 +/–
> Лучше производность Предпочитаю интегральность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

50. Сообщение от Аноним (59), 30-Май-26, 01:56	+1 +/–
Пару месяцев назад я столкнулся с кодом написанным во времена rust 1.0x, он вполне себе собирается. Собственно со стабильностью там всё в порядке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #65

52. Сообщение от Аноним (1), 30-Май-26, 01:58	–2 +/–
>С каждой новой версией Rust всё усложняется, расширяется https://www.youtube.com/@RustVideos/videos https://rust-lang.org/ru/learn/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #142

53. Сообщение от Аноним (59), 30-Май-26, 02:07	+/–
А при чём тут синтаксис? Он сейчас вообще во всех языках, и новых, и старых, одинаковый, кроме питона. А выразительность в основном из стандартной библиотеки идёт, например чтобы вместо ```c bool found = false; for (size_t i = 0; i < sizeof(haystack); i++) {     if (strcmp(haystack[i].field, needle) == 0) {         found = true;         break;     } } if (found) {} ``` писать ```rust if haystack.iter().any(|elt| elt.field == needle) {} `` ну и интересно посмотреть на "современные" языки значимо выразительнее rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #99, #128

54. Сообщение от Аноним (59), 30-Май-26, 02:07	–1 +/–
Здесь вообще ничего особенного, но сделай это на C/C++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #72

55. Сообщение от Аноним (59), 30-Май-26, 02:08	–1 +/–
Я читал пейпер, нет - не сказано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

56. Сообщение от Аноним (59), 30-Май-26, 02:10	–1 +/–
> Авторы исследования забыли указать Как раз не забыли, там сказано что была команда C имела большой опыт в C, а команда Rust опыта в Rust имела сильно меньше, и, тем не менее, справилась на отлично. > сишники в эмбедовке разбираются в шинах данных, iommu, dma Нет, не сишники, а эмбеддовщики. Знания о том как работает железо от языка не зависят и применяются одинаково в любом языке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #126, #156

57. Сообщение от Аноним (107), 30-Май-26, 02:11	–2 +/–
С сишниками в эмбеддовке и везде проблема в том, что они в Си не разбираются. Не могут написать код без UB, а чаще и не хотят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

58. Сообщение от Аноним (59), 30-Май-26, 02:21	+3 +/–
> Столько буков и ни слова о конечном результате О конечном результате сказано - в 3 раза меньше кода, он гораздо более понятен и застрахован от нескольких классов распространённых ошибок. > только какие то бесполезные языковые абстракции. Выше есть пример кода с сишным циклом против `Iterator::any`. Не, я прекрасно понимаю что вы не программируете и для вас все эти слова это просто буквы, только зачем вы в обсуждение ЯП влезаете? > Потому что видимо на С не пробовали даже делать плагины и абстракции, как оно сделано в том же линухе/бсд в дровах для всего того же самого. О да, vtable руками, миксины на макросах и обработку ошибок на goto, а также плагины для дров FreeBSD мы действительно не писали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #98

59. Сообщение от Аноним (59), 30-Май-26, 02:26	+/–
Лол, для await не нужны прерывания, это просто сахар для построения конечного автомата из понятного линейного кода. Никакой магии там нет, равно как и никаких "rust захочет", можно всё то же что и в C, только это делается одной строкой, а не kloc'ами лапшеобразного бойлерплейта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

64. Сообщение от Nameh (?), 30-Май-26, 03:22	+1 +/–
Сахар и выразительность будет в приоритете обьема байт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

65. Сообщение от Сиус (?), 30-Май-26, 05:51	+/–
Этим кодом был Аль^W Hello world.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

66. Сообщение от MihaNix (ok), 30-Май-26, 07:10	+4 +/–
Пишите на том языке, который знаете хорошо. Это поможет добиться лучших результатов! Для микроконтроллера я обычно трачу больше времени на изучение документации и проверку своего понимания на практике. Выберу язык Си и буду работать с битовыми последовательностями, чтобы управлять низкоуровневыми функциями контроллера (конфигурирование портов ввода вывода и т.п.).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #69, #168

67. Сообщение от Аноним (-), 30-Май-26, 07:25	+/–
> Интересный эксперимент. Теперь плиз то же самое но на STM32F1xx которе в разы дешевле? Для игры в менее комфортных условиях. А не том переростке, по цене чуть не апликушного проца и с 1 поставщиком в виде STMicro - и более никого на этом глобусе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

68. Сообщение от Аноним (-), 30-Май-26, 07:25	+2 +/–
>  Выбираю SPARK. И много прошивок для МК написал? Захвастайся чтоли для разнообразия, как сие вообше?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

69. Сообщение от Аноним (-), 30-Май-26, 07:26	+/–
>  Пишите на том языке, который знаете хорошо. Это поможет добиться лучших результатов! Что-то не очень работает для приблуд с микропитоном.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

72. Сообщение от Аноним (72), 30-Май-26, 08:13	+2 +/–
В чем проблема?: int inc(int x) {     return x + 1; } #ifdef TEST #include <assert.h> int main() {     assert(inc(1) == 2); } #endif
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #76, #82

73. Сообщение от Vivaswan (ok), 30-Май-26, 08:15	+1 +/–
Вот именно то же хотел написать...    Как всё хитрО перемешано в тексте!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

74. Сообщение от Аноним (74), 30-Май-26, 10:14	+/–
Странно что не упомянули embassy - фреймворк для ембедовки на расте, вот он реально крут. Почти полностью на него перешел для чего-то более сложного чем ардуино.
Ответить | Правка | Наверх | Cообщить модератору

75. Сообщение от warlock (??), 30-Май-26, 10:17	–1 +/–
Ровно так и сделали. Получился Rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #80, #83

76. Сообщение от Прохожий (??), 30-Май-26, 10:34	+/–
Громоздко и чревато ошибками (если вместо TEST написать что-то другое, уже тест не  запустится потом).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

77. Сообщение от Прохожий (??), 30-Май-26, 10:50	+1 +/–
>У раста до сих пор нет стейбл версии В каком смысле? Есть, конечно. И эта новость как раз о stable версии. А есть ещё ночные сборки. > и на обратную совместимость они тоже положили Почитайте на досуге про editions.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

78. Сообщение от Прохожий (??), 30-Май-26, 10:52	–2 +/–
Куча? Да, согласен. Отлаженного? А вот здесь - большие сомнения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

79. Сообщение от Аноним (-), 30-Май-26, 10:53	+1 +/–
>  А в чем суть? Или пока сам не понял? В том что чем больше флехи - тем дороже будет чип стоить. Место на кристалле не бесплатное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #94

80. Сообщение от Аноним (-), 30-Май-26, 10:54	–2 +/–
>  Ровно так и сделали. Получился Rust. Они сделали - брейнфак какой-то. Где, простите, типажи выражовываются, так что вот тут итератор не итерирует оказывается и надо - сильно отдельный сеанс брейнфака, с чуть ли не патчем тулчейна чтобы это заработало. Жалкая пародия на то что может C++ как расширяемый синтаксис. Убого и гиморно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #181

82. Сообщение от Аноним (-), 30-Май-26, 11:04	–2 +/–
> В чем проблема?: Тебе про UB не рассказали чтоли? Прямо иллюстрацию подогнал, почему таких как ты на Rust надо, пинками. int inc(int x) {     return x + 1; } #ifdef TEST #include <assert.h> int main() {     assert(inc(1) == 2); } #endif 1) "int" у тебя - это сколько в граммах^W битахх? Ты хоть сам то границы применимости своего кода - назвать сможешь? Даже не чтобы потроллить адептов rust? А вот на Rust это таки вполне конкретное u32 -> u32. И тут этот вопрос не возникает. 2) Ты никогда не задумывался о формате хранения (signed) int и что вообще при wrap случается? Ну или если int = 2^31 (+1 на знак), что случается при пересечении границы 2^31 и переполнении? А, это вообще UB?! У тебя лажа на самом видном месте. И assert не чекает краевые случаи. Как впрочем и у адепров Rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #97, #103, #117

83. Сообщение от Аноним (83), 30-Май-26, 11:14	–1 +/–
У раста синтаксис функциональных языков, при чем тут си?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #88, #113, #148

84. Сообщение от Аноним (85), 30-Май-26, 12:05	+1 +/–
Снова не включили интерфейс для работы с указателям каждый второй четверг, кроме случаев, когда четверг выходной или 3е число. Жду.
Ответить | Правка | Наверх | Cообщить модератору

85. Сообщение от Аноним (85), 30-Май-26, 12:07	+2 +/–
Если ты не способен контролировать лайфтаймв сам, то ты и программировать не умеешь, потому что не понимаешь как у тебя программа работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #105, #179

88. Сообщение от warlock (??), 30-Май-26, 12:32	+/–
> У раста синтаксис функциональных языков, при чем тут си? Нет, у Раста синтаксис именно Си, только слегка изменённый в соответствии с нашим сегодняшним пониманием, как должен был выглядеть Си, чтобы не иметь ряда болезненных проблем. Естественно, что он в чём-то похож на функциональные языки, так как такой правильно спроектированный (перепроектированный) Си и должен был быть похож на функциональные языки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #193

89. Сообщение от Аноним (89), 30-Май-26, 12:39	–1 +/–
Как "160 мегагерц" уменьшит потребление оперативной памяти? Или ты думаешь что на 16 мегагерцах СИшная поделка станет магически образом потреблять меньше? 24640 против 42608 это почти в два раза.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #187

90. Сообщение от Аноним (89), 30-Май-26, 12:42	+/–
А кого волнует размер исходников? Или даже сколько оно компилируется? Для разработчика (а не какого-то б0мжа) собирается нормальная билд-машина. Зато в результате: - разница в размере бинарника 10% - разница в потреблении оперативки почти 50% в пользу раста - при одинаковой производительности
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #100, #188

91. Сообщение от Аноним (89), 30-Май-26, 12:44	–1 +/–
>  "Тестирование выполненной работы не выявило заметных преимуществ в использовании языка Rust вместо C" А... "черное это белое" от фанатов СИшки? Логично. > Поправил Скорее "Переврал".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #189

92. Сообщение от Аноним (89), 30-Май-26, 12:47	+/–
> У меня совершенно другой вопрос соберется ли этот же код на расте спустя года 3. Конечно. > У раста до сих пор нет стейбл версии Что значит "стейбл версия" в понимание такого профана как ты? Когда вышел С23, то поломалось куча проектов, так как true/false добавили. > и на обратную совместимость они тоже положили, так что такое. Феерическая чушъня. Почитай что такое edition (doc.rust-lang.org/edition-guide/editions/) В андроиде до сих пор можно писать на edition 2015.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #139, #191

93. Сообщение от Фнон (?), 30-Май-26, 12:50	+/–
Тут на форуме был человек, который учавствовал в разработке HAL (вроде бы) библиотек на расте. Было бы интересно услышать его мнение, как наверное самого разбирающегося. Друг, если тебя не затруднит, оставь свой комментарий.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #112

94. Сообщение от Фнон (?), 30-Май-26, 12:54	–1 +/–
> В том что чем больше флехи - тем дороже будет чип стоить. Сейчас копеечные чипы имеют столько памяти, что иногда даже избыточно. Условный STM32C0 за 20 центов имеет 32 KB Flash / 6 KB RAM По меркам микроконтроллеров это дофига.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #123

95. Сообщение от Фнон (?), 30-Май-26, 13:02	+2 +/–
Логических? Может и столько же. Ошибок памяти? Скорее то столько же - около нуля.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #111

96. Сообщение от Аноним (96), 30-Май-26, 13:06	–1 +/–
> С каждой новой версией Rust всё усложняется, расширяется, а значит программирование на нём становится менее надёжным. Интересное мнение. А можно какое-то подтверждение "программирование на нём становится менее надёжным" ? > А Cи остаётся таким же простым. Но ошибки в нем такие-же, как 50 лет назад)) Сколько там Copy Fuсkов уже нашли в ядре?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #143

97. Сообщение от Аноним83 (?), 30-Май-26, 13:58	+/–
А ты никогда не задумывался что большинство пихает int туда где пофик на результат? Ну оно примерно от -255 до 255 и ладно, больше программа считать никогда не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #107, #124

98. Сообщение от Аноним83 (?), 30-Май-26, 14:00	+/–
> О конечном результате сказано - в 3 раза меньше кода В вашем посте обсуждение только язковых конструкций, а не результата. > только зачем вы в обсуждение ЯП влезаете? Я скорее про применение и девиации адептов :) > vtable руками, миксины на макросах и обработку ошибок на goto, а также плагины для дров FreeBSD мы действительно не писали. Оно и видно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #101

99. Сообщение от Славик (ok), 30-Май-26, 14:00	+1 +/–
На С тоже можно упаковать в одну строчку. Но, глядя на С код, можно представить вссемблерный код и отлаживать в машинных кодах. Попробуй это сделать на расте, особенно когда компайлер сгенерит код с ошибкой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #115

100. Сообщение от Аноним83 (?), 30-Май-26, 14:01	+/–
А у вас с первого раза релиз выходит? Если нет - тогда разница ощутима.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #102

101. Сообщение от Аноним (101), 30-Май-26, 14:07	+/–
> Я скорее про применение и девиации адептов :) "Исследование проведено компанией STMicroelectronics при участии нескольких европейских университетов" Вы про девиации адептов СИшки? Еще раз для непонтливых. Фирма, которая разработала и производит микроконтроллеры, провела исследование и пришла к выводу что СИшка не имеет преимуществ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #121, #185

102. Сообщение от Аноним (101), 30-Май-26, 14:08	+/–
> Если нет - тогда разница ощутима. Вы что компилируете после добавления каждой новой строки? Я скорее в дебае залипну на большее время, чем выиграю от разницы в сборке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #122

103. Сообщение от Славик (ok), 30-Май-26, 14:18	+1 +/–
ну что за демагогия, во первых есть uint32_t тип, а во вторых С это системный язык,он не вставляет в код отсебятины и  подразумевает  что человек за клавиатурой знает что он делает. Нужно проверить переполнение - проверь соответствующий флаг процессора.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #106, #125

104. Сообщение от Аноним (104), 30-Май-26, 14:44	–1 +/–
>  сишники в эмбедовке разбираются в шинах данных, iommu, dma и тд. Хахахаха! Тойопта убившая кучу народу передает привет. Как тебе функция на 1300 строк кода с цикломатической сложностью в 146? > А эти на расте ни в чем не разбираются. Возможно ваше бездоказательное утверждение верно. Но тем не менее эти "не разбирающиеся" смогли написать код, которые на уровене СИшого по производительности. > Так что все-таки сишка под МК лучше уже хотя бы поэтому. Чтобы потом долго и уныло дебажить память попорченную "разбирающимися"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #114, #127, #144

105. Сообщение от Аноним (104), 30-Май-26, 14:47	+1 +/–
Т.е все сишники от ядра до утилит типа curl "программировать не умееют"? Ибо уже десятки лет одни и те же ошибки: выходы за пределы буферов, use after free и double free. Возможно просто инструмент поганый?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #136

106. Сообщение от Аноним (107), 30-Май-26, 15:04	+/–
>С это системный язык, Системный. Для PDP-11. >он не вставляет в код отсебятины Вставляет, это фича. >Нужно проверить переполнение - проверь соответствующий флаг процессора. И что, в сишочке знаковое переполнение вдруг стало не UB? Может и доступ к флагам процессора без ассемблерной вставки есть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #110

107. Сообщение от Аноним (107), 30-Май-26, 15:17	+/–
В принципе да, на сишочке так и пишут. "Пофиг на результат", "и так сойдет!", "переполнения точно не будет, зуб даю!". Неплохая характеристика как и ЯП, так и сообщества сишников.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #120

108. Сообщение от Markx (?), 30-Май-26, 15:31	+2 +/–
Синтаксис просто нечитаем, даже мутант C++ смотрится в разы понятней
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #134, #135, #172

109. Сообщение от Аноним (107), 30-Май-26, 15:42	+3 +/–
Еще недавно по историческим меркам тру микроконтроллер-деды то же самое про сишочку и ассемблер говорили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

110. Сообщение от Славик (ok), 30-Май-26, 16:55	+/–
ещё раз, м е д л е н н о,  "С" это системный язык. Рассматривай его как высокоуровневый ассемблер, если так будет проще. FYI "С" является системным языком для ВСЕХ операционных систем начиная с UNIX, включая windows and linux, на одной из которых ты строчишь камменты,  а PDP-11 это железо и "С" неможет быть системным языком для PDP-11. На PDP-11 крутилась изначально RSX-11, для которой системным языком был MACROASSEMBLER-11
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #119, #147

111. Сообщение от An (??), 30-Май-26, 18:42	–3 +/–
Вот вообще без разницы, какой тип ошибки приведет к уязвимости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #183

112. Сообщение от Аноним (9), 30-Май-26, 18:44	+/–
> был человек, который учавствовал в разработке HAL (вроде бы) библиотек на расте. Помянул его сегодня блинами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

113. Сообщение от Аноним (113), 30-Май-26, 18:51	+/–
> У раста синтаксис функциональных языков, при чем тут си? Где ты там увидел синтаксис функциональных языков? То есть, первый вопрос: что такое синтаксис функциональных языков? У кого синтаксис более функциональный, у haskell или у lisp? Или Rust для тебя является определением понятия "синтаксис функциональных языков"? Но раст ведь до кучи ещё и не функциональный язык вовсе. Его комбинаторы итераторов выглядят функциональной фишкой, но функциональный язык может любые функции комбинировать так, а не только значения типа Iterator.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #133

114. Сообщение от Аноним (114), 30-Май-26, 19:04	+/–
Си - язык практиков. Если практики из Тойоты отказались от Раста и продолжают писать на чистом. Значит чистый Си - торт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

115. Сообщение от ferris (?), 30-Май-26, 19:13	+/–
Когда последний раз отлаживал в машинных кодах?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #152

116. Сообщение от ferris (?), 30-Май-26, 19:15	+/–
proxmox
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

117. Сообщение от Аноним (72), 30-Май-26, 20:45	+/–
// if you want simple Rust style; // abort (panic) in debug mode #include <assert.h> #include <stdint.h> int32_t inc(int32_t x) {     assert(x != INT32_MAX);     return x + 1; } #ifdef TEST int main() {     assert(inc(INT32_MIN) == INT32_MIN + 1);     assert(inc(0) == 1);     assert(inc(INT32_MAX - 1) == INT32_MAX); } #endif
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

119. Сообщение от Аноним (107), 30-Май-26, 23:48	–2 +/–
Ты из своего "системного" языка не можешь стандартным способом, без ассемблерных вставок, получить доступ к функциональности своего процессора, которой сто лет в обед. Ни арифметики с насыщением, ни SIMD'ов, нихрена. Причем конпелятор SIMD'ы умеет и с радостью все автовекторизует, к вопросу "можно ли сишочку рассматривать как ассемблер". Можно, для PDP-11, аккурат все сишочные конструкции однозначно транслируются в PDPшный асм. >Рассматривай его как высокоуровневый ассемблер Мне стандарт запрещает так делать. Си определен для абстрактной машины, не для реальной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

120. Сообщение от Аноним83 (?), 31-Май-26, 00:02    Скрыто ботом-модератором	+/–
На всём так пишут, потому что важен результат. Просто растишки надеятся на то что более вумный компилятор не даст им ошибится. Хотя я конечно вас стебу, относительно того как я лично пишу, и иногда мне вспоминается что не все мои коллеги внимательны при написании, увы. С не для всех оптимальный выбор, некоторым больше подходят другие языки, типа пхп :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

121. Сообщение от Аноним83 (?), 31-Май-26, 00:04	+/–
И что? Пресвятые европецы на гранты написали нужные отчёты, и теперь это святая истина? Эти же люди писали что полов больше двух и прочую ерунду про глобальное потепление и что надо жрать не мясо а жуков. Завтра им проплатят и они напишут о пользе питания гумусом, мол замкнутый безотходный цикл, так и надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #131

122. Сообщение от Аноним83 (?), 31-Май-26, 00:06	–1 +/–
Так смотря какой размер у вашего проекта, для хэлло ворлда скорость раста ещё можно потерпеть, а когда у вас там хотя бы 100+ файлов - как то не комфортно будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #132

123. Сообщение от Аноним (123), 31-Май-26, 00:43	+/–
>> В том что чем больше флехи - тем дороже будет чип стоить. > Сейчас копеечные чипы имеют столько памяти, что иногда даже избыточно. > Условный STM32C0 за 20 центов имеет 32 KB Flash / 6 KB RAM > По меркам микроконтроллеров это дофига. Зато вон там есть RISCV за 10-20 центов, 2 кило RAM и 16 кило флеша на все. Но это все же 32 бит ядро с DMA и обвесом "как у STM32" - по сути только ядро заменили для удешевления. Я вот мелкооптовую партию за 15 центов урвал, теперь у меня пару мешочков этого под разные проекты, даже делаемые на фабах. Не, у STMicro таких цен не бывает. Особенно для мелких тиражей и околорознично и покупабельно простым смертным где попало. И это более-менее STM32F1xx-like обвес, плюс-минус. Так то круто за 15 центов, можно 32-битные фонарики фигачить или что там кто хотел %). Благо там PWM относительно высокочастотный, ADC какой никакой, похуже STM32 но за 15 центов за чип - рожу не кривят, etc. Ибо на выбор там будет PIC10/12 и может ATTiny какой - которые куда страшнее. А оверинженерия с RTOS, немеряными рантаймами и проч это прекрасно. А вы точно знаете как тот async/await работал внутрях, какие подставы есть и проч? Или через месяцок аптайма вы откушаете в тиражике уже раздаденом кастомерам ВНЕЗАПНЫХ факапов когда окажется что где-то как-то ресурсов все же не того и нате ка вам тойота-стайл? Да, Rust от срыва допустим стека не помогает на системе без MMU, если что. Об этом даже честно написано но кто ж из фанатов еще и доки то читает...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #138

124. Сообщение от Аноним (-), 31-Май-26, 01:36	+/–
> А ты никогда не задумывался что большинство пихает int туда где пофик > на результат? Угу, блин, и я потом такой - затыкаю в дидовом копролите - integer underflow, когда оно начинает радостно референсить - большие отрицательные индексы массива - при том отхватив сие прям из пакета с эфира. Ессно руша память в хлам. Ну или к вопросу за что сишникам предъявы выкатывают. За вот такие вот плюхи с граничными условиями. Я то конечно обиделся и апю радикально переделал - там теперь и проверки и апя все ж явно битности того что мы хотели хинтит. И все же - сказать что проблемы нет? Ну вот нет, слов из песни не выкинешь. > Ну оно примерно от -255 до 255 и ладно, Вообще "не менее 16 битов" по стандарту. Но все равно - проблема в том что вон там u32 -> u32 железно говорит о диапазоне корректной работы. А бцкий int - угадай попробуй сколько будет. И пэтому полно кода, который на вот этой платформе пашет - но удумай его на аврину какую собрать - которая еще и реально юзает мандат стандарта на 16 битов поюзает - ибо 8 битное ядро по 32 бита считает не ахти - багов будет немеряно. Правда сабжу там вообще нечего ловить по сути - но, давайте без "ну и что что горит сарай, зато у соседа корова сдохла!" > больше программа считать никогда не будет. А вот это - ниоткуда не следует зачастую. И в куче дидовых копролитов немеряно глупой лажи на тему. Так что креативно оформленным допустим радиопакетом - можно срубить немало лулзов. И мне совсем не нравится такое состояние дел. Да, я запатчил фирмвар реально сушествовавшему деплойменту неких простых систем с "простым RF линком" где был претупейший баг в обработчике пакетов. Теперь там конечно будет куда сложнее стрельнуть в пятку, но в си и мало-мальски структурированые апи - боль. Ибо скажем если struct передавать в функцию - ну, круто, да, кроме того что ABI не регламентирован. Поэтому попробуй так сторонний модуль позвать, допустим функцию бутлоадера из фирмвара вызвать, при том что оно - две независимые программы и все держится только на ABI соотвественно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

125. Сообщение от Аноним (-), 31-Май-26, 01:54	+1 +/–
> ну что за демагогия, во первых есть uint32_t тип, Тот то хмырь с примером его не поюзал, вместо этого влепив классический UB. Для unsigned переполнение таки - well defined behavior, этим можно пользоваться. Но что будет с той шляпой на границах битностей вообще никем не гарантировано. Как и диапазоны работы! Таки стандарты надо читать, а голову - юзать. Иначе адепты раста вам напихают - и будут по своему правы. > а во вторых С это системный язык, он не вставляет в код отсебятины Ну вот это тоже - где как. Допустим: typedef struct something ... { ...поля... } something; ... something var1; something var2 = {.a = 10, .b = 20, .c[30] = 5}; ... var1 = var2; // Как тебе такое, Элон Маск?! И да, попробуй struct с array и ко - без втыкания отсебятины влобовую то так присвоить? :). Конечно, по сравнению с rust это невинные шалости. Но memcpy тебе тут все же потребуется, ага. И если у тебя его нет - как раз и напишешь заодно! :D Или ЭТО завалится на фазе линковки в режиме freestanding по undefined reference to memcpy(). Не, явно ты его нигде не юзал, но... компилер может и сам сие организовать для таких вещей. Ну или как структуру с массивом и ко присваивать по вашему, кроме втыкания "неявного" memcpy? Просто в сях такого немного и грабли все известнве. А сколько тех господ понимает как их async-await допустим работает - и способны трезво оценить перспективы прострела пяток, worst cases по ресурсам/сбоям и проч - ну таки сложность рантайма тому очень не способствует. > и подразумевает  что человек за клавиатурой знает что он делает. Нужно > проверить переполнение - Ну, вот тут, как раз, пример с не особо годной обработкой граничных условий начиная с того момента что они не есть well defined с самого начала. Это источник багов. При том на PC такой код может с 32 бит int работать изумительно а потом мы на AVR с 16 битами int придем - и покушаем лаптем - и даже не щей. > проверь соответствующий флаг процессора. Мда? Ну и как это на си стандартно сделать? В принципе сабж то тоже ничем не лучше - у них проверки тоже видите ли только в режиме дебага - а в релизе - это таки замедляет код и потому скипается. Так что сишник может с тем же успехом такой же билд себе запилить с -fsanitize=undefined в общем то. И да, это даже на МК на минималках - лезет, оно может вместо полной штуки воткнуть минимальный обработчик вызывающий bad opcode, так что какой-нибудь Cortex M просто поймает hard fault или что там у кого - и вы тоже в курсе профака :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #141, #162

126. Сообщение от Аноним (-), 31-Май-26, 02:00	+1 +/–
> Нет, не сишники, а эмбеддовщики. Знания о том как работает железо от > языка не зависят и применяются одинаково в любом языке. Ну вот не скажи. Если в си можно влобовую записать в регистр - то в Rust работа с такими вещами любо лютый unsafe (а чем это тогда лучше си?) либо совершенно жесточайший брейнфак, увы и ах. Можно спятить даже просто делая работу с GPIO. Да, круто конечно - делегировать это богам и расслабить булки, но в итоге то вы будете - вторым сортом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #149

127. Сообщение от Аноним (-), 31-Май-26, 02:06	+1 +/–
>>  сишники в эмбедовке разбираются в шинах данных, iommu, dma и тд. > Хахахаха! > Тойопта убившая кучу народу передает привет. А представляешь, Rust без MMU тоже переполнение стека - не поймает. Об этом честно в доке написано - но кто ж из фанатов то ее еще и читает? У вас таких - вера в серебряные пули. Это еще опаснее - ибо сочетание слабоумия и отваги еще никого до добра не доводило. Особенно с грубой переоценкой своих сил и незнанием своих инструментов. > Как тебе функция на 1300 строк кода с цикломатической сложностью в 146? Уволить нах...рен того кто ЭТО писал. Как сие MISRA checks вообще прошло?! А, заоверрайдили? Тогда еще и в тюрьму посадить причастных. По статье criminal negligence. Ну или что таким помешает и в rust unsafe всякий напихать или так же облажаться с оценкой worst case и таки тоже - стек вынести? А MMU там как раз и нет... это МК а не апликушник же. > Но тем не менее эти "не разбирающиеся" смогли написать код, которые на > уровене СИшого по производительности. Остается вопрос будет ли он на уровне сишного по багованости, предсказуемости и майнтайнить его вдолгую. Вот вы там точно в курсе что async/await реально унутрях делал допустим и как это в системный уровень и ресурсы транслируется? Или вы их от балды напихаете - а потом через месяцок у кастомеров - ХЛОБЫСЬ!! И вы знаете - если вы на допустим гироскутере чесали - и ут вдруг panic() в фирмваре мотора - как обработка ошибок, ужас ужас - вашему таблу встретившемуся с асфальтом, имхо, такая обработка ощибок все же не зайдет. А что делали в Linux по таким поводам - господи, этот позор надо просто видеть. Патчили и тулчейн и стлибы, и что там еще. Если б си был настолько геморным - он бы никогда не взлетел вообще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #137

128. Сообщение от разраб (?), 31-Май-26, 02:45	+/–
F# конечно из тяжелых, но с удобной разработкой. Oberon легкий быстрый но разработка на уровне виднос 95.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

129. Сообщение от разраб (?), 31-Май-26, 03:05	–2 +/–
speakez tech разрабатывает фрэймворк на Fsharp под двойной лицензией который позволяет генерировать машинный код. Полностью в рамках функциональной парадигмы и разграниченных продолжений. посредством llvm mlir. По моему это имеет гораздо больший потенциал. Жаль что лицуха двойная.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #178

130. Сообщение от разраб (?), 31-Май-26, 03:39	–1 +/–
Fidelity Framework если кому интересно на гитхаб
Ответить | Правка | Наверх | Cообщить модератору

131. Сообщение от Прохожий (??), 31-Май-26, 07:01	+/–
Ещё раз, может со второго раза дойдёт (хотя, маловероятно, глядя на твои попытки в аналогии). Отчёт писался сотрудниками фирмы-производителя микросхем для своих нужд. Причём здесь гранты, Европа и количество полов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

132. Сообщение от Прохожий (??), 31-Май-26, 07:03	+/–
Раст компилирует библиотеками. Если там ничего не менялось, то и компилироваться повторно не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

133. Сообщение от Прохожий (??), 31-Май-26, 07:10	+/–
>Где ты там увидел синтаксис функциональных языков? Да вот же (из примера выше): if haystack.iter().any(|elt| elt.field == needle) {} >Но раст ведь до кучи ещё и не функциональный язык вовсе Он мультипарадигменный, да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

134. Сообщение от Прохожий (??), 31-Май-26, 07:15	–3 +/–
Ох уж эти эксперты... Из примеров выше. Rust #[test] fn test_inc() {     assert_eq!(inc(1), 2); } C #include <assert.h> #include <stdint.h> int32_t inc(int32_t x) {     assert(x != INT32_MAX);     return x + 1; } #ifdef TEST int main() {     assert(inc(INT32_MIN) == INT32_MIN + 1);     assert(inc(0) == 1);     assert(inc(INT32_MAX - 1) == INT32_MAX); } #endif
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #174

135. Сообщение от Прохожий (??), 31-Май-26, 07:17	+/–
Или вот ещё, тоже из примеров выше '''c bool found = false; for (size_t i = 0; i < sizeof(haystack); i++) {     if (strcmp(haystack[i].field, needle) == 0) {         found = true;         break;     } } if (found) {} ''' '''rust if haystack.iter().any(|elt| elt.field == needle) {} '''
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

136. Сообщение от Аноним (136), 31-Май-26, 09:28	–2 +/–
Твоя логическая ошибка или попытка манипуляции, называется "соломенное чучело", ты пытаешься заменить мой тезис на более слабый. А учитывая как страстно ты защищаешь инструмент...ты этим только подтверждаешь мой тезис, что ты не умеешь программировать, а веришь в магию. Ты наверное и ИИ любишь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #180

137. Сообщение от Аноним (-), 31-Май-26, 09:36	+/–
>> Тойопта убившая кучу народу передает привет. > А представляешь, Rust без MMU тоже переполнение стека - не поймает. А при чем тут раст? Речь про СИшников которые пишут эмбедовку. > Это еще опаснее - ибо сочетание слабоумия и отваги еще никого до добра не доводило. Особенно с грубой переоценкой своих сил и незнанием своих инструментов. Ты сейчас про тойоптеров? Они убили кучу народу своим овнокодом. >> Как тебе функция на 1300 строк кода с цикломатической сложностью в 146? > Уволить нах...рен того кто ЭТО писал. За что? Где такой закон? А нету. > Как сие MISRA checks вообще прошло?! А, заоверрайдили? А разве МИСРА запрещает оверрайд? > Тогда еще и в тюрьму посадить причастных. По статье criminal negligence. К сожалению они просто заплатили штраф. > Ну или что таким помешает и в rust unsafe всякий напихать или так же облажаться с оценкой worst case и таки тоже - стек вынести? Пока на расте таких ошибок не было. Вот как будет - тогда и поговорим. > Остается вопрос будет ли он на уровне сишного по багованости, предсказуемости и майнтайнить его вдолгую. Вопрос на который у вас ответа нет. В отличии от STM) > И вы знаете - если вы на допустим гироскутере чесали - и ут вдруг panic() в фирмваре мотора - как обработка ошибок, ужас ужас - вашему таблу встретившемуся с асфальтом, имхо, такая обработка ощибок все же не зайдет. Классная фантазия. Но пока про такие случаи я не слышал. А тойоптеры в таком случае просто делали CPU reset.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

138. Сообщение от Аноним (-), 31-Май-26, 09:39	–2 +/–
> А оверинженерия с RTOS, немеряными рантаймами и проч это прекрасно. Пф, система которая работает в миллионах девайсах критикуется горлопаном с форума. Шикарное зрелище. > А вы точно знаете как тот async/await работал внутрях, какие подставы есть и проч? Или через месяцок аптайма вы откушаете в тиражике уже раздаденом кастомерам ВНЕЗАПНЫХ факапов когда окажется что где-то как-то ресурсов все же не того и нате ка вам тойота-стайл? А ты уверен что твой овнокод нормально протестирован? > Да, Rust от срыва допустим стека не помогает на системе без MMU, если что. А в системе с MMU)? > Об этом даже честно написано но кто ж из фанатов еще и доки то читает... Не надо проецировать свою убогость на окружающих.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #164

139. Сообщение от Аноним (139), 31-Май-26, 10:16    Скрыто ботом-модератором	+/–
У меня к растаманам придирка. Что за вантузное слово "эдишн"? Другое нормальное слово не могли придумать. Где юниксовость а?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

140. Сообщение от Пыщь (?), 31-Май-26, 10:20	+/–
Просто на ADA, совсем без контрактов (чтобы даже запаха SPARK не было), на каком-нибудь light профиле, столька букафф будет! Если про perl можно шутить, что это язык для написания, а не для чтения, то про ada - это для чтения, а не написания. Ну а если профиль пожирнее, то готовь ОЗУ и свободные такты для RTL. Правильная оптимизация потребует погружения в особенности ада :) А уж ежели контрактами в SPARK погонять, то ещё больше букаф придётся докидать. Правильные полные спецификациии и жирные контракты - залог удачи в SPARK (так думаю). С неполной спецификацией, допускающией широкие возможности трактовки, конопляторная оптимизация обязательно испоганит твой даже полностью верный код в самом скромном уголке прошивки. Совсем без асма и це на голом железе тяжко будет, почти невозможно. Даже полуофициальный startup-gen от adacore выдаёт асмовую заготовку для начальной инициализации. На затравочку ещё нужно помнить, что общедоступных binding микросхем, аналогичных це-шным CMSIS, можно по пальцам перечесть. Может это только я так бултыхаюсь доступными (без регистраций и смс) инструментами, а у серьёзных адовых погроммистов всё в ажуре.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

141. Сообщение от Славик (ok), 31-Май-26, 10:31	+/–
> И да, попробуй struct с array и ко - без втыкания отсебятины влобовую то так присвоить? :).......    Но memcpy тебе тут все же потребуется, ага. у вас наверное компайлер от майкрософт :))) вот, пожалуйста int main() { typedef struct  {uint32_t a; uint32_t b; char c[35];} fields;   fields v1 = {.a=10, .b=20, .c[30]=5}, v2;   v2 = v1; } gcc 16 x86_64 генерит нормальный код и никакого memcpy         push    rbp         mov     rbp, rsp         mov     DWORD PTR [rbp-48], 10         mov     DWORD PTR [rbp-44], 20         mov     QWORD PTR [rbp-40], 0         mov     QWORD PTR [rbp-32], 0         mov     eax, 0         movabs  rdx, 1407374883553280         mov     QWORD PTR [rbp-24], rax         mov     QWORD PTR [rbp-16], rdx         mov     DWORD PTR [rbp-9], 0         mov     rax, QWORD PTR [rbp-48]         mov     rdx, QWORD PTR [rbp-40]         mov     QWORD PTR [rbp-96], rax         mov     QWORD PTR [rbp-88], rdx         mov     rax, QWORD PTR [rbp-32]         mov     rdx, QWORD PTR [rbp-24]         mov     QWORD PTR [rbp-80], rax         mov     QWORD PTR [rbp-72], rdx         mov     rax, QWORD PTR [rbp-20]         mov     rdx, QWORD PTR [rbp-12]         mov     QWORD PTR [rbp-68], rax         mov     QWORD PTR [rbp-60], rdx         mov     eax, 0         pop     rbp         ret >При том на PC такой код может с 32 бит int работать изумительно а потом мы на AVR с 16 битами int придем - и покушаем лаптем - и даже не щей. для этого есть int32_t и потом никто и не говорит что С переносим как джава.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #146, #166

142. Сообщение от proglyk (ok), 31-Май-26, 13:04	+/–
Хочется молча оставить ссылку на c89 стандарт, на котором до сих пор пишут и не лазают в Ютубе и ещё куда-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

143. Сообщение от proglyk (ok), 31-Май-26, 13:07	+/–
В ядре чего? Прошивки для МК? Ты забыл о чем тема новости человек? Сейчас не спор что лучше в принципе, а что лучше для МК, а там задачи порой очень простые и никакие ядра не надо в спор тянуть
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

144. Сообщение от proglyk (ok), 31-Май-26, 13:12	+/–
Нервный смех. Мне не нравится что ты лезешь в споры и что-то доказывает, при этом являясь Толи студентом с взлетевший ЧСВ из-за того, что rust book прочёл, Толи не учащимся на своих ошибках мужиком.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #145

145. Сообщение от Аноним (145), 31-Май-26, 13:21	+/–
> Нервный смех. Признак ̶д̶у̶р̶а̶ч̶и̶н̶ы̶  недалекого ума? > Мне не нравится что ты лезешь в споры В общем-то пофигу, что тебе не нравится. > и что-то доказывает, при этом являясь Толи студентом с взлетевший ЧСВ из-за того, что rust book прочёл, Толи не учащимся на своих ошибках мужиком. Твой хрустальный шар явно подделка. В статье написано что STM не видит преимуществ СИшки перед растом. Но СИшная охранота начинает куракекать и рассказывает что "СИ для МК лучше".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144

146. Сообщение от Аноним (107), 31-Май-26, 14:02	+1 +/–
Кек, "у меня такая же нога и она работает". 294ый прав, gcc *вставляет* вызовы memcpy/memset в некоторых случаях, об этом *написано* в его документации и если плотненько обмазываться эмбеддедом об этом рано или поздно узнаешь на опыте. энжой: https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #151

147. Сообщение от Аноним (107), 31-Май-26, 14:09	+/–
Ваш "ассемблер" даже указатели без фокусов сравнить не может, лол. $ cat prov.c #include <stdio.h> int main() {         int a = 10;         int b = 20;         int *p0 = &a + 1;         int *p1 = &b;         if (p0 == p1) {                 printf("equal!\n");         }         printf("p0: %p, *p0: %d, p1: %p, *p1: %d\n", p0, *p0, p1, *p1);         return 0; } $ gcc -Wall -Wextra -O3 prov.c -o prov $ ./prov p0: 0x7fffe1b7ba24, *p0: 20, p1: 0x7fffe1b7ba24, *p1: 20
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #150

148. Сообщение от Аноним (149), 31-Май-26, 14:41	–1 +/–
У раста 1 в 1 плюсовый синтаксис
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #171, #194

149. Сообщение от Аноним (149), 31-Май-26, 14:48	+/–
> Ну вот не скажи. Если в си можно влобовую записать в регистр - то в Rust работа с такими вещами любо лютый unsafe (а чем это тогда лучше си?) Тем что всё остальное safe, сложно для понимания да? > либо совершенно жесточайший брейнфак С чего брейнфак-то? Простейшее API, а-ля `PORTB.pin(3).set_direction(PinDirection::Out).enable_pin(true)`. Это из плюсов код, если что, который компилится в те самые 2 инструкции, и то как оно должно быть независимо от языка. На rust будет так же с точностью до байта и safe. Вы видимо остановились в развитии на `PORTB &= 1 << 3`, так вам на пенсию пора.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #190, #197

150. Сообщение от Славик (ok), 31-Май-26, 15:31	+/–
> Ваш "ассемблер" даже указатели без фокусов сравнить не может, лол. > >         int a = 10;   >         int b = 20; >         int *p0 = &a + 1; >         int *p1 = &b; > кто вам сказал что адрес b будет равен адресу a+1 ? Стандарт языка? > >    if(p0 == p1) { >     printf("equal!\n"); >    } > [overquoting] > $ gcc -Wall -Wextra -O3 prov.c -o prov > $ ./prov > p0: 0x7fffe1b7ba24, *p0: 20, p1: 0x7fffe1b7ba24, *p1: 20 > вы делаете -O3  и ожидаете вменяемый ответ? FYI if(p0 == p1) выброшена компилятором как всегда дающая false Это вопрос не к языку а к компайлеру
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147 Ответы: #153

151. Сообщение от Славик (ok), 31-Май-26, 15:38	+/–
> Кек, "у меня такая же нога и она работает". 294ый прав, gcc > *вставляет* вызовы memcpy/memset в некоторых случаях, об этом *написано* в его > документации и если плотненько обмазываться эмбеддедом об этом рано или поздно > узнаешь на опыте. > энжой: https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html Ну, gcc это такой компайлер что ключь -S и анализ .s файла ОБЯЗАТЕЛЕН.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #154

152. Сообщение от Славик (ok), 31-Май-26, 15:58	+/–
> Когда последний раз отлаживал в машинных кодах? регулярно просматриваю .s файлы. И иногда нахожу много интересного, такого что приходится переделывать .c файлы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #165

153. Сообщение от Аноним (107), 31-Май-26, 16:33	+/–
>кто вам сказал что адрес b будет равен адресу a+1 Ты вывод-то посмотри. Они побитово равны. >вы делаете -O3  и ожидаете вменяемый ответ? Да, мой код всегда компилируется с -O3/-Os. Какой смысл писать на Си без оптимизации? >FYI if(p0 == p1) выброшена компилятором как всегда дающая false >Это вопрос не к языку а к компайлеру Ты Си не знаешь. Стандарт *разрешает* так делать, в компиляторе тут нет ошибки. Сишочка определена на абстрактной машине в которой у указателей кроме адреса есть еще и происхождение (provenance).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #157

154. Сообщение от Аноним (107), 31-Май-26, 16:45	+/–
>Ну, gcc это такой компайлер NYET. Rifle^W Compiler is FINE. Не надо требовать от языка того, чем он не является и будет все нормально. >что ключь -S и анализ .s файла ОБЯЗАТЕЛЕН. UB-driven development, понемаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

155. Сообщение от Аноним (155), 31-Май-26, 17:08	+1 +/–
> В си никто не мешает положить тесты рядом с кодом. Да? А чего ж не кладут тогда? Вредители что ли?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #159

156. Сообщение от Аноним (155), 31-Май-26, 17:13	–1 +/–
> Знания о том как работает железо от языка не зависят и применяются одинаково в любом языке. Так то знания. А этот пациент заучил заклинания на сях: боромочи дождь-дождь-дождь, он и пойдёт рано или поздно. Делай вот так, и будешь шиной командовать. Знание правильных слов на сях заменяет знание железа. Но снаружи особо не видно, пока язык имплементации сменить не потребуют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

157. Сообщение от Славик (ok), 31-Май-26, 19:28	+/–
Ладно малыш, закончим на этом. >>кто вам сказал что адрес b будет равен адресу a+1 > Ты вывод-то посмотри. Они побитово равны. >>вы делаете -O3  и ожидаете вменяемый ответ? > Да, мой код всегда компилируется с -O3/-Os. Какой смысл писать на Си > без оптимизации? Ну да, дальше hello world ты не потянул. >>FYI if(p0 == p1) выброшена компилятором как всегда дающая false >>Это вопрос не к языку а к компайлеру > Ты Си не знаешь. Стандарт *разрешает* так делать, в компиляторе тут нет > ошибки. Сишочка определена на абстрактной машине в которой у указателей кроме > адреса есть еще и происхождение (provenance). Ха-Ха, ты даже не можешь обьяснить результаты твоего же "хело ворлд" выше. Знаток "С" блин.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #158

158. Сообщение от Аноним (107), 31-Май-26, 20:28	+/–
>ты даже не можешь обьяснить результаты твоего же "хело ворлд" выше. Я объяснил, дедуль. Не, можешь настаивать что тут ошибка в конпеляторе, авторам ISO/IEC TS 6010 не забудь сообщить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

159. Сообщение от Сладкая булочка (?), 31-Май-26, 21:12	–1 +/–
>> В си никто не мешает положить тесты рядом с кодом. > Да? А чего ж не кладут тогда? Вредители что ли? Можно, а зачем? (с)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155

161. Сообщение от Аноним (161), 01-Июн-26, 02:05	+1 +/–
Да скорее не усложняется а становиться сильнее и сложнее с каждым разом запомнить сколько и где там и API стал новый. Если в сишке это база не менялась голой, то тут каждый день новая м версия библиотек и самого языка
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

162. Сообщение от Аноним (-), 01-Июн-26, 02:09	+/–
>> проверь соответствующий флаг процессора. > Мда? Ну и как это на си стандартно сделать? В принципе сабж то тоже ничем не лучше - у них проверки тоже видите ли только в режиме дебага - а в релизе - это таки замедляет код и потому скипается. Так что сишник может с тем же успехом такой же билд себе запилить с -fsanitize=undefined в общем то. И да, это даже на МК на минималках - лезет, оно может вместо полной штуки воткнуть минимальный обработчик вызывающий bad opcode, так что какой-нибудь Cortex M просто поймает hard fault или что там у кого - и вы тоже в курсе профака :) В Rust флаг переполнения процессора можно узнать с помощью функции overflowing_add. То, что вы нафантазировали, не имеет никакого отношения к вопросу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #167

163. Сообщение от Феникс123 (?), 01-Июн-26, 05:14	+1 +/–
Сколько unsafe было в реализации на Rust? Не нашел в статье.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #175, #176

164. Сообщение от Аноним (-), 01-Июн-26, 06:37	+1 +/–
> Пф, система которая работает в миллионах девайсах критикуется горлопаном с форума. > Шикарное зрелище. Пф, вон то - за 1 год продается большим тиражом, чем все вы вместе взятые, вероятно. Их даже кастомные малотиражники выносят - мешками, на вес. ИМХО, 1) Если вы козыряете количествами в миллионы - извольте пруфлинки на продукты. 2) Лично вы как к всему этому относитесь? Я вот embedded системки делаю. В том числе и на вон тех. Потому что дешево и сердито. Не, RTOS я как раз не юзаю обычно. Если мне хайлевел крутой приспичивает я одноплатник с Linux беру. Куда круче и менее мучительно чем отношения с RTOS. > А ты уверен что твой овнокод нормально протестирован? Мой код работает в сотнях систем. И поверьте, за сбои мне - предъявят. Я несу ответственность за этот код и качество его работы. Это - пойнт работать со мной для моих кастомеров. С моей стороны это - причина хотеть понимать что там, где, как и почему и каковы наихучшие расклады. Особенно - в last line of defence на основе МК. Которая прежде всего - должна все удержать. Когда everything else failed - МК должен спасти ситуацию. На совсем брутальные вещи конечно есть хардварные защиты и предохранители но они "тупые". Когда мне надо - я знаю мой рантайм до буквально последнего битика в таких вещах. Как, что и почему оно там. А теперь извольте ответить за себя - вы в курсе как вон то реально работает? И ли вы в режиме черного ящика и ритуалов позовете магию, понятия не имея как оно - но при этом рассказывая как все это "круто" и "безопасно". Не, вы знаете, юзать железки сделанные теми кто танцевал ритуалы не понимая inner working это не круто и не безопасно. А в эмбедовке - за такое можно и присесть если оно что-то пожжет, или кого-то покалечит/убьет и под внимание попадет ваш уровень компетенции, как с Тойотой и было. >> Да, Rust от срыва допустим стека не помогает на системе без MMU, если что. > А в системе с MMU)? Системы c MMU стоят других бабок, это другой уровень сложности. У упомянутого МК тоже MMU нет насколько я помню. Т.е. это все применимо прямо к сабжу и там еще тщательно проверить надо - что хипстеры с горящими глазами, за которых подумает кто-то другой - вообще правильно обыграли эти моменты, лэйаут фирмвары, сетап MPU и проч - или таки у них "тойота" получится ничем не хуже. >> Об этом даже честно написано но кто ж из фанатов еще и доки то читает... > Не надо проецировать свою убогость на окружающих. Вот и не проецируйте. По вашим ответам отлично видно ваш уровень квалификации. 1) Вы ушли от ответа в курсе ли вы как тот async/await работает и есть ли какие-то допустим риски по ресурсам и их исчерпанию и "что будет, если". 2) Вы даже не в курсе что у сабжевого мк тоже MMU насколько я помню - нет. Но наяриваете про тему с MMU. Если кто не в курсе - в МК обычно нет paging и свопа. Как максимум там может быть здорово упрошенный MPU но 1) это другое 2) системщик обычно должен явно обыграть некоторые моменты и 3) в этом месте упование на то что за вас все другие умные люди сделают вас как раз и подставит по полной. Потому что вот это - совсем не факт. И по таким вещам мы и узнаем кто крутой системщик а кто пальцы загнуть вышел. И я уже нашел мой ответ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

165. Сообщение от Аноним (-), 01-Июн-26, 06:53	+/–
> регулярно просматриваю .s файлы. И иногда нахожу много интересного, такого что приходится > переделывать .c файлы. Я предпочитаю отображение дисасма пополам с сорцом. Так несколько нагляднее во что оно трансформировалось. Правда в случае LTO - это может выглядеть не совсем так, или даже совсем не так как вы это себе представляли. Но все же идею - дает в общем случае. А те "эксперты" палят свою квалификацию. Главное чтоб не девайсы и хаты/инсталляции юзерей, ибо "слабоумие и отвага" в паре с верой в серебряеые пули и то что за вас другие подумали - может творить чудеса. Но - увы - со знаком минус.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

166. Сообщение от Аноним (-), 01-Июн-26, 07:05	+/–
> у вас наверное компайлер от майкрософт :))) Нет, у меня - freestanding фирмвара МК без builtids, stdlib - freestanding режим. Где примерно такое по смыслу - чпок - однажды обломало линковку с сообщением что memcpy() не найден. Да, компилер при этом по сути только кодогенератор: весь стартап код, рантайм и проч лично мой под кастомный env. И если что - в доках GCC написано про это все. Но, кажется, это вообще совсем не про майкрософт?... > вот, пожалуйста > Теперь то же самое в режиме freestanding и без builtins попробуй. И да, это вполне может быть инлайнингом какого-то куска от memcpy builtin'а. Вообще-то такое надо смотреть пополам с отображением сорца. А, да, что и как (не) инлайнить он так то тоже - сам решает. > для этого есть int32_t и потом никто и не говорит что С > переносим как джава. Да он намного больше джавы переносим так то. Я могу один и тот же код на поганом AVR с 8 битами запустить - а могу и на здоровом 64 бит серванте. Если код нормально писан - результат должен быть одинаковый. И вот тут мы узнаем чего тот или иной сишник стоил и насколько он хотя-бы свои стандарты знает.... И да, эти стандарты так то обычно не жалуют - те кто их еще и читал. И вот что вас упаси - так это изучать свойства си путем экспериментов. Если что-то где-то работает в конкретном случае это совсем не дает оснований экстраполировать что оно работает всегда и везде. Увы, но с си это работает совсем не так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141

167. Сообщение от Аноним (-), 01-Июн-26, 07:07	+/–
> В Rust флаг переполнения процессора можно узнать с помощью функции overflowing_add. Ну и сколько кода это реально делает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162

168. Сообщение от Проходил мимо (?), 01-Июн-26, 07:37	+/–
Битовые операции в Си и в Rust очень похожи, если что. Например проверка битового флага на Си у вас будет примерно так: #define FLAG 0x01 //  Определение переменной val размером 1 байт, старшая половина которой //  используется для хранения флагов а в младшей хранится какое-то значение от 0 до 15 unsigned char val = 0; //  Тут что-то происходит //  Выделяем значение и проверяем флаг num = val & 0x0F; val = (val & 0xF0) >> 4; if( val & FLAG ) {     // Делаем что-то полезное } А на Rust так: const FLAG: u8 = 0x01; //  Определение переменной val размером 1 байт, старшая половина которой //  используется для хранения флагов а в младшей хранится какое-то значение от 0 до 15 let mut val: u8 = 0; //  Тут что-то происходит //  Выделяем значение и проверяем флаг num = val & 0x0F; val = (val & 0xF0) >> 4; if (val & FLAG) > 0 {     // Делаем что-то полезное } А еще в Rust есть куча вариантов битовых операций (например сдвига), отличающихся наличием или отсутствием проверки переполнения и самого подхода к сдвигу. Практика показывает, что это очень удобный и правильный подход.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #186

169. Сообщение от Проходил мимо (?), 01-Июн-26, 07:46	+1 +/–
Для поддержки асинхронности используется специальный кусок кода (специальный движок), поэтому, ИМХО, мечты про 276 байт не осуществимы в принципе. ЗЫ Слово unwrap в предполагаемом коде для микроконтроллера лично у меня вызывает удивление, только выраженное ненормативной лексикой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

170. Сообщение от Проходил мимо (?), 01-Июн-26, 08:04	+/–
Ваши представления об обратной совместимости у Rust весьма далеки от реальности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

171. Сообщение от Проходил мимо (?), 01-Июн-26, 08:08	+/–
Не один в один. Далеко не 1 в 1. Но похожих моментов действительно очень много.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148

172. Сообщение от Проходил мимо (?), 01-Июн-26, 08:14	+/–
Подавляющее большинства кода на Rust выглядит понятным и достаточно легко читаемым. Чего нельзя сказать о последних генерациях Си++. Ваш же случай давным давно описал Крылов в басне "Лиса и Виноград".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #195

173. Сообщение от Аноним (174), 01-Июн-26, 08:49	+/–
Готовность? 0 :)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #177

174. Сообщение от Аноним (174), 01-Июн-26, 08:50	–1 +/–
Да, плюсы и си читаются легче
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #182

175. Сообщение от Прохожий (??), 01-Июн-26, 08:59	–1 +/–
Какая разница?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163

176. Сообщение от Прохожий (??), 01-Июн-26, 09:06	–1 +/–
Для типичного "эксперта". Unsafe features: 1. Dereference a raw pointer. 2. Call an unsafe function or method. 3. Access or modify a mutable static variable. 4. Implement an unsafe trait. 5. Access fields of unions. It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any of Rust’s other safety checks: If you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety. You’ll still get some degree of safety inside an unsafe block.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163

177. Сообщение от Прохожий (??), 01-Июн-26, 09:09	+/–
Вообще-то Volvo уже использует Rust в некоторых своих прошивках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173

178. Сообщение от Прохожий (??), 01-Июн-26, 09:15	+/–
Если вам нужна формальная верификация, для Rust, например, вот это сделали: https://github.com/creusot-rs/creusot Всё "в рамках функциональной парадигмы", потому что там трансляция в функциональный язык программирования идёт, насколько я понял.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

179. Сообщение от Прохожий (??), 01-Июн-26, 09:41	+/–
У вас очевидные проблемы с логикой. Любой человек (абсолютно, без исключений) подвержен ошибкам. Особенно это актуально на сколь-либо большом коде. Другими словами, даже если вы способны контролировать лайфтаймы на небольшом участке кода, никто не может дать гарантию (и вы в том числе), что вы справитесь также успешно на большом участке. Что, собственно, и показывает многолетняя практика программирования на Си.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

180. Сообщение от Прохожий (??), 01-Июн-26, 09:42	+/–
Ваш тезис не выдерживает на практике никакой критики.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #192

181. Сообщение от Прохожий (??), 01-Июн-26, 09:49	+/–
>Они сделали - брейнфак какой-то. Сказал любитель C++ со спецификацией на полторы тысячи страниц, которую, уверен, никогда не читал полностью. >Жалкая пародия на то что может C++ как расширяемый синтаксис. Например, что такого можно сделать в C++, чего нельзя сделать в Rust?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

182. Сообщение от Прохожий (??), 01-Июн-26, 09:52	+/–
:) Фанатизм во всей своей "красе". Как может читаться легче вот эта простыня, по сравнению с одной строкой кода?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174

183. Сообщение от Аноним (183), 01-Июн-26, 10:33	+1 +/–
Есть огромная разница. Во-первых, это два независимых класса ошибок. Устранение одного из классов ошибок равносильно устранению класса причин возникновения ошибок, а значит их в целом становится меньше. В коде на C причинами ошибок становятся как логические ошибки, так и ошибки работы с памятью - причинами ошибок на Rust становятся в основном логические. Если вам непонятно, что если устранить половину из причин катастрофы, риск катастрофы становится меньше, то у меня плохие новости. Во-вторых, есть огромная разница между логическим ошибками и ошибками работы с памятью. Ошибка работы с памятью казалось бы, тоже логическая (ну не подумал человек о каком-то граничном случае), так почему у нее отдельный класс? Потому что работа с прямым управлением памятью требует non-local reasoning, чего не требуется ни от какой правильно задизайненной бизнес-логики. Когда в твою функцию на C на вход приходят два указателя, ты не имеешь ни малейшего понятия ни сколько память по этим указателям проживет, ни кто и когда ее освободит, ни являются ли они алиасами (не указывают ли на одну и ту же память) - делать рациональные суждения о такой программе, не удерживая в голове весь контекст всего кода сразу невозможно, и при этом еще и не сделать ни одной ошибки в цепочке суждений. И даже никакая современная нейронка, какой бы у нее огромный context window и reasoning у нее ни был, на это не способна, потому что она оперирует вероятностями, а здесь нужен формальный анализ. А полный формальный анализ большой программы либо вычислительно невероятно дорог, либо вовсе в некоторых случаях невозможен (halting problem).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

184. Сообщение от Аноним (183), 01-Июн-26, 11:04	–1 +/–
Да где вы все это читаете? Rust ломает обратную совместимость только в одном случае - для исправления некорректности (unsoundness) safe-контрактов (например, если обнаруживается баг в borrow checker). И такие штуки случались в основном на очень ранних этапах раста и затрагивали два с половиной землекопа. И в общем-то, если вы обновили компилятор и он перестал собирать ваш код, потому что в нем UB, которое старый компилятор раньше не замечал - это хорошо, а не плохо. В остальном у раста есть механизм editions. Каждый следующий edition вносит обратно несовместимые изменения с предыдущим, чтобы держать контракт языка чистым и ортогональным (тут махаем ручкой комитету стандартизации C++). Каждый крейт на расте должен быть написан в одной конкретной редакции. Компилятор гарантирует, что будет поддерживать все редакции до скончания времен и что код всех редакций будет линковаться между собой (т.е. у вас может быть код в редакции 2024 с зависимостью в редакции 2015). Так что и через три года, и через 10 лет ваш код на расте соберется как миленький со свистом, за исключением случая, если в нем было UB, которое Rust раньше не замечал, но для этого вам должно было сильно не повезти и это не будет глобальной проблемой, а будет решаться через несколько минимальных локальных изменений в старом коде. Проверяйте, пожалуйста, информацию, которой тут делитесь. Коментаторы на opennet уже придумали свой отчужденный от реальности коллективный миф соломенного Rust-а, делясь друг с другом своими идеями и гипотезами о том, как им кажется, он работает (при этом ни разу не делая сноски для других, что это они только что нафантазировали, но выражая свои фантазии, словно это факты с достоверными источниками), вместо того, чтобы почитать документацию внимательно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

185. Сообщение от Совершенно другой аноним (?), 01-Июн-26, 11:11	+/–
Там текст "немного по дебильному написан" (с) Идёт подмена понятий, попробовали новый язык Rust, но фразу сформулировали, почему-то не новый язык Rust не имеет преимуществ, а старый C. Странная формулировка, не находите.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

186. Сообщение от Аноним (186), 01-Июн-26, 11:14	+/–
практика показывает, что это жутко нечитабельный и тормозной оверхед. и ты забыл указать тонну бла-бла-бла поверх процитированного кода, чтобы оно вообще начало собираться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168 Ответы: #198

187. Сообщение от Аноним (186), 01-Июн-26, 11:15	+/–
ну я тоже могу сишный рантайм обрезать в 15 раз, станет 4200. это что-то для тебя изменит, или ты и бальше будешь рекламировать свой недоязык, но уже другими аргументами?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

188. Сообщение от Аноним (186), 01-Июн-26, 11:34	+/–
Как же растовики врать любят. Что ни слово, то вранье.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

189. Сообщение от Аноним (186), 01-Июн-26, 11:36    Скрыто ботом-модератором	+/–
Что, растишечка, не вышло обмануть сообщество? Думал все такие же тугие как растокоммьюнити? Тестировали что? Раст. Значит не выявили преимуществ кого? Раста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

190. Сообщение от Аноним (186), 01-Июн-26, 11:37	+/–
Что именно safe, растик, 2+2? Тебе не хватает квалификации, чтобы "безопасно" сложить два числа?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149

191. Сообщение от Аноним (186), 01-Июн-26, 11:40    Скрыто ботом-модератором	+/–
> У меня к растаманам придирка. Что за вантузное слово "эдишн"? Другое нормальное слово не могли придумать. Где юниксовость а? Отвечаю: это совершенно типичный для растоманов ход "обмани лоха". Умное слово, которое лохи будут понимать как одно (стабильная версия), но которое на самом деле обозначает другое (тэг).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

192. Сообщение от Аноним (186), 01-Июн-26, 11:41	+/–
Его тезхис выдержал практику хотя бы тем, что ты сейчас свой коммент набрал с помощью сишного кода, а не растового.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180

193. Сообщение от Аноним (186), 01-Июн-26, 11:44    Скрыто ботом-модератором	+/–
Очередной растишка-дурачок, ничего не знающий, но все равно что-то говорящий. Rust вырос из языка OCaml.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

194. Сообщение от Аноним (186), 01-Июн-26, 11:44	+/–
OCaml
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148

195. Сообщение от Аноним (186), 01-Июн-26, 11:46	–1 +/–
Если исключить откровенную манипуляцию автора, то его комментарий читается вот так: Подавляющее большинство кода на Rust выглядит плохо читаемым и менее понятным чем любой С++, кроме "последних генераций" (имелись ввиду самые свежие правки стандарта).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172 Ответы: #196

196. Сообщение от Проходил мимо (?), 01-Июн-26, 12:15	+/–
> Если исключить откровенную манипуляцию автора, то его комментарий читается вот так: > Подавляющее большинство кода на Rust выглядит плохо читаемым и менее понятным чем > любой С++, кроме "последних генераций" (имелись ввиду самые свежие правки стандарта). Голодная кума Лиса залезла в сад; В нём винограду кисти рделись. У кумушки глаза и зубы разгорелись; А кисти сочные, как яхонты, горят; Лишь то беда, висят они высоко: Отколь и как она к ним ни зайдёт, Хоть видит око, Да зуб неймёт. Пробившись попусту час целой, Пошла и говорит с досадою: «Ну, что́ ж! На взгляд-то он хорош, Да зелен — ягодки нет зрелой: Тотчас оскомину набьешь» Иван Андреевич Крылов, 1808 год.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195

197. Сообщение от _kp (ok), 01-Июн-26, 12:29	+/–
>>всё остальное safe Вообще то, вся работа с реальными структурами, протоколами, регистрами - это в Rust всё unsafe, и подобный код в embedded преобладает. А в остальном облажаться как раз минимальные шансы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149

198. Сообщение от Проходил мимо (?), 01-Июн-26, 12:34	+/–
> практика показывает, что это жутко нечитабельный и тормозной оверхед. > и ты забыл указать тонну бла-бла-бла поверх процитированного кода, чтобы оно вообще > начало собираться. Не будет ли любезен многоуважаемый Аноним сообщить, какая именно строка из приведенного кода является "жутко нечитабельной" и "тормозным оверхедом"? Ткните пальцем пожалуйста, что именно в приведенном коде вы ниасилили? Так-то приведенный код лишь иллюстрирует минимальную разницу между синтаксисом битовых операций в Си и Rust, но мне прям стало очень интересно, где же вы тут нашли жутко нечитабельные тормоза. А еще я бы очень хотел узнать, о каких таких тоннах бла-бла-бла там идет речь? Вот знаете, прям удивили меня вот этим вот утверждением - сколько лет пишу и на Сях, и на плюсях, и на Rust - а ни разу никаких таких "тонн бла-бла-бла" чтобы скомпилировать программу мне не требовалось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема