Ferrous Systems Blog

Some thoughts...
1. There is no tech stack in the world you can safely deploy and forget about for months or years. Security updates are needed, OS updates cause changes, browser technology changes, and your users change. Even setting aside security, let's say you build something that becomes popular, you've no IC lock-in, and you don't add features / adapt. Sooner or later someone is going to create a clone that does add features / adapt and you will start to lose business.

2. Adding new features is rarely 'easy', because you have to test it with the other features, do deployment, support older versions of the app (if possible), etc. Still, some stacks make it easier than others.

3. Simple deployment once you've configured your automation is an area where there has been lots of progress. You can look at Puppet, Chef, Docker containerization.

4. Dependencies change. Typically you should view changing dependencies like you would adding a new feature: have a justification for it, do full testing, and only then deploy.

5. Open Source is easy to find, and there are a lot of good quality candidates.

6. One commented recommended to use what you know. Within reason, that's good advice. However, the old adage of 'when all you have is a hammer, everything looks like a nail' applies. Use the right tool for the job.

7. For the front-end, I recommend client side JavaScript, either Lit or React using Vite. Svelte shows promise, but is not fully mature enough yet to be acceptable…

There does seem to be a lot of people who are very excited about the potential for Rust as a replacement for C/C++ in the embedded space.

There is "Working Group" dedicated to the domain: https://www.rust-lang.org/what/embedded & https://blog.rust-embedded.org/newsletter-28/

Toward the bottom of the page there's a "Production use" section with some quotes from people @ companies using it.

There's also an Embedded Rust "book": https://docs.rust-embedded.org/book/

In addition to the language itself, the surrounding tooling (e.g. for package management) contributes to the potential wins available from to moving to Rust.

My impression is that there are still areas where there isn't yet an idiomatic solution as to how _best_ to represent certain embedded SW concepts in a way that allows Rust's guarantees to be maintained. So I think there's some churn around that as people experiment/learn. (Primarily in relation to some of the physical constraints of the hardware.)

One of the companies prominent in the Rust embedded space is Ferrous Systems: https://ferrous-systems.com/

While it's still early days, relatively speaking, I think a lot of people see a move to Rust as a "once in a generation" opportunity to finally move on from an embedded ecosystem built on substandard vendor C toolchains & also gain from the robustness/safety that Rust offers.

In a lot of ways the embedded domain stands to gain even more from what Rust offers because unlike, say, the desktop/server space…

I'm working on a memory profiler for Python that is fast enough to run in production (see link below), so I've ended up with some similar problems re performance and importance of testing.

A few things the article talks about where one can maybe do even better:

1. likely()/unlikely() not being in stable Rust. This is true, but the hashbrown project has some hacked-up variants it claims work on stable: https://github.com/rust-lang/hashbrown/blob/bbda6e0077bafb75c02d0ace665faa09b4514932/src/raw/mod.rs#L47

2. Rust not having fast thread locals. Same problem for me, so likewise did it in C with "initial-exec". But! If you use clang, you can get LTO across C and Rust, so you can get fast thread locals _and_ not have function call overhead. Basically need to use same version of Clang as Rust does (12 at the moment) and do a little song and dance in linker and compiler flags. See https://matklad.github.io/2020/10/03/fast-thread-locals-in-rust.html

3. For testing these sort of things, being able to assert "this test touched this code path" is extremely useful. In my case, for example, I have different code paths for sampled and unsampled allocations, but from perspective of code calling malloc() everything should be identical. So how to tell if correct code path was used? Coverage marks are a great solution for this: https://ferrous-systems.com/blog/coverage-marks/

(The Python profiler, if anyone is interested: I've already released an open source memory profiler that tracks…

My very first job out of school was in a local company writing enterprise software and I hated it, lasted only a few months. Then I enlisted in a uni research project to build a Cubesat as a systems engineer, and after a couple of years I moved to the agency.

I haven't seen many career hoppers, but I'd say it's doable. I would try to enter through the ground software path: mission control systems or simulators. Those employ more "pure" software people.

From there it's a matter of being in touch with the embedded guys and show that you can do it. Simulators are great for that; they're basically a piece of software that emulates the onboard processor and simulates all the other sensors and actuators so operators can train and validate the on-board software. You have to be in touch with the onboard software developers, because there are always lots of kinks to iron out (e.g. I once had to fix a bug that a compiler optimization introduced, making magnetorquers always "max out" on actuation).

If you're in trading, I assume you're proficient in C++? If so, that's a great asset already.

About Rust: I love Rust and I use it in my embedded work now. I think it would be very beneficial for space applications. That said, there is a long way until it's accepted in the space industry. Ferrous Systems[1] is working on it, but it will take a long time; it's a slow industry. Perhaps it will start being accepted by the end of the decade.

Another idea for a side project: amateur…

So you're saying for two of the three arbitrary rules I mentioned you need additional tooling for analysis... sure sounds like my initial point.

But that's not even the point.

> If anything I'd say the contrary is true, people overestimate what MISRA achieves, big chunks of it could be summarised as "Don't do things that are obviously a terrible idea".

This is exactly what I mean. You're missing the point of MISRA if you think that's an overestimation or just to make managers happy... MISRA is often for life or death, and it's not even going as far as the random ISO standards that end up applying on top of it in some domains. It might be "obviously terrible" stuff, but very excellent developers end up doing it anyways sometimes, that's just being human.

The ground work to even verify a Rust toolchain doesn't even exist, (the closest I could find is a WIP https://ferrous-systems.com/blog/sealed-rust-the-pitch/) so I'm guessing everyone forcing this is likely rolling their own setup of additional tools?

If you don't work on ABS controllers and you work at somewhere like Tesla where the bar for safety is a little lower in the name of using new shiny things, by all means use Rust. But I wouldn't do that in a million years. I simply don't buy that using established MISRA C tooling is less safe than rolling your own lint setup.

They created a specification for Ferrocene because Rust does not yet have a language standard:

https://spec.ferrocene.dev/

>> But does the language need a standard?

Yes, Rust needs a standard.

>> And if so, then for what purpose?

For the same purpose that all standards have--to formally define it in writing.

Ferrocene's web site (https://ferrous-systems.com/ferrocene/) shows that it meets the ISO 26262 standard (https://en.wikipedia.org/wiki/ISO_26262).

Why does ISO 26262 matter? What purpose does it serve? Couldn't a vehicle manufacturer just say "our vehicles are safe"?

Which would you trust more: a vehicle that is verified to meet ISO 26262 standards, or a vehicle whose manufacturer tells you "it's safe" without formally defining what "safe" means?

I stated it above, but I will re-state it here: Without a language standard, there are many organizations and industries that will not use Rust. Not because Rust is not a fantastic tool for the job, but because laws, regulations, etc. require standardization and qualification of components.

This means that I can use a qualified C compiler and toolchain to write safety-critical code, but I can't use Rust despite the fact that Rust is a better choice and will help to prevent problems. Standards do matter. Rust needs a language standard.