Comments 24
Иметь возможность комфортно писать на строготипизированном языке для микроконтроллеров - это очень круто.
Единственное, мне не понятно, почему они не сделали ручное управлени GC, чтобы программист мог запускать сборку мусора тогда, когда для этого есть свободное время (чтобы не сбивать тайминги при общении с внешним миром).
Возможно в будущем появится ручное управление GC, скорее всего данные методы пока не в приоритете добавления. Программирование под МК в основном подразумевает статические переменные, которые "живут" на протяжение всей работы программы.
Иметь возможность комфортно писать на строготипизированном языке для микроконтроллеров - это очень круто.
Предлагаю ознакомиться с Rust. Очень строгая система типов и проверок, работа на куче платформ (от WASM до микроконтроллеров), отсутствие как GC (что позволяет писать среды реального времени), так и необходимости вручную освобождать память (что нередко вызывает ошибки)
И просто огромное количество опционального сахара и zero-cost abstractions, благодаря чему писать приятно, а на выходе получается производительность на уровне С++
Rust все же достаточно низкоуровневый язык, отсутствуют классы и нет систем наследования, по сравнению с C#. И порог вхождения существенно выше.
Это принципиальная позиция, композиция вместо наследования, т.к. оно нередко приводит к ошибкам. При необходимости это наследование эмулируется с помощью дженериков и трейтов
Про низкоуровневость не согласен. Если не хочется, то и не надо на низкий уровень опускаться. Посмотрите бэкенд на том же Actix и найдите 10 отличий от Express (кроме того, что Actix быстрее примерно в 10 раз). Это универсальный язык
Про порог входа тоже не согласен. Язык гораздо чаще не дает совершать ошибок, куча сахара и тд. Если специально на низкий уровень не опускаться и в unsafe не лазать, то почти всё привычно. Только привыкнуть к системе владения и ссылкам (и то, владение есть в Свифте, а ссылки в неявном виде есть много где, взять ту же Джаву).
Зато в награду паранойидальный, но очень умный и приятный компилятор, гарантирующий отсутствие утечек памяти, рейс кондишенов и тд без продажи души демонам
А в шарпе я навскидку вот вспомню супернеочевидный как для новичка, так и для свитчера кейс, когда перестановка 2 множителей в выражении роняет перфоманс в 20 раз (что вообще противоречит математике и логике)
А как в Rust работать с прерываниями?
Можно ли использовать async/await?
Есть ли generic типы?
А как в Rust работать с прерываниями?
Вот целый блог по созданию ОС на Rust: https://os.phil-opp.com/
Вот статья про прерывания в части официальной документации языка, посвященной embedded разработке: https://docs.rust-embedded.org/book/start/interrupts.html
Можно ли использовать async/await?
Да. Причем не только в полноценных функциях, можно даже делать async лямбды
И полноценные потоки тоже никто не отбирает. При этом есть много проверок на отсутствие гонок и прочего, что делает многопоток сильно менее болезненным
Есть ли generic типы?
Тоже да. Причем, в отличие от темплейтов С++, компилятор не верит на слово и требует гарантий наличия нужных методов в дженерик типе.
Подробнее можно посмотреть в официальной документации: https://doc.rust-lang.org/book/ch10-01-syntax.html
Отдельно стоит упомянуть тот факт, что Rust построен на платформе LLVM, а значит совместим с С++. Т.е. Rust можно вызывать из C++ и наоборот.
Кроме того, многое, ради чего в других языках нужно искать библиотеки, тут есть из коробки. Например, условное добавление кода на этапе компиляции, генерация тестов по документации, просмотр документации по всем зависимостям проекта локально в браузере с навигацией и поиском, и тд
Многие корпорации (Amazon, Discord, Dropbox, Jetbrains, Microsoft, Mozilla) начали переписывать старые или разрабатывать новые проекты на этом языке, что меня очень радует. Хорошие инструменты должны популяризироваться.
Вообще на всяких конференциях, посвященным микроконтроллерам и разработке под них, Rust уже тоже частый гость. Там на нем пишут под всё на свете, от STM32 до всякой экзотики
Я формально работаю на Java, но фактически использую Java, Typescript, Kotlin. Ранее писал на С++. Сам на Rust наткнулся не так давно и просто влюбился в язык. Уже один пет на нём начал и один планирую. Первый на моей памяти такой, соединил всё лучшее из С++, Java и Python. Удобен, быстр, безопасен, позволяет писать как на высоком, так и на низком уровне. Как прикладные программы, так и системщину. И ни в одном из перечисленных применений нет ощущений, что натягиваешь сову на глобус
Если Rust наберет популярность для embedded устройств, то это будет замечательно, все будут только в плюсе. Под разные задачи разработчик сможет выбрать наиболее для него подходящий инструмент. Применительно Rust к .NET nanoFramework, на Rust для .NET можно писать низкоуровневый неуправляемый код, т.е. нижний слой. И не забываем про критику Торвальдса.
Торвальдс критикует всё, что не чистый Си. И то, разговоры о добавлении Rust в линь увенчались далеко не громким отказом (в отличие от того же С++)
Если Rust наберет популярность для embedded устройств, то это будет замечательно, все будут только в плюсе.
Так вроде уже. Не Си конечно по популярности, но никто и не претендовал. Библиотеки под всё самое используемое есть давно, статьи, на конференциях эмбеддщиков на нём кодят и тд
Применительно Rust к .NET nanoFramework, на Rust для .NET можно писать низкоуровневый неуправляемый код, т.е. нижний слой
Я не знаю, зачем такого монстра создавать. Почему бы просто не писать на Rust под голое железо? Pico же просто Cortex M, Rust в него давно уже умеет
Ну и у Rust есть имхо киллер-фича, которая ставит его на голову выше конкурентов в первую очередь в embedded мире. Паники, они же фатальные ошибки. А точнее то, как они реализованы. Rust в рантайме отслеживает все возможные критические ситуации. Паники срабатывают до критической ошибки, вызывая раскрутку стэка и прочее. Т.е., например, при вылете за границы массива, на Rust мы поймаем панику, но память не будет повреждена, т.к. он её выбросил до того, как ушел реальный вызов. А в embedded Rust мы при этом пишем глобальный обработчик паник (или пользуемся готовым, коих полно) и всё. Или уходим в бесконечный цикл, или логгируем падение, или еще что. Но самое главное, что наша ошибка не повлияла ни на что, кроме хода выполнения программы (включая память). А ведь есть среды, где менеджера памяти, а значит и защит, просто нет. И там только Rust сможет вам дать по рукам и спасти от ее порчи
Так вроде уже. Не Си конечно по популярности, но никто и не претендовал. Библиотеки под всё самое используемое есть давно, статьи, на конференциях эмбеддщиков на нём кодят и тд
Тогда ждем посты про Rust на embedded устройствах ;)
Да вроде уже, пусть и корявенькие)
Маловато будет. Я так понял в отличие от .NET nanoFramework на Rust Embedded отсутствует интерактивная отладка во время исполнения приложения, чтобы полностью стек просматривать?
Так это только два примера статей. Я ж не буду весь хабр перекапывать, плюс есть сторонние источники
Я так понял в отличие от .NET nanoFramework на Rust Embedded отсутствует интерактивная отладка во время исполнения приложения,
Присутствует, и даже несколькими способами. Просмотр стека, кучи, регистров, бэктрейса во время отладки. И тд
Не нужно путать теплое с мягким. Как я понял, дотнету обязательно нужна операционка для работы. Но если у нас есть операционка, то можно писать и на обычном полноценном Rust. А Embedded нужен для bare metal сред, когда мы пишем напрямую под железо, без какой-либо операционки или среды исполнения, только прошивка и программатор
UPD: погуглил, похоже дотнет тоже может на bare metal работать, но поддерживает меньше платформ, чем Rust (например FPGA от Xilinx). Просто по вашей статье сложилось впечатление, что он без позикса не живет. Ну в таком случае сравнение корректно, но я все равно считаю, что и сам язык удобнее и безопаснее, и отсутствие GC много где критично (= любое реальное время)
В первой части об этом идет речь, только не сделал четкое разделение реализации на bare metal и ОС.
Эталонная реализация .NET nanoFramework работает поверх ChibiOS, например для STM32. Но для ESP32 сделано исключение, и работает непосредственно на железе без ОС.
Для работы .NET на FPGA, тоже на Xilinx, есть один интересный проект .NET TO FPGA WITH HASTLAYER.
Ну тогда согласен, что это достойное решение для фанатов C#. По сути из реальных минусов только GC, наличие которого ставит крест на RT-окружении. Ну и работа поверх ОС тоже урезает доступные ресурсы и прочее. На той же STM32 Rust работает bare metal, как и на других embedded платформах (но при желании никто не мешает и поверх ОС запустить, тогда даже std будет)
Но я в целом шарп не люблю, как и Майкрософт, поэтому не для меня)
.NET вообще не позиционируется как решение для RT. Для меня .NET nanoFramework, это возможность создавать несложные бытовые устройства с минимальными затратами, например умная бытовая техника, сельское хозяйство, мониторинг. Если разработчик знает "большой" .NET, то ему минимум потребуется времени для перехода на nF, плюс к этому будет возможность переноса программного кода. А а люблю платформу .NET)
Ну я не спорю, что нормальная возможность. Но имхо на том же Rust это будет не сложнее, а профита и возможностей больше (а может просто у меня уже профдеформация из-за того, что пишу на нескольких языках)
К слову, код Rust тоже кроссплатформерный. В смысле один компилятор, есть кросс-компиляция и нет undefined behavior, т.е. можно гарантировать переносимость кода (если он конечно не использует системные апи или конкретное железо, но это и так очевидно)
Но для ESP32 сделано исключение, и работает непосредственно на железе без ОС.
Ага, там он работает над FreeRTOS...
которые действительно обходимыми для проекта
Одним из главный принципов NuttX
С списке устройств
Pi Pico удовлетворяет этим требования
По факту так таковой перенос, как переписывание уровня HAL
и т. п.Про запятые и стилистику даже не упоминаю.
С точки зрения приличия можно было ограничиться личным сообщением
При всем уважении к Вам, я очень отрицательно отношусь к навязыванию своих услуг, то что Вы делаете. Если я не согласился на "выгодных для вас условиях", которые между прочим Вы не огласили, то на это были свои причины. Если Вы так принципиальны, все же огласите свои расценки. Да, очепятки необходимо вычищать до публикации поста, спору нет, но с ваших слов я прям специально пишу для аудитории "безграмотными публикациями". И запомните на будущее, кормят детей, а авторы пишут как и художники.
Третью статью подряд Вы не вычищаете опечатки до публикации. Поэтому, да, получается, что Вы делаете это специально.
Свои расценки на корректуру я Вам уже назвал — любые, которые Вас устраивают.
Писать (без)грамотные статьи — Ваше право. А право читателей, включая меня, ставить им плюс, минус, или не ставить ничего вообще.
Ни в коем случае не навязываю своих услуг, лишь напоминаю, что моё предложение о помощи с корректурой пока в силе.
Запускаем .NET nanoFramework на Raspberry Pi Pico