[reynoldsbd]

I'm fortunate enough to have just landed on a new team working with embedded Rust. Here are some of my takes, in no particular order.

The language and ecosystem have come a long way in a very short time. It's easy to use safe `no_std` Rust on the stable toolchain for 98% of your code, and there are crates available for all kinds of things like memory management, register access, or even async runtimes.

Compared with C, Rust is absolutely a game changer in terms of reliability/safety/productivity. Every line of C code is a potential liability, because humans make mistakes. Having a compiler that smacks me down is invaluable; it results in a safer and more reliable program, and it helps me get it right the first time. Like many others, my experience with Rust is nearly always "if it compiles, it works". This is _especially_ valuable for embedded programming, because debugging is often way harder when working with hardware.

One major drawback is lack of support/engagement from hardware vendors. They pretty much assume you are using C, and all of their IDEs/SDKs/codegen tools/whatever are written with that assumption. This probably isn't going to change any time soon (ever?). What this means is that if you want to use Rust, you'll be on the hook for figuring out a lot of low-level things like linker scripts, boot sequence, or memory/clock initialization. Often this means reading or reverse-engineering the vendor's SDK to figure out how these work. If you're working at a big company on a serious product, you might have done this anyways. But for a hobbyist, this can be a huge barrier.

[cogman10]

> One major drawback is lack of support/engagement from hardware vendors. They pretty much assume you are using C, and all of their IDEs/SDKs/codegen tools/whatever are written with that assumption. This probably isn't going to change any time soon (ever?).

My assumption is that with the advent of rust getting into gcc, you will see at least some of these changes starting to make their way into toolchains. Probably not for the MSP430, but possibly for the next generation of embedded chips.

[P_I_Staker]

Is rust interoperable with C and ASM? I would think it'd have to be. Some of those things (all of them?) are considerations the system designer needs to worry about regardless.

It seems like you should be able to still use most of the stuff provided by the toolchain in a similar fashion. That said, trying to do a native implementation by porting the code, or just using a C/ASM bootloader could prove tricky for newcomers.

Bootloaders are often black boxes. It could be flashing something written in COBAL, and it would be none the wiser. It seems like rust would need to provide a mechanism for entry pointing. I don't know how to handle memory mapping and linker scripting in rust.

I'm not disagreeing that it could be a huge barrier, but theoretically it doesn't have to be that much, or at least most of it is stuff you'll often be dealing with anyway.

[b20000]

so what you are saying, is that rust solves the issue of finding competent engineers. you can use a language like rust such that engineers don’t need to be any good. it reminds me of microsoft frontpage and all the other scripting languages and tools that have been created to solve this issue. but here we are in 2022 and nothing has changed. people still hand code css and html to get what they want.

embedded software engineering is about understanding the hardware and leveraging its power through good architecture and smart thinking and understanding what the code you write will do. you can’t shortcut this by using a new programming language that does the work for you. you will still need to understand the low level details. so, learn C++ and familiarize yourself with the related embedded standards for reliability and safety.

adding rust into the mix will now require you to maintain code in not one but multiple languages as you cannot get around C or C++ and possibly assembly. it’s already complicated enough as it is, and you should focus on understanding the principles instead of learning another set of syntax and implicit logic.

[Thiez]

Nice gatekeeping. Perhaps you could provide some concrete examples of how Rust is worse than C++ for embedded programming, when it comes to "understanding the hardware and leveraging its power through good architecture and smart thinking and understanding what the code you write will do"?

To me it is very strange that you would act as if Rust is some dumbed down toy language (not your literal words, but I conclude this from your MS frontpage example), while it is considered (not entirely deserved, in my opinion) difficult to learn with a very steep learning curve.

Personally I find programming in C quite annoying because of all the sharp edges (e.g. implicit integer promotion, the various types of UB) that you have to keep in mind. To me this distracts from thinking about good architecture, rather than promoting it.

[crest]

I take something very different from the grand-parent post: the language requires you to get the design mostly correct to even compile. Unexperienced developers won't be able to come up any non-trivial new designs of their own, but can reuse existing code and even experienced developers have to fight the language to get a prototype stood up, but once they've working code it's more reliable. Not every line of code could accidentally reconfigure your PLL or voltage regulator just enough to drive you insane debugging a glitching chip.

[reynoldsbd]

> rust solves the issue of finding competent engineers

That's a very cynical take, but I think there's a kernel of truth in there somewhere. Rust does indeed make it much harder for less experienced programmers to make certain classes of mistakes. Why on earth would that be a bad thing?

> you can't shortcut this by...

"Using Rust" and "understanding the hardware"/"good architecture" are not mutually exclusive, and Rust is not a shortcut. Embedded programming is still very hard. In some ways, Rust can make it even more difficult by forcing your code and architecture to follow additional rules.

> cannot get around C or C++

Speaking from experience, this is false. It's perfectly possible to write embedded applications using only Rust and assembly, without a single line of C/C++. I do it every day.

[adolph]

> so what you are saying, is that rust solves the issue of finding competent engineers.

It’ll be a depressing time when the demand for engineering is lower than supply. Until then people with needs larger than resources will find alternatives to “finding competent engineers.”

That said, Espressif seems to be moving past pure embedded and positioning themselves in IoT, for example the latter part of ESP-IDF stands for IoT Dev Framework. This allows them to provide a single way of doing things regardless of implementation within the broad ESP32 family.

Will the results be the equivalent of Frontpage websites? Sure, and as any of those start getting the resources to need and use “competent engineers” they will unlike the efforts that would never have gotten off the ground.

[cogman10]

I don't think that's what GP was saying at all.

The issue they bring up in more that hardware manufactures will have things like

    #define BLINKY_LIGHT_ADDR 0xDEADBEEF

in a standard set of headers distributed with their toolkit. That magic address is where you write to turn a light on or off.

Now, they will almost certainly also define that sort of thing in a datasheet, somewhere, but for the average embedded dev it's far simpler to pull in the SDK and use that.

This isn't some sort of "good programmer bad programmer" filter. This is a "I don't want to read a 40 page pdf of a datasheet to find out what you named light 1 and where that address is"

[bsder]

It's worse than that.

Something like your Bluetooth communication is dependent upon a C-based "communications stack" that demands to control the event loop and all the registers aren't even documented.

"Where is the LED?" is easy to work around. "How do I put my BLE system into low power advertising mode?" may not even be possible without accessing the C library.

[steveklabnik]

That’s a fun example, because while you’re right, that may also be changing. Android’s new Bluetooth stack is in Rust, in my understanding. We’ll see if more vendors provide even more stuff in Rust in the future!

[cogman10]

Ah, good point. That would be rather tricky to solve.

[felipellrocha]

Lol. Talk about straw man argument.

[solumunus]

One of the dumbest posts I've ever read on here.