reynoldsbd

I’ve found that good logging/tracing discipline can play an important role here. For example, my team has a guideline to put a debug! message before blocks of code that are likely to fail. Then if something goes wrong, we can dial up the logging level and zero in on the problem fairly efficiently. With this model, we don’t find the need to use any third party error framework at all.

In the abstract, we are basically treating the error as a “separate thing” from the context in which it occurred. Both are of course strongly related, however the way some of these error libraries try to squash the concepts together can be quite opinionated and doesn’t always facilitate smooth interop.

Not saying this is the only way to deal with errors, but it’s just one way of thinking of the problem that I’ve had pretty good success with.

Current MS employee here. For a time this was true, but FF recently added this integration. No about:config needed, there’s simply a checkbox under the FF security settings. Since this was added, I have gone back to using FF as my daily driver, and I haven’t really encountered any other friction.

> 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.

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.

My experience in a big metro area has been that almost every Uber driver does this full-time, and their vehicle is for the sole purpose of Uber. I guess it depends on where you are.

Counterexample: comedy central now has to work to redact all noncompliant programming.

Best practices are funny because context and history are important. Actual regulation is not so forgiving.

This is incredibly false. When you change the law, you can't assume that people who are currently in compliance will continue to be.

"We could have done it this way." doesn't pay the bills (or in this case, doesn't prevent steep fines).