The argument is that small-scale nuclear reactors have been built for military and scientific applications so the tech is not especially novel.
What I think is unproven is whether SMRs can be built and run safely while being cost-effective to other forms of power.
I wouldn’t be surprised, for example, if it actually costs less to build and run one full-scale reactor than it does for multiple SMRs of the same output.
Yeah, the issue isn't knowing how to build small reactors, it's whether you can do so with enough economy of scale and learning to make it cheaper than conventional nuclear.
And I personally have switched from bull to bear on that. I was rooting for NuScale but they're hitting the same thing as everyone else.
Meanwhile, battery storage has been on an insane cost reduction curve.
If they can get Starship reliable enough, it'll definitely be successful even if it never goes to mars.
But despite SpaceX's huge successes with Falcon, that doesn't prove they'll cross the finish line with Starship. Falcon and specifically the Merlin engine made just about every choice they could in favor of risk reduction rather than the best possible performance. It was a continuation of work that Tom Mueller did while at TRW.
With Starship they're in more uncharted territory, especially the re-entry concept, and the engine has been designed under the opposite philosophy of trying to push limits.
They are, but if the country has a law forbidding you from doing anything, things cannot move forward. If they'll not work, of course they won't be built. And large classic reactors are unlikely to be built either, even with this new law.
Gotcha - yea I think it’s a good idea to try out these things.
I just hope it doesn’t become a ideological fight to make something work at any cost to fit a certain narrative (same goes for renewables of course)
Countries should definitely evaluate LMRs (Large Modular Reactors) too. Most countries need large amounts of carbon free energy, not small amounts. And nuclear power plant economics have profited in the past from making larger, more powerful reactor units.
But yeah their most modern nuclear power plant was a BWR 4 with Mark II containment, which would probably not be worth modernizing instead of building a new GenIII+ PWR from scratch that lasts a century.
In the contrary it’s one of the best design decisions of the language. The rules for object safety are the same C++ applies to virtual functions. On the other hand you don’t have to choose a priori whether you’ll need dynamic or static polymorphism, you can choose at use site, and the size of the objects do not pay for dynamic dispatch because the vtable pointer is kept together with the object pointer, not within the object.
This is possible in C++ too, but it may require extra work. But is it really needed that often to use both kinds of polymorphism for the same type?
> the size of the objects do not pay for dynamic dispatch because the vtable pointer is kept together with the object pointer, not within the object.
You have identical memory overhead in Rust and C++ if you store a single pointer to a polymorphic object. But if more than one such pointer is stored (if it's shared), Rust uses more memory, since it stores N virtual table pointers (together with each object pointer), where C++ stores exactly one virtual table pointer within the object itself.
> This is possible in C++ too, but it may require extra work.
Everything is possible, what matters is how much work you have to do to achieve and maintain it.
> You have identical memory overhead in Rust and C++ if you store a single pointer to a polymorphic object. But if more than one such pointer is stored (if it's shared), Rust uses more memory, since it stores N virtual table pointers (together with each object pointer), where C++ stores exactly one virtual table pointer within the object itself.
On the other hand Rust uses less memory if you store 0 polymorphic pointers, while C++ still pays the cost of storing a vtable pointer for each object instance.
Effectively C++ choose a design that optimizes for having a lot of polymorphic pointers, while Rust optimized for supporting polymorphism for all objects at no extra cost if you don't use it.
The C++ design is optimised for the case where you're mostly storing Things everywhere and then at runtime code works out whether each particular Thing is a Customer, or a Product, or a Target, or an Artist, or what...
I don't think even an LLM writes software like this, maybe somebody's Java 101 class teaches this, but frankly I think that's a bad way to teach even Java.
The Rust approach optimises for cases where Customers and Products and Targets and Artists are stored and treated separately and if we do need the generic Thing somewhere it's pretty rare so we store the extra information only where needed.
There is another important reason not to store the vtable pointer in the object: performance! In C++ if you want to make a virtual method call you have a double indirection where you must first load the object and only then can you load the vtable. Having a fat pointer like Rust does means that both loads can be in flight at once. If you are using enough dyn references to care about the extra memory then you'll likely care about the performance impact of those extra indirections even more.
Come now! It is clear that the sarcasm indicator wasn't suggesting that the government didn't really announce that. The sarcasm was in the invocation of governmental authority, which is thereby implied to be ill-founded and not worth listening to.
I felt it useful to provide a reliable source for such an outrageous national position. Lest some think it exaggeration or twisting of facts for humour or effect. It's not. Yikes. :-)
I understand the issue about the ever-moving target etc., but almost fifteen years later do you really believe C++98 is better than C++11 without move semantics and decent smart pointers? I remember working with Qt5 and C++98 and yes, it was productive, but it was also a mess of intricate object ownership.
I'm critical about some choices made with C++20 and after, like the mess that modules are, and the too-little-too-late ranges library. C++26 is also a joke imho. But on the other hand, working with std::optional and (in C++23) std::expected is so much better than without. The thing is nobody forces you to use every single feature of a new standard, but I would not recommend ignoring very good tools just for the sake of it.
For all of my projects it is good enough. C++11 onwards has a few advantages, but I don't need them. Moving ownership between containers to avoid allocations was possible with the standard library even before C++11, and Qt offered "implicit sharing" which has a similar effect without syntax changes and incompatibilities. Even with my C++11 projects (e.g. https://github.com/rochus-keller/eigen/) I had to take care still in 2024 which feature not to use on MSVC because it didn't work or behaved differently. I never have any ownership issues and I implement large compiler projects with different AST and IR layers. All my projects still compile with https://github.com/rochus-keller/leanqt/ on all platforms. I would never trade a tiny language advantage with a whole world of dependability issues. One day I will revive and refactor GCC 4.7 to get a cross-platform C++98 with parts of 11 compiler just written in C, then latest all of my software is buildable "from first principles".
PS: it's funny I wrote my comment three days (and not an hour) ago.
> Moving ownership between containers to avoid allocations was possible
That's not the biggest upside of move semantics. You can't safely express smart pointers without move semantics. They tried with std::auto_ptr, and it didn't work.
C++26 will allow billions of lines of pointless serialization boilerplate to finally be deleted, adding the basic reflection functionality that most other languages have had for decades.
Reflection is a joke. De/serializing arbitrary C++ structs is ill-defined. When you need serialization, even lots of it (e.g. silly JSON), I think you're better off writing your own framework where you can be clear about data formats and transformation rules.
Yes -- I can see good use for runtimes. For example, compiler can autogenerate good runtime error messages. Thinking about it, debuggers make use of reflection. Debuginfo formats have some kind of reflection built in.
I'm not sure C++26 reflection is sufficiently well-baked to actually allow it to be used for serialization boilerplate in codebases. What matters is not what the standard says, but what the compilers implement, and the compiler implementers I know have been kvetching about how problematic reflection is, to the point that it may never be turned on by default.
> and the compiler implementers I know have been kvetching about how problematic reflection is, to the point that it may never be turned on by default.
Out of curiosity, would you be able to elaborate on (or link to?) what makes reflection so problematic?
Yes, C++26 reflection is nice, but also extremely complex to understand and use well. The rest of C++26 is the usual series of too-little-too-late additions. Meanwhile I’m still waiting for pattern matching to become a thing (a proposal has been discussed for ages)
Much has changed for me since I used smart pointers where possible - which is the vast majority of the time. I am currently telling somebody you can't change a QString to a C string even though the C string probably won't overflow in that use. I have changed.
Smart pointers somewhat existed. Without move they were vastly less powerful. (You could have a generic shared pointer without move, but unique pointer has useful properties that you cannot get without move) Non-generic smart pointers - RAII - was very common but that was implemented separately for everything. Having to figure out how to deal with copy was a problem (though many times you disabled it and then passed a reference or a raw pointer to the object - a poor mans move which sometimes was good enough but often was annoying).
More importantly, before C++11 every library I worked with had their own incompatible way of managing memory. None of them used smart pointers in the API, it was always raw pointers (or references where possible but often not possible) and their own documented ownership rules. Any single library was simple enough to follow the rules (hint we got it wrong often), but the combination was very complex and sometimes impossible to combine the two different rules.
C++11 changed how most people manage memory. You could get the same effect without, but it was both more complex, and nobody agreed on the same rules.
What is a product? So you take two natural numbers `a` and `b`, and you want to sum `a` for `b` times, or vice versa. Then things become complicated if you want to do that quickly...
I never studied these specific classes, but my immediate intuition is that an n-input fan-in AND or OR gate can be reduced to a tree of 2-input gates with depth O(log(n)), which preserves polylog complexity, so surely AC = NC.
Wikipedia agrees :)
If you specify the exponent of the log, you get a different answer.
reply