What are you talking about, there is actually too much unicode awareness in C++. Unicode is not the same thing as utf-8. And, frankly, no language does it right, I'm not even sure "right" exists with Unicode

Too much unicode in standard C++? Where?

c++20's u8strings took a giant steaming dump on a number of existing projects, to the point that compiler flags had to be introduced to disable the feature just so c++20 would work with existing codebases. Granted that's utf-8 (not the same thing as unicode, as mentioned) but it's there.

And yet, unicode support is still abysmal throughout the standard library. I don't disagree though.

Things like char32_t, std::u32string for storing UTF-32 characters.

And yet, none of them work with std::regex etc.

I once spent several days debugging that same mistake. Stuff worked perfectly in tests but broke misteriously in production builds. Couldn't stop laughing for a few minutes when I finally figured it out.

Atomic operations, especially RMW operations are very expensive, though. Not as expensive as a syscall, of course, but still a lot more expensive than non-atomic ones. Exactly because they break things like caches

Not only that, they write back to main memory. There's limited bandwidth between the CPU and main memory and with multithreading you are looking at pretty significantly increasing the amount of data transferred between the CPU and memory.

This is such a problem that the JVM gives threads their own allocation pools to write to before flushing back to the main heap. All to reduce the number of atomic writes to the pointer tracking memory in the heap.

> Just use lambdas/callbacks

"Just" is doing a lot of work there. I've use callback-based async frameworks in C++ in the past, and it turns into pure hell very fast. Async programming is, basically, state machines all the way down, and doing it explicitly is not nice. And trying to debug the damn thing is a miserable experience

You can embed the state in your lambda context, it really isn't as difficult as what people claim.

The author just chose to write it as a state machine, but you don't have to. Write it in whatever style helps you reach correctness.

You still need the state and the dispatcher, even if the former is a little more hidden in the implicit closure type.

High-throughput is not the same thing as low latency. In fact, they're often at odds with each other

Google "Messmer Plan". France built 65 reactors in 15 years as a reaction to the 70s oil crisis, and now the majority of electricity in France comes from nuclear without any significant dependency on fossil fuels. The only thing that we're lacking is political will to change things.

Yep. Once people experience true hardship like having to keep their house just above freezing in the winter due to the cost of energy - all of a sudden impossible things become quite possible.

The only potential issue here would be if the west had collectively hollowed out its manufacturing base so much as to make surging capacity and capability a generational thing vs. immediate.

Coasting on past success eventually brings stagnation and pain. Hopefully the pain isn’t too horrible for normal folks this time around.

That seems to be mostly because of oil use which is coming from transportation. Electrical generation is dominated by nuclear and renewables. Electrification of transport will help, provided they don't generate the additional electricity needed by burning gas or coal...

That's why I used the word electricity and not energy. It isn't perfect, but still much better than the majority if the world and even Europe. The fact that even the French themselves cannot replicate it anymore speaks volumes about the weakness of the current political system. As a counter example, the Chinese can and do.

In 2024, China produced 8 times more electricity from renewables that from nuclear [1], and the renewable share is growing much more quickly. Nuclear is as dead in China as it is elsewhere in the world.

[1] https://ourworldindata.org/grapher/energy-consumption-by-sou...

China has a huge advantage over the majority of Europe: abundance of mostly empty land with a lot of sunlight, it's unrealistic in places like Norther Europe. But I'm not talking about nuclear alone, it was the best answer in the 70s and 80s, nowadays we need a healthy mix of nuclear, solar and wind. But above everything else we need a government willing to make significant changes and make them fast.

China has a larger population density than the EU. There is more empty land in Europe.

Chinese population is concentrated in the East. The Western half of the country is pretty much empty. Lots of sunny semi-desertic/desertic areas, too so they do have a lot of actually empty land well suited for solar (China is more to the South compared to Europe: Beijing is about same latitude as Madrid...) and wind.

> There is more empty land in Europe.

Truly empty? Or nature reserves?

And now Flamanville 3 is 7x over budget and 14 years late. Online but not commercially operational.

Their EPR2 fleet are getting an enormously large subsidy at 11 cents kWh CFD for 40 years and interest free loans. Sum freely. With the first reactor online in 2038 of everything goes to plan.

How many trillions in subsidies should we handout to new built nuclear power to ”try for real”?

Or we can just build renewables and storage which is the cheapest energy source in human history.

How do you control which CPU your task resumes on? If you don't then it's still the same problem described above, no?

on the OS scheduler side, i'd imagine there's some stickiness that keeps tasks from jumping wildly between cores. like i'd expect migration to be modelled as a non zero cost. complete speculation though.

tokio scheduler side, the executor is thread per core and work stealing of in progress tasks shouldn't be happening too much.

for all thread pool threads or threads unaffiliated with the executor, see earlier speculation on OS scheduler behavior.

Correct. The Linux scheduler has been NUMA aware + sticky for awhile (which is more or less what this reduces to in common scenarios).

It only seems right because there are no other implementations and the distinction is meaningless. You don't want to live in the world of multiple slightly different implementations all of which you need to support, this is, roughly, what the C++ build story looks like, and it's not fun.

It's the complete opposite for me. Rust code, especially async Rust code is just full of noise the only purpose of which is to make the borrow checker shut up

Try golang, where they did the only sane thing: everything is async from the very beginning, no function colouring

I think practical experience with Go reveals that this choice being “the only sane thing” is highly debatable. It comes with huge drawbacks.

Of course it has drawbacks, everything does, but my practical experience has been hugely in favor of what golang is doing, at least, in terms of cognitive load and code simplicity. It is very much worth it in many, many cases