Whenever you make a String you’re saying that you need a string that can grow or shrink, and all the extra code required to make that work. Because it can grow or shrink it can’t be stored on the (fast and efficient) stack, instead we need to ask the OS for some space on the heap, which is slow but usually has extra space around it so it can grow if needed. The OS gives back some heap space, which we can then use as a buffer to store the contents of the string.

If you just need to use the contents of a string you can accept a &str instead. A &str is really just a reference to an existing buffer (which can be either on the stack or in the heap), so if the buffer the user passes in is on the stack then we can avoid that whole ‘asking the OS for heap space’ part, and if it’s on the heap then we can use the existing buffer on the heap at no extra cost. Compare this to taking a &String which is basically saying ‘this string must be on the heap in case it grows or shrinks, but because it’s an immutable reference I promise I won’t grow or shrink it’ which is a bit silly.

Another poster already mentioned that transuranics and other such byproducts tend to be very dense, so a swimming pool can in fact hold tens of thousands of tons of spent fuel. Also, ‘nuclear waste’ is a generic catch-all term that includes less radioactive material, compared to ‘spent fuel’ which is just the really ‘high-grade’ material.

The part about not needing enrichment is worth discussing, but we do have solutions to that already. There are entire classes of reactors dedicated to not producing weapons byproducts or needing enrichment using the same processes capable of generating weapons-grade material. The reason we see reactors that can make these materials so often is because many of the early reactor designs (many still in use today) were explicitly selected for use by the US government during the early days for their dual-use ability to make plutonium for nuclear weapons. Examples of proliferation-safe designs include molten salts and integral fast reactors, but there’s an engineering experience chicken-and-egg problem - they don’t get built very often because we don’t have experience building them. A new design like this will face the same challenges.

TL;DR: Combining a particle accelerator and a nuclear reactor to turn Uranium-238 into Plutonium-239, which then fissions. The reactor itself is subcritical, so if the proton accelerator turns off then the reaction stops.

The main advantages of the system claim to be ‘increased efficiency of fuel use’ since the uranium doesn’t need to be enriched, the ability to burn long-lived nuclear waste, as well as the system being passively safe.

The first point strikes me as an odd thing to focus on, since all nuclear reactors are already very fuel efficient, and if you want maximum efficiency then breeder reactors exist already, which produce more fissile material than they consume - you can’t get much more efficient than that. Fast breeder reactors are also great for burning up nuclear waste too, but they never really took off because, well, there isn’t actually much nuclear waste to use, precisely because typical reactors are already very efficient: A reactor might consume one ton of fuel per year. You could fit all the spent nuclear fuel humanity has ever used into a single swimming pool. I mustn’t be too critical though - any attempt to close the fuel cycle is good, I just don’t think it’s a really pressing issue. Lastly, being passively safe is cool and all, but almost all new reactor designs are, and attaching a particle accelerator to a nuclear reactor sounds like an expensive way of doing it.

All of that being said, I’m always interested to hear about new reactor designs, so I guess we’ll see how it goes.

New Zealand.

Our laws make carrying anything with the intent to use it as a weapon (in self defence or not) a crime - whether it’s a gun, sword, pepper spray, cricket bat, screwdriver, or lollipop stick. This makes sure that when someone robs a corner store the owner gets jailed for having a baseball bat behind the counter. It’s absurd.

The law not only doesn’t equalise your chances, it actively forces you to be at a disadvantage when defending yourself, and by the time any police arrive the assailant is long gone. Most criminals don’t have guns (except for the multiple armed gangs of course), but plenty of them bring bladed weapons, there have been multiple cases of machete attacks.

I’m all for gun ownership for the purpose of property defence. Including strong legal defences for home and store owners repelling assailants.

I don’t think just anyone should be able to go and purchase a gun no questions asked, it should probably be tied to some kind of mandatory formal training, e.g. participation in army reserves. It should definitely be more difficult than getting a driver’s licence (but I also think a driver’s licence should be harder to get than it is now. The idea that you can go and sit a written test and then legally pilot a two ton steel box in areas constantly surrounded by very squishy people is kind of absurd to me).

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.