I've been in the embedded space for over 10 years so I figure I'll give my thoughts on the matter. Apologies up front as this will be a little ranty. > Embedde

I've been in the embedded space for over 10 years so I figure I'll give my thoughts on the matter. Apologies up front as this will be a little ranty. > Embedded developers are very conservative, they don't chase the shiny and believe in using old tried and true technology. This is underselling the point. They are conservative in the same sense as an electrical engineer who refuses to use ECAD software or transistors because drafting tables and vacuum tubes are tried and true. There's a difference between "[not] chas[ing] the shiny" and just being obstinate. > With C you have a HAL provided by a vendor that allows very rapid bring up of the hardware which is 90% of the battle in embedded. Switching to Rust you would have to write your own. I'm not sure why vendor supplied HALs - which can be pretty hit or miss in terms of quality - are so important for board bring-up. In the end it's a minor milestone in the development lifecycle for all but the simplest of projects. In the projects I work on practically all of the time is spent on the complexity of the firmware and how it interacts with the various networks of sensors, actuators, cellular, BLE, storage, etc. Besides, last I checked there were many people putting effort into HALs written in Rust. > With C you have billions of lines C libraries at your disposal to bring your product to market. To use Rust you would have to write your own or deal with the shims and lose the Rust benefits. First off it has not been my experience that libraries are used often. As you mention later FreeRTOS is generally the only external code I see pulled into a project, everything else is written from scratch or copy pasted from a previous project which was written from scratch or copy pasted from a previous previous project etc. Let's assume that libraries are commonly used though, how exactly do you use them? This is one point of C/C++ that is still absolutely dire. Rust has Cargo whereas C/C++ has a lot of wacky ways to deal with it such as through git submodules, or cmake, or possibly conan. Generally speaking what I see is the code being copy pasted into the project and never updated despite the growing security concerns for connected embedded devices. Of course Rust offers more than mere package management, Cargo is also the build system, it also has support for automated testing and documentation. All of these things are typically afterthoughts at best in many embedded projects. > I do 4-5 embedded projects a year, using Rust and not having the HAL and C library ecosystem would put those projects ad a competitive disadvantage. To be clear at this point in time if I were asked if an embedded project should be written in Rust my answer would be "probably not", although given 5-10 years that answer very well may change to the affirmative. The ecosystem is young and growing; as long as the growth continues it will likely be a viable alternative in the future.