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.

Translation: A company that has the potential to benefit from regulation by squeezing out competitors wants more regulation.

I'm not saying they're not right, just that it seems awfully convenient for a company specializing in pumps that recirculate data center water to want efficiency regulations that would push customers towards their most efficient (and thus presumably most high-margin) pumps.

Instead of having your hot water fan out in a tree, you wire it like a token ring with a return pipe, where each faucet only has a short bit of pipe between it and the ring. Then, you have a pump to circulate hot water through the ring-shaped pipe network. That way, it takes half a second to get hot water instead of half a minute or more.

Sure. I'd imagine most hardware vendors will want it. I'm just saying that the wording, at least as described in the summary, is... problematic at best.

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.