I like to add that there heavily regulated industries that successfully brought down cost - such as aviation. The reason nuclear industry is not able t bring down cost in general is because building plants is slow and there is also no scale in numbers, so you can not iterate and optimize. Bringing down cost also did not work under favorable political circumstances. SMR try to address exactly this, but the problem is that there are also many fixed costs so building larger plants is more efficient. The gains from building many small reactors must be large to overcome this. I would not bet my money on this.

I think the idea that "evil people killed nuclear by adding pointless regulations" is a bit of a fairy tale nuclear proponents tell to rationale the economic failure of nuclear. The fact that there is indeed some element of truth to this may be very misleading.

I think it is your comment which is misleading. First, there is capital cost in addition to operational cost. (Ironically, directly in a sentence mentioning "lie by omission".) Then, the idea that it is expensive only because of paper work is clearly wrong. Regulations certainly add cost, but this is certainly not the only reason building a nuclear power plant is expensive. Then it is also clear that "no regularization" is not an option, so it remains unclear how to fix this, as some regularization is necessary. The statement "If this happens, then most of the expense to build a nuclear power plant will vanish, leaving only the significantly cheaper operational costs." implies that all capital cost would disappear without regulations, which would mean you could magically create nuclear plants over night without cost, which is clearly a ridiculous statement.

GP said: "frankly the thought of having to roll my own dynamic array, linked list (for the 10^6th time)" and this is wrong. You need to do it once, or just pick a library once. I agree that there are advantages of having some common data structures in the standard library.

And yet, many of the applications I use daily and actually prefer to use turn out to be written in C. I think more people should write applications in C.

I agree, but this was not the argument I was replying to.

I don't think this is is the case. While the N9 was certainly late and likely for the reasons you explained, and Android was coming strong, I do not think the market has already consolidated at that point, also because Nokia was still selling millions of Symbian smartphones. I certainly did not own an Android phone or seen too many people using it when I bought my N9.

No, I don't think so.

I do not understand this comment "for the 10^6th" time. Even if you do not want to use someone else's library, you write it once and then reuse it. The idea that is has to be in the standard library or you have to rewrite it from scratch all the time is very weird.

I prefer C over Rust anytime because of much less complexity, more portability, higher stability, more tooling, far less supply chain issues, fast compilation times, proper dynamic libraries, less ugly syntax.

I had the N9, the GUI was good. I liked this phone much more than the Android phone I had to replace with much later. I do not know what went wrong inside Nokia, but the CEO came from Microsoft and killed Meego.

IMHO " seemed destined for irrelevance after the iPhone's 2007 arrival." is rewriting the history. My interpretation is that Nokia panicked and self-destructed by switching to Windows Phone after seeing iPhone but even more Android taking smartphone market share in 2010 and 2011, and if it instead just had kept developing their own Linux-based smartphones, it would still be around selling their own Linux-based smartphones which were far superior than Android.

You can also specialize C code for architectures, you do not need C++ template metaprograms for this. I also see them overused, creating a lot of bloat that then can hurt performance.

Rust has many flaws C does not have, including a type system build on monomorphization, annoying syntax, less explicitness, worse support for independent compilations.

But what you can is put an ownership / lifetime model similar to Rust into C or C++. This does not avoid all the hassle of Rust but would avoid some of the problems of Rust and allow a much smoother transition.

It is the usual problem of open-source and free software. What is old is not maintained properly. Rust gives companies an excuse to move on until it too is boring and old and will suffer from neglect.