Давай я, прежде чем продолжать дискуссию, уточню один момент. Я на самом деле не знаю, насколько rust полезен для embed'а. Я уверен, что полезен, но вот насколько -- не знаю. Пока у меня есть только одна программка на расте под мк, которая мигает светодиодом, я не могу увидеть общей картинки. На самом деле, я полез совать раст в микроконтроллер для того, чтобы освоить раст на том же уровне, на котором я освоил C: высокоуровневый ЯП нужен для генерации ассемблерного кода, и если мне очевидно какой ассемблерный код будет генерироваться из того или иного куска C'шного кода, то что получится из куска кода на rust'е, я не всегда знаю. Но на x86_64 это в большинстве случаев не столь важно, и поэтому скучно ковырять ассемблерные дампы, а вот при решении embedded задач придётся разбираться и это будет гораздо веселее. Я уже успел столкнуться с неожиданными оптимизациями, когда llvm вдруг решил, что вывод в порты ввода/вывода и delay на циклах -- это вещи, которые можно переупорядочить, то есть сначала вывести всё, а потом отработать все задержки. Но меня в основном больше интересует другое -- как компилируется передача значений в функции, в зависимости от const/mut модификаторов и в зависимости от стратегии передачи move/copy. И с учётом этого, как лучше проектировать API -- когда передавать по значению, когда ссылкой, когда вешать на тип трейт Copy, а когда лучше оставить его жить в move стратегии.Короче, я это к тому, что на данный момент, все мои соображения о полезности rust'а в восьмибитном микроконтроллере сугубо умозрительны, и у меня нет конкретных примеров использования тех или иных фичей языка. Но, если тебе хочется поспорить, мы тем не менее можем это сделать.
Давай попробуем.
Твоя аргументация сводится к тому, что а) "мы всегда так делали" и б) "яп -- не серебряная пуля". Но видишь в чём фишка, ты ведь знаешь, что если ты будешь ждать серебряной пули, то ты никогда не дождёшься, потому что серебряной пули не существует и быть не может. При этом "мы всегда так делали" в современном мире -- это путь в небытие. То есть в прошлом было то же самое, но там этот путь был дольше и мог растянутся на несколько поколений. Если ты хочешь чтобы твои знания и навыки оставались актуальными, или ещё лучше становились бы более ценными, то тебе надо непрерывно учиться. Если ты не учишься, то через десять лет ты будешь старпёром, который хорошо умеет выполнять два технологических действия и ни на что больше не годен. Если тебе повезёт уметь выполнять такие технологические действия, которые будут востребованы до конца твоей жизни, то будут неплохие шансы оставаться трудоустроенным до тех пор, пока ты не умрёшь от скуки выполняя десятилетиями одни и те же технологические действия. Если не повезёт, пойдёшь работать дворником.
> Лично я предпочитаю проявлять внимательность что и почему я делаю в коде. Для меня это работает. И объяснить себе проще и быстрее чем компилятору. И если бы я был хронически не способен написать несколько строк без ошибок, стал бы с горя вебмакакой, там не так важно.
Вот это вот как раз установка "меня всё устраивает, менять что-либо я не собираюсь". Не любое изменение -- это улучшение, но любое улучшение -- это изменение. Если ты хочешь стать лучше, то тебе надо меняться. У твоей внимательности есть границы, у твоих интеллектуальных возможностей тоже есть границы (они у всех есть). Ты можешь оставаться в этих границах, и отказываться от задач требующих выхода за них, либо ты можешь развиваться и учиться работать в областях, где не хватает интеллектуальных возможностей.
> Я могу с наскока написать программу на чем угодно, которая скомпилируется но работать (с точки зрения ведения осмысленной активности) не будет.
Это не аргумент нисколько. Если программист нацеленно пишет нерабочую программу, то мне совершенно неинтересен этот случай. Всё же мы рассуждаем о программмисте, который хочет написать рабочую программу, и более того, прилагает к этому всякие разные усилия: пишет код; думает о том, что пишет; он думает о ещё ненаписанной программе в целом, что позволяет ему сделать код более логичным; он придумывает всякие там CodingStyle, которые позволяют избегать каких-то классов ошибок; он находит свои собственные индивидуальные правила написания кода, которые позволяют ему не совершать тех ошибок, которые он часто совершает. И мы говорим, всё же, о таком программисте, а не о том, который назло мамке пишет нерабочую программу.
А если мы говорим о таком программисте, то... Я фактически забыл про дебаггер, работая с rust'ом в прикладном программировании. Дебаггер не нужен, потому что все ошибки типа "я вносил десяток изменений в разных частях кода, и в процессе забыл про одно из них" теперь приводят к ошибкам компиляции. Более того, у меня входит в привычку, потерявшись в пространстве, забыв о том на каком этапе внесения изменений я нахожусь, запускать процесс компиляции и разглядывать ошибки -- это напоминает. И это стратегия, которая плохо работает в C, и почти совсем не работает в асме.
Правда, надо отметить, что при прикладном программировании, есть ещё паники и бектрейсы, которые тоже вносят свой вклад, который мне сложно пока оценить. На мк begin_panic -- это вечный цикл, ничего более осмысленного в голову пока не приходит, так что у меня будет возможность оценить насколько важную роль играют эти паники и бектрейсы в процессе разработки.
> Раскрывается извините основной перк программиста. Он или делает это правильно и понимает с чем имеет дело. Или наслаждается абы каким трэшом. Ну как, если ты например под работающим процом попробуешь тактирование передернуть или с выбором режима DVFS лоханешься, загнав камень за предел гарантированной стабильности, что будет дальше - unspecified, вообще независимо от ЯП. Запиши в регистр baud rate uart'а неверное значение - и останешься без коммуникаций. Независимо от ЯП. И такое везде.
Основной перк программиста -- это автоматизация всего, что можно автоматизировать, и кое-чего из того, что нельзя. Rust имеет расширенные возможности по детекции ошибок на этапе компиляции, а значит сам бог велел попытаться дотянуться этими возможностями до всего вообще. Ну, например, ты упоминаешь регистр baud rate, почему бы не создать глобальный объект нулевого размера, дать ему доступ к этому регистру, не давать никому другому туда доступа. Затем к этому объекту приделать ровно один pub метод set_baud_rate, который будет проверять входное значение на попадание в заданные границы. Метод естественно сделать inline, с тем чтобы у llvm была бы возможность выполнить проверки в compile-time, выкинув их из рантайма. Это, конечно же, больше геморроя, чем написать одну ассемблерную инструкцию, но написать set_baud_rate не сложнее, а рассуждать о коде будет проще -- в случае, если uart не работает, я легко смогу отмести гипотезу о том, что выставлена неверная скорость передачи.
Это можно сделать и на C без создания объекта, а тупо inline функцией, но объект (пускай и нулевого размера) -- это уже, как бы, память, а этом значит что все перки rust'а по контролю за памятью, оказываются применимы к этому объекту. Мне сложно сказать, как это можно использовать применительно к регистру контролирующему скорость уарта -- зачем может понадобиться mutable/immutable доступ, контроль реентерабельности и прочие перки. Но, я говорю, я не готов пока приводить конкретные и реальные примеры.
Тебе не приходилось читать о верификации кода? Если нет, то почитай обязательно: даже если тебе неинтересна верификация в смысле создания математических доказательств валидности кода, такое чтиво может развить твои способности думать о коде. Внимание от этого не станет устойчивее или шире, но вот способность осмыслять сложный код станет сильнее. Из последнего на что я натыкался: http://www.pathsensitive.com/2018/01/the-three-levels-of-sof...
В частности вывод оттуда: если ты пишешь код под мкк так, чтобы он работал и на другом мкк, то твой код становится надёжнее.
> А у меня прямща есть нормальный девборд + пара прототипов запиленых ЛУТом. Без макеток - нарисовал в KiCAD, распечатал и протравил. Так прикольнее. При желании маску могу запилить, чтобы совсем как с фабы, но для ранних прототипов это пижонство.
ЛУТом?! Ох да нифигажсебе! Круто!
А я всё через дырку, так проще припаять/отпаять, что-то добавить или убрать. А вообще, думаю, купить макетку, которую не надо паять. А то тут на макетке периодически такая путаница из проводов случается из-за неверных исходных посылок, а перепаивать влом. Если же просто перетыкивать, то может быть реже придётся тонуть в соединениях.
