Indeed. I'm currently working in the automotive space, where there are lots of tiny embedded controllers to mange everything from engine operations to taillight flashing... and it's almost entirely C++. There's a little C in some pockets, but even then it's generally (a) built with a C++ compiler, and (b) has at least some actual C++ in it, even if it's C, stylistically.

Rust is a great fit, and a big improvement over all of the extra processes that try to paper over C++'s weaknesses when trying to write guaranteed-reliable code (C++ is better than C in that regard). The problem is that we can't actually use Rust in any safety-critical contexts -- even though it's clearly fantastic for those cases! -- because the necessary ASIL certifications are lacking. There are people working on it, though. Maybe it's actually solved... I need to look into the Ferrocene solution and see what it includes and what it will cost us. I strongly suspect that Ferrocene's compiler and libs are completely unmodified copies of the regular Rust toolset, and that what you're paying for is just their certification work. But that's probably just fine... the work needs to be done and someone needs to be paid for it.

In this case, the answer is better tools, meaning better than C. There is fundamentally no way to get memory safety in C. People have been trying for decades with smarter linters, macros, manual review processes... nothing works at scale. If you have a solution, you should show it to the world and become rich and famous.

Give it a try! See if you can find a solution that I couldn't.

The gist contains a hugely-simplified version of the code, of course but enough to show the problem, in multiple variations. I actually tried a lot of other things, including adding some helper functions but, no matter what, if I have a codepath that returns a mutable ref to the content, the mutable borrow of self is held until the end of the function so nothing else can borrow. The only workable solutions I found were (a) double lookup or (b) unsafe code that creates an additional mutable reference.

This is because every previous president was too honorable to do so, so no one thought it necessary to include the presidency in those laws.

Sadly, the current occupant of the White House is utterly lacking in any form of honor or even basic human decency. As Americans, we should all feel deeply ashamed.

You didn't even read my comment, apparently.

Do you actually believe yourself? This Congress has passed less legislation than any single-party Congress in the last century: Go look it up. In the first year they passed a grand total of 38 bills -- normal is more like 200. And they've repeatedly failed to act when any other Congress would have, either to rein Trump in, or else to authorized the openly-illegal actions that he wanted to pursue and which the GOP clearly supported (e.g. changes to immigration laws to make deportations easier).

The current Congress is one of the most do-nothing bodies we've had.

I'd describe it more as a history of contemptuous attitude toward both the law and the courts that stomps all over the law but usually stops just barely shy of actual contempt of court. Even that's a bit too kind. The only reason contempt-of-court citations aren't flying regularly is because judges are accustomed to giving the government every benefit of the doubt. That's changing rapidly, though; the judges are getting fed up.

Sure, but it also says that Congress makes the laws, not the president. Since the GOP leadership doesn't believe in passing legislation, it won't be a conflict between state and federal law, it will be a conflict between state law and an executive order.

Movies are not real ...
Who cares if a non real story is story tale-ed by an AI created movie or a movie that costed a fortune to make and the people involved got paid bread crumbs?
Thinking about Avatar, Lord of the Rings of Game of Thrones.

No.

Diode shot-noise output is demonstrably based in large part upon quantum effects. There is also some determinism in there, but mixed in with a lot of true randomness.

As a practical matter, getting enough output from a noisy diode and then compressing it with a cryptographic hash function is equivalent to perfect true randomness. This work is a cool achievement, but it has no practical benefit over the systems we use today... systems that are built into most modern CPUs.

Yeah, that is a nice approach in many cases.

My problem was different, though. My problem was that the function needs to return a &mut to the map value, and I also needed to take some other action that involved a map lookup if the map entry wasn't present. The two actions (return map entry reference and perform another possibly-mutating action on the same map if the searched-for map entry wasn't present) were in two different match arms, so there was no mutable ref being held on the map in the value-not-found arm (the return value of which was always some sort of error), *but* the borrow checker assumes the return-by-reference in one arm to mean that the mutable ref is held for all arms.

Restructuring the code in various ways to make it absolutely, positively, clear that the mutable ref was not being held in the not-found path didn't help. I even tried using entry(), but it didn't change the fundamental issue. As long as there is any path through the function that returns a mutable ref to a value in the map, the compiler considers all subsequent paths to be holding a mutable ref, even if they're not reachable if the ref-returning path executes.

