Guessing Game на STM32 c использованием Rust

[AllFiction]

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

через год мена заинтересовали тем, что на расте пишут под esp32 (и всем советуют) и я таки попробовал вкатится хотя-бы чисто ради МК. В итоге оказалось что мне и на си вполне норм. Синтаксис - в целом как я и ожидал, нет того "упрощения" как в Го, зато есть куча чисто локальных особенностей и общая стилистика как будто созданная инопланетянами, у меня прям вайбы первых сайтов написанных с jqwery были. Но самая большая проблема, которая оттолкнула это то что раст зависит от библиотек. В го все есть код и подключить что либо можно, но по умолчанию считается что все должно быть компилируемо прям в рамках самого языка. В расте же ты как в старые добрые времена зависишь от сторонних dll и без них даже не скомпилируется. Причем это проблема настолько всеобъемлюща, что даже что то постое консольное требует библиотек (в го необходимость внешнего вылазит редко, графические интерфейсы, нетиповые ядра и тд), а про МК я вообще молчу - как в процессе оказалось, что бы создать скетч под ESP32 который будет нормально собираться и шиться, как под линуксом так и под виндой с маком мне надо или спецом прописывать все или сложить рядом с исходниками нужные бинарные либы.

вообщем все то же самое что и было на си, только другой синтаксис и совершенно иной срок использования. если по си можно твою проблему в будущем нагуглить, то вот с растом вряд ли.
Не понимаю как раст сравнивают с Го по простоте, ведь даже тот же кривейший tinygo который с esp32 очень относительно работает, на нем я могу сделать скетч который будет шиться у всех и не потребует каких-то особых танцев по итогу. главное даже в паплайне будет собираться без проблем.

За STM не подскажу, не пробовал его с растом ковырять, но учитывая что в 99% случаев ты все равно работаешь через обертку (hal) а прочие танцы с кубиками и тд все равно в итоге надо настраивать конкретно на каждой платформе - если не ардуино а серьезно, то раст будет неплохим выбором. лишь бы проблем с либами не было, хотя опять таки с STM очень часто приходилось "руками доводить" потому скорее всего детерминированность пакетов раста будет прям шагом вперед при работе с камнями STM

[Newpson]

как в старые добрые времена зависишь от сторонних dll и без них даже не скомпилируется

сложить рядом с исходниками нужные бинарные либы

можете, пожалуйста, прояснить этот момент? Я, конечно, пока ненастоящий растовчанин, но статическая линковка Rust сейчас является его и плюсом (всё своё ношу с собой) и минусом (бинари довольно крупные получаются) одновременно, а все crates собираются по месту из исходников. То есть, испытал абсолютно противоположный вашему опыт.

[Jijiki]

раст не потипу плюсов, как говорится изучайте матчасть, у раста если следовать его логике, всё гораздо удобнее чем в сравнении с С/С++, удобные каналы mpsс, далее, большой проект раста читается проще, если сразу при написании, при использовании удобств раста сразу размечать удобные секции, да кода будет много, но рамки-границы будут выражены всё еще, и самое интересное грязи будет по-меньше чем в С или в С++. там есть много удобств, которые чисто в коде прям проще видятся и выявляются восприятием, в его семантике кстати!, чем в С/С++ восприятие и грязь

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

у раста удобные структуры, имплементации более выражены, работа с модулями удобная, нет той возни как в С/С++, derive намного удобнее опций или пойди пойми где у вас какие конструкторы и что они должны делать, далее, нет возни с cmake/conan/ice, конструкции языка более явные - это приводит к тому, что структура кода более вырожена на логику, к сожалению в расте одни только +, минусов я не заметил, я тоже сначала не доверял расту, но после диспетчинга на С, и некоторых попыток С++, переход на раст стал очевиднее, пускай я не експерт и от идиоматики хаскель/раст я пока далёк, но такой подход даже радует, чем С/С++...

упд: владение, бороу чекер ), семантика мув - это настоящий прорыв сегодня, вдруг оказалось что она необходима, а не на откуп человека (типо сиди думай чо делать дальше, где там семантика мув вообще должна быть)

если быть кароче, мои итоги, раст это что-то крутое из мира хаскельфорт, некое переосмысление, и оно о чудо реально клёвое )

[Weselton]

Сколько же неправды вы написали )
0) Rust или Go - вкусовщина (и не только). У го порог входа может быть ниже, но когда (вдруг) приходится что-то оптимизировать или делать что-то более сложное, оказывается что "простота" (я бы сказал "кастрированность") языка начинает совать палки в колеса. И тут начинается генерация костылей за костылями. Да и с безопасностью (отсутствие null safety или гонки в многопоточке, к пример) в Go сильно хуже, прям отвратительно, 10 шагов назад. Я много прогал на Го и кайфа не получал. Имхо

1) "эльфийский по типу плюсов" - не знаете, что пишете ) Плюсы в разы сложнее и огромней. Раст - скорее Си 21 века

2) Раст без сторонних крейтов зависим только от системных библиотек операционной системы (если собирать с помощью musl, то и от этих зависимостей получится избавиться). Среди крейтов сторонних есть те, которые зависят от сторонних либ в системе (openssl, например), но это исключение из правил и встречается крайне редко. Но такое и на go бывает (sqlite). Подход, как и у Go - статика по умолчанию. Тот же crate для разработки под esp32 от espressif около года или типа того не зависит от сторонних сишных либ.

[Andrey_Brodobrey]

Звучит все это круто. Rust действительно выглядит, как свежий глоток воздуха в STM. Правда я не понимаю, где, работая с СТМ, можно полноценно развернуть возможности раста. Мое взаимодействие с стм, чаще упирается в работу с регистрами и описании логики считывания с датчиков, там и Си/++ особо не развернешь.
Играясь с дисплеями, наверное - да, можно и на Расте. Но это очень узкое применение. Там, в сущности, и на питоне можно, и не плохо выходит.
Как по мне Си и Плюсы плотно заняли эту нишу, полноценно их в МК уже не заменить. Максимум только отдельные библиотеки на иных языках под конкретную периферию.