Rossphorus

Rust has support for many embedded targets. I can personally vouch for the MSP430. Rust compiles down to an intermediate language which can then use the same compilers and linkers as C. For instance when compiling Rust for the MSP430, GCC-MSP430 is actually part of the toolchain.

Not really. While working at the OS-level can typically require 'unsafe' operations a core tenet of writing Rust is making safe abstractions around unsafe operations. Rust's 'unsafe' mode doesn't disable all safety checks either - there are still many invariants that the Rust compiler enforces that a C compiler won't, even in an 'unsafe' block.

And even ignoring all of that, if 10% of the code needs to be written in Rust's 'unsafe' mode that means the other 90% is automatically error-checked for you, compared with 0% if you're writing C.

Here's the generation statistics of the BN-800 reactor I mentioned before: https://pris.iaea.org/PRIS/CountryStatistics/ReactorDetails.aspx?current=451 It's been operating at about 70% of it's rated capacity basically since it was first turned on, that's large scale power generation. Breeder reactors have been in commercial use for decades (see also: Phenix and Superphenix).

The simple reason why breeder reactors aren't the default is because most reactors don't need to be breeders. The two main upsides of a breeder reactor is a) breeding of nuclear material, which as I said before was only ever a concern in the very early days of nuclear power. We have thousands of years' worth of fuel available now. b) The reuse of nuclear waste for additional power generation. Of course you have to have nuclear waste to reuse first, which necessitates many other, non-breeder reactors already being in use, so breeder reactors are usually restricted to countries that already have significant investment into nuclear power, like France, Russia, China, etc.. If you don't need to breed more nuclear fuel, and you don't have waste to reprocess you might as well keep it simple and build a regular LWR reactor.

The Wikipedia page for breeder reactors has a whole list you can even sort by output capacity. For example, the BN-800.

There have been plenty. For example, the CANDU series of reactors developed in the 1950s and 60s. Breeder reactors were quite popular during the early days of nuclear power, as it was initially thought that there was maybe only 100 years' worth of (easily accessible) nuclear material on earth, rather than the thousands (or tens of thousands) of years' worth we know of now, due to both more reserves being discovered and also easier methods of fuel enrichment being developed. The fact that breeder reactors have fallen out of favour due to abundant fuel reserves certainly says something.

Breeder reactors produce more fissile material than they consume.

The MSP430 is just the chip I happen to use at work, if you're not convinced you could try looking for an actual ultra low power chip, I found the STM32U0 at 70uA/MHz and the STM32U5 at 16uA/MHz in the first result.

Even ignoring selecting a more efficient micro, a smattering of tiny ceramic caps will buy you a few hundred microjoules for bursts. If you're already operating at 2V you can get a 6V rated 100uF cap in a 1210 package - and that's after considering the capacitance drop with DC biasing. Each one of those would buy you 200 microjoules, even just one ought to be plenty to wake up for a few tens of milliseconds every second to get a reading from some onboard peripheral (as an example) then go to sleep again.

For sure, you're not going to be doing any heavy lifting and external peripherals could be tricky, but there are certainly embedded sensor use cases where this could be sufficient.

It's more than you think. I work with the MSP430 microcontroller, which is capable of a sleep current of 40nA @ 2V, full active mode at 140uA/MHz with all onboard peripherals turned on. With this you could achieve almost a 20% on-off ratio with a 1MHz clock, or keep it in active mode all the time at ~150kHz, which is sufficient for many embedded sensor applications.

GTA online took ages to load, like 10+ minutes on some machines. One guy got really annoyed and investigated. It turned out to be loading a single 10MB JSON file in an incredibly inefficient manner. The JSON file contains about 60,000 items and they need to extract each item from it, but every time they look for the next item they start from the beginning of the file again, despite already knowing where they found the previous item! All the entries in the JSON list are unique, but the code also checks for any duplicate entries, of course it's also done in the least efficient way possible requiring 1,984,531,500 comparisons for something that has no effect. Not only did this one person find these problems but he also implemented a fix that reduced load times by 70% as a result, shaving off more than 7 minutes of load times for some machines. The fact that Rockstar didn't notice this is frankly shocking and speaks to the fact that they really just don't care.

https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/

Nitpick: The relationship between vehicle weight and road damage is a quartic (e.g. x to the power of 4), not an exponential

That's fair. Because I explicitly mentioned &'static str later on, my explanation of &str implicitly assumes that it's a non-static lifetime str, so it isn't stored in the executable, which would only leave the stack. I didn't want to get into lifetimes in what's supposed to be a high-level description of types for non-Rust programmers, though. I mentioned 'stack' and 'heap' explicitly here because people understand that they mean 'fast' and 'slow', respectively. Otherwise the first question out of people's mouths is 'why have a non-growable string type at all??'.

I never said str is heap-allocated. I'm presuming you meant stack when you said heap (or you meant String when you said str)?