The unsafe solution would have been to create two mutable references to the map. Technically UB, but a pretty common dodge.

The safe solution was to do a "contains_key" check first and if the key wasn't present to then do the other possibly-mutating operation and return the correct Err(). Since that path didn't return a ref, the possibly-mutating operation was clearly completed, clearing the way for the lookup that did retrieve the value, check it and then (if the check passed), return a &mut ref to it.

I'm even seeing tiny firmware moving to Rust. no_std noalloc Rust is actually a pretty good fit for that environment, especially since a lot of tiny firmware code absolutely, positively must not crash, ever. Rust's memory safety plus the no-panic crate get you about as close to that as possible without formal methods. The biggest remaining gap is stack overflow. flip-link is a pretty good tool for that; it doesn't keep you from blowing the stack, but it makes stack overflows a hard, immediate crash rather than quiet corruption.

Ah, the "Of course we can do this if only programmers always remember to do X, Y and Z" argument.

This is exactly the point. Rust encodes those safe practices into the language and has the compiler enforce them. No one is arguing that it's not possible to write safe, correct C code. Only that humans are incapable of doing it at scale.

Of course he asked himself those questions. The problem is that the answer is "I can't. I can do some things to try to reduce their occurrence, but C is fundamentally not designed to make avoiding them possible".

You clearly haven't written a significant amount of Rust (or C++) and then disassembled it to examine the output.

You mean, what Rust does.

Is a C string even UTF-8? You have no idea. The *only* thing you know about a C string is that it has some bytes and (you hope!) a NUL terminator.

You mean, what Rust does.

It's also the pointer stuff that trips up people who do understand the underlying assembly language code.

Only if your compiler sucks, which hasn't been the case for a very long time. Back in the late 80s when I started writing C, compilers already optimized switch statements into binary searches of the target space. By the early 90s I'd encountered a couple of compilers that optimized them into extremely efficient hash tables, making them both faster and more compact. In the 2020s compilers are downright wizardly at optimizing these things.

This is actually really important for Rust, because Rust's type-safe-union enums strongly encourage heavy use of switches. Many cases that require vtable-based polymorphism in C++ (or structs of function pointers in C) end up as highly-optimized switches in Rust. You can do vtables in Rust, too, but they're strikingly less common than in C++ and even than in many common C styles.

Good C++ classes use functions that are as small and single-purpose as possible. You can write crap code in any language. You can write slow code in any language.

This doesn't follow at all. Using the C runtime doesn't preclude being a better C, at all. The problems with C have very little to do with its runtime. C's problems are all about the lack of bounds checking, lack of dangling pointer checking, lack of thread synchronization checking. Note that in Rust the last two things are done entirely at compile time. It's like if "-Wall -Werror" got 1000 times smarter. Not because the compiler is smarter but because the language semantics don't require the compiler to allow a lot of potentially bad stuff.

It is true that sometimes Rust is too restrictive, disallowing provably safe code. Just yesterday, I couldn't convince the borrow checker that a function was safe without breaking a hashmap lookup into two steps. I actually considered using a small unsafe block to avoid the extra lookup. I decided against it, but this raises two points: First, in Rust if you need to you can always discard the protections (though note that even "unsafe" blocks are more restrictive than"-Wall -Werror") and drop down to a C style, or even assembler if you need to. Second, and more importantly, Rust points out when you're doing something potentially risky and forces you to think hard about it. C just lets you do it... even with -Wall -Werror.

Rust is fine for both, though when using in the kernel, drivers or on bare metal, you have to configure it correctly. For context, I'm currently writing bare metal code in Rust on a device that has minimal stack and no heap. It's no_std, noalloc, abort-on-panic (though I'm using the marvelous no-panic crate to statically verify that my code cannot panic). The code is very compact and very efficient -- but also guaranteed to be safe against buffer overflows, dangling references, etc. and, IMO, substantially more readable than the same thing would be in C. Making it compact and efficient requires understanding the code that will be generated, of course. This is universally true.