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.

Here’s a little secret: All data types don’t actually exist. When your code is compiled down to machine code your computer just operates on collections of bits. Types are a tool we use to make code more understandable to humans. int and unsigned int tell us information about how numerical values are interpreted. bool tells you that only two values are going to be used and that the value will somehow relate to true/false. char tells us that the value is probably some sort of text. But again, everything is just stored as bits under the hood.

You can go even further and define new types, even though they might still just be numbers under the hood - you could for instance define a new type, e.g. Age, which is still just an integer, but it tells you the reader more information about what it is and what it might be used for. You might define a new type just for error codes, so at a glance you can see that this function doesn’t return an int, it returns an OsError, even if the errors are actually still just integer values.

C does however play somewhat loosely by these rules, and to try and ‘make your life easier’ will often ‘coerce’ types between eachother to make everything work. For instance, integer types can be coerced to booleans - 0 is false, everything else is true (even negative values). Later on you’ll find that arrays can ‘decay’ to pointers, and other fun surprises. Personally, I think this implicit coercion between types is one of C’s biggest mistakes. If types exist to help humans reason about code, what does it mean if the compiler needs to silently change types behind the scenes to make things work? It means the humans were sloppy and the compiler can only guess at what they actually wanted to do.

There exist a spectrum of different behaviours in this regard, some languages are what we call ‘weakly typed’ (like Javascript, or to a lesser extent C) and other languages which are ‘strongly typed’. Weakly typed languages will try to implicitly convert types together to make things work: In Javascript if you try and add an integer to text “Hello!” + 52 the compiler will try to implicitly convert types until something makes sense, for instance in this case the compiler would say ‘oh, they probably want to add the text “52” onto the end’ and will produce “Hello!52”. Sometimes this is handy, sometimes it introduces bugs. A strongly typed language will instead simply refuse to compile until you make the types line up.

C++ actually does this ‘optimisation’ for std::vector<bool>. I say ‘optimisation’ because it effectivesly trades time for space, which is usually the opposite of what you want - space is cheap, time usually isn’t. Sometimes it’s a good tradeoff though - it’s common in embedded development where you might only have a few kB of RAM.

Another poster already mentioned that transuranics 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.

NZ is more aligned with the Commonwealth than the US. If the UK invited NZ to something and we turned it down that would be a big deal. We have a fairly small standing military, so we need at least one strong ally, and geographically speaking it’s gonna be either the US or China. I’d label NZ as a ‘begrudging’ US ally in that sense. NZ has previously verbally sparred with the US after we barred all nuclear-powered ships in our waters, so this wouldn’t be the first time there’s been some political tension between the two. Australia has a much stronger relationship with the US, hosting their military bases, nuclear weapons, and such. It’ll be interesting to see what their response is.

I got through two chapters of Artemis before I gave up. Project Hail Mary, however, is very good.

There’s nothing inherently wrong with digital ID, provided it’s implemented in a zero-knowledge-style manner. In fact, it would be much better than what we have now: Uploading your physical photo ID to every company that is legally required to ask for it.

Bubbles are not an existential threat to society. We’ve had like four bubbles in the past 20 years.

This is how bubbles always go, see the Gartner hype cycle. People always overextend, try to apply new tools/tech into places that it doesn’t belong, and only then do people realise the limitations of technology. This is common in business, C-suites explicitly exploit the hype cycle to secure naive investor funding, but investors always become wise eventually - it’s a game to see how much money can be extracted from them before they become increasingly aware of the limitations of the technology. There will be niches where the tech actually settles, but it’s always much smaller than what’s promised. I’m a programmer, I’ve been listening to people say that LLMs are going to take my job for the past five years, and yet every time I’ve actually tried to apply an LLM directly to my work it’s failed in a pretty drastic manner. I find existing systems useful as a tool, but that’s about it.