So if this one is a dictator, does that mean the next one is an emperor?

> He just didn't like the font so he ordered it to be changed.

There is your answer. He imposed his will - that's what dictators do. You have to be careful when the reason for any costly change is one individual's personal preferences. It's a bad omen.

> Equivalent to your boss ordering tabs be used instead of spaces.

That's not always equivalent, especially if it is to set a standard. Obviously, some people using spaces and the others using tabs is not ideal in situations you're referring to. It's also fine to change the standard, if they find a significant problem with the current convention. But if your boss wants it changed, and their only explanation is their dislike of the status-quo, then that's a red flag. The problem isn't very serious right now, but could grow into one in the future and you have to be on the watch.

Not exactly related, but this is also the government that keeps insisting that the tariffs are paid by the foreign exporters (now that's a BS justification by any government that warrants widespread panic). It's all about narratives. I wouldn't bother much with fact checking them.

So what next? Wheelchair ramps? Seats for the elderly and the pregnant? Accessibility features don't displace or even inconvenience the majority in any manner. They only make facilities accessible to an additional crowd, who should be getting them as a matter of right in the first place. What's the end game here?

No

Here is my take on your question.

> I'm curious why your perspective on Rust as a HW engineer.

C, C++ and Rust requires you to know at least the basics of the C memory model. Register variables, heap, stack, stack frame, frame invalidation, allocators and allocation, heap pointer invalidation, etc. There are obviously more complicated stuff (which I think you already know, seeing that you're an embedded developer), but this much is necessary to avoid common memory errors like memory leaks (not a safety error), use-after-free, double-free, data-race, etc. This is needed for even non-system programs and applications, due to lack of runtime memory management (GC or RC). You can get by, by following certain rules of thumb in C and C++. But to be able to write flawless code, you have to know those hardware concepts. This is where knowledge of process and memory architecture comes in handy. You start with the fundamental rule before programming, instead of the other way around that people normally take. Even in Rust, the complicated borrow checker rules start to make sense once you realize how they help you overcome the mistakes you can make with the hardware.

> Hardware does a ton of things - DMA, interrupts, etc. that are not really compatible with Rust's memory model - after all Rust's immutable borrows should guarantee the values you are reading are not aliased by writers and should be staying constant as long as the borrow exists.

> This is obviously not true when the CPU can either yank away the execution to a different part of the program, or some foreign entity can overwrite your memory.

I do have an answer, but I don't think it can be explained in a better way than how @QuiEgo did it: You can 'sandbox' those unsafe parts within Rust unsafe blocks. As I have explained elsewhere, these sandboxed parts are surprisingly small even in kernel or embedded code (please see the Rust standard library for examples). As long as you enforce the basic correctness conditions (the invariants) inside the unsafe blocks, the rest of the code is guaranteed to be safe. And even if you do make a mistake there (i.e memory safety), they are easier to find because there's very little code there to check. Rust does bring something new to the table for the hardware.

NOTE: I believe that those parts in the kernel are still in C. Rust is just a thin wrapper over it for writing drivers. That's a reasonable way forward.

> Additionally, in low-level embedded systems, the existence of malloc is not a given, yet Rust seems to assume you can dynamically allocate memory with a stateless allocator.

That isn't true. @QuiEgo already mentioned no_std. It's meant for this purpose. Here is the reference: https://docs.rust-embedded.org/book/intro/no-std.html#bare-m...

Okay. That sounds like a reasonable explanation. Thanks!

That's a rather pessimistic take compared to what's actually happening. What you say should apply to the big players like Amazon, Google, Microsoft, etc the most, because they arguably have massive C codebases. Yet, they're also some of the most enthusiastic adopters and promoters of Rust. A lot of other adopters also have legacy C codebases.

I'm not trying to hype up Rust or disparage C. I learned C first and then Rust, even before Rust 1.0 was released. And I have an idea why Rust finds acceptance, which is also what some of these companies have officially mentioned.

C is a nice little language that's easy to learn and understand. But the price you pay for it is in large applications where you have to handle resources like heap allocations. C doesn't offer any help there when you make such mistakes, though some linters might catch them. The reason for this, I think, is that C was developed in an era when they didn't have so much computing power to do such complicated analysis in the compiler.

People have been writing C for ages, but let me tell you - writing correct C is a whole different skill that's hard and takes ages to learn. If you think I'm saying this because I'm a bad programmer, then you would be wrong. I'm not a programmer at all (by qualification), but rather a hardware engineer who is more comfortable with assembly, registers, Bus, DRAM, DMA, etc. I still used to get widespread memory errors, because all it takes is a lapse in attention while coding. That strain is what Rust alleviates.

> Memory safety applies to all memory. Not just heap allocated memory.

> Anyway, Rust has benefits beyond memory safety.

I want to elaborate on this a little bit. Rust uses some basic patterns to ensure memory safety. They are 1. RAII, 2. the move semantics, and 3. the borrow validation semantics.

This combination however, is useful for compile-time-verified management of any 'resource', not just heap memory. Think of 'resources' as something unique and useful, that you acquire when you need it and release/free it when you're done.

For regular applications, it can be heap memory allocations, file handles, sockets, resource locks, remote session objects, TCP connections, etc. For OS and embedded systems, that could be a device buffer, bus ownership, config objects, etc.

> > Nearly all of the relevant code is unsafe. There aren't many real benefits.

Yes. This part is a bit weird. The fundamental idea of 'unsafe' is to limit the scope of unsafe operations to as few lines as possible (The same concept can be expressed in different ways. So don't get offended if it doesn't match what you've heard earlier exactly.) Parts that go inside these unsafe blocks are surprisingly small in practice. An entire kernel isn't all unsafe by any measure.

This one is apparently a genuine mistake from the author. But I think we should leave it as it is. The confusion and the argument about it is interesting in itself.