> Хорошо, не вопрос.
> История тут такова была. Было сказано что на расте программируют контроллеры, я
> попросил показать контроллер который программируют на расте. Не оказалось.Тогда я вынужден признать, что я не понимаю вопроса. Что значит "контроллер, который программируют на расте"? Контроллер, который не программируют на C/C++? Контроллер, который чаще программируют на rust'е, чем на C/C++? Контроллер, который кто-то хотя бы раз программировал на rust'е?
> Я не мега знаток раста, так чуть ковырял, на хорошо в C/C++.
> Rust как позиционируют? Безопасная работа с памятью мол киллер фича. Так
> вот эта киллер фича в подобных контроллерах не нужна от слова
> совсем.
> В таких контроллера нет работы с динамической памятью от слова совсем.
Безопасность работы с памятью, о которой говорит раст -- это больше, чем просто RAII. Это гарантии отсутствия data race, причём тут речь идёт не только о конкурентности, речь идёт и о реентерабельности. Динамической памяти может и нет, но разве нет и стека? Стек -- это ведь тоже динамическое выделение памяти, пускай и в ограниченном виде, и даже работа со стеком исключительно может порождать и null-указатели, и dangling-указатели. Работа с вводом-выводом? Она тоже ведь легко заворачивается в растовые абстракции, и может быть даже на уровне машинного кода выглядит как работа с памятью.
На деле я с ембеддщиной общаюсь изредка и чисто по фану, но если интересны впечатления профессионала, который стал профессионалом на поле встройки, пользуясь C, а потом попробовал притащить туда rust, и пришёл в восторг, то вот ссылки:
https://www.ecorax.net/as-above-so-below-1/
https://www.ecorax.net/as-above-so-below-2/
> Зато в расте насколько мне известно нет аналога шаблонам. Т.е. абстракции уровня
> компиляции. То что мне в одном месте пытались впихнуть как аналог
> на деле оказалось недоделано и скудно по возможностям.
Да, растовые дженерики слабее C++. Но есть два нюанса:
1. самый раздражающий меня провал в функциональности дженериков исправили как раз в этом релизе: теперь можно использовать константу в качестве параметра
2. есть макросы -- это не C'шные укуренные макросы, это полноценный макроязык, который заточен на работу с синтаксисом rust'а. Их вполне можно использовать, в отличие от C'шных. То есть, как и с любыми макросами в любом языке, всё же не стоит их использовать без особой нужды, но они позволяют творить очень много чего. На самом деле больше, чем любые шаблоны. В стандартной библиотеке есть немало примеров тому. Взять тот же println!, который вроде как аналог C'шного printf, но он не функция с эллипсисом, он макрос, который парсит форматную строку на этапе компиляции, там же проверяет типы остальных аргументов на соответствие этой форматной строке, и генерит код вывода, согласно форматной строке. Или всякие разные трейты для слайсов разной длины: сейчас вот добавили возможность сделать это без макросов, но это было сделано на макросах, которые генерировали имплементации трейтов для типов [T; N] (в терминах C -- массив длины N с элементом типа T), где T -- это параметризованный тип, а N -- это числа от 1 до 32. В diesel подобное было проделано для таблиц бд с разным количеством полей в записи. На макросах, блин, генераторы парсеров пилят, которые читают файл с описанием грамматики, и генерят код разбора этой грамматики. То есть макросы, по своим возможностям, не хуже лисповских, но чем-то лучше, потому что не в лисповском синтаксисе, который в случае макросов `(погружается ,$в$ 'шизофрению).
> Ну и конечно куча кода уже готова, его никто не будет переписывать потому что от этого не получишь ну вообще никакого выигрыша.
А это вовсе и не нужно, как показывает история. Вон с Cobol'а тоже никто не переписывал. И тем не менее бизнес переехал на Java с Cobol'а. С Fortran'а пытались переписать, чёт как-то не вышло, но и где сегодня фортран? Примерно там же, где и кобол.
