nickelpro

For fusion the bar is "economically viable", in the current discussion for QC the bar is "cryptographically relevant".

They are comparable in that to meet either criteria, a variety of unsolved engineering challenges need to be overcome. For both, some of those problems have no clear and obvious solutions to which a simple application of resources and time will achieve.

Currently unknown innovations are required, unknown unknowns lurk in the dark corners, and all projections are relying on the assumption such innovations will arrive in a timely fashion and the unknown unknowns will be harmless glitches.

Neither are likely impossible, but betting on timelines is a fools game. This isn't the NYT publishing man-made flight is a million years away 2 months before the Wright brothers flew at Kitty Hawk, waiting for the right conglomeration of otherwise sound engineering to materialize in one place. It's like saying level 5 self-driving cars are two years away, a perpetually delayed technology for which all problems are well known and no new innovations are imminent.

It is exceptionally unlikely CRQC will be achieved in our lifetimes, if ever. The closer example is economically-viable fusion power production, which today has better odds than CRQC but remains solidly in the "maybe" zone after decades of global investment. Even though fusion weapons had been achieved half a century beforehand.

The bombs were actually relatively easy problems, in the scheme of things.

It is never wise to listen to people who's jobs and funding are connected to the development of a technology on when that technology will arrive. The answer is always "soon".

Many new school HDLs are working in this space and they couldn't be farther from the "representative of what digital circuits are constructed from" idea. Often they're high-level programmatic generators, very far from describing things in terms of actual PDK primitives.

Clang says "we don't need them", GCC says "we'll ship them in libstdc++", and MSVC says "you are supposed to provide them".

I didn't know about that when I was working on finishing import std for CMake and accidentally broke a lot of code in the move to a native implementation of the module manifest format, so everything got reverted and put back into experimental.

This was wrong, mostly because C++ compiler flag semantics are far more complicated than in Fortran, you live and you learn. The bones of most implementations is identical to Fortran though, we got a ~3 year head start on the work because of that.

Ninja already had the dyndep patch ready to go from Fortran, CMake knew basically how to use scanners in build steps. However, it took longer than expected to get scanner support into the compilers, which then delayed everything downstream. Understanding when BMIs need to be rebuilt is still tricky. Packaging formats needed to be updated to understand module maps, etc, etc.

Each step took a little longer than was initially hoped, and delays snowballed a bit. We'll get there.

Modules solve the problems of text substitution (headers) as interface description. It's why we call the importable module units "interface units". The goals were to fix all the problems with headers (macro leakage, uncontrolled export semantics, Static Initialization Order Fiasco, etc) and improve build performance.

They succeeded at this rather wonderfully as a design. Implementation proved more difficult but we're almost there.

There's no current effort to standardize what a package registry is or how build frontends and backends communicate (a la PEP 517/518), though its a constant topic of discussion.

[1]: https://github.com/cps-org/cps

I agree with both of you, there's some interesting tricks here for how a website builds anti-bot protection, but the AI sloppification is framing it as a consumer protection issue but not delivering on that premise.

It is a reasonable criticism that the post does not deliver a "so what?" on its basic framing.

You generally do not want to simulate or describe raw gate-level netlists. Both languages are capable of that. Old school Verilog (not SystemVerilog) is still the defacto netlist exchange format for many tools.

It's just aggravatingly slow to sim and needlessly verbose. Feeding high-level RTL to Verilator to do basic cycle-accurate sim has exceptionally fast iteration speed these days.

There's no major implementation which doesn't handle warning or even failing the flow on accidental latch logic inside an always_comb.

Broadly, the X Server has a bunch of capabilities which are irrelevant. The modern model is really Window <-> Compositor based, and the X Server protocol is just a pointless middle man in that exchange.

The Unix philosophy is fragmentation into tiny pieces, each doing one thing and hoping everyone else conforms to the same interfaces. Piping commands between processes and hoping for the best. That's exactly how Wayland works, although not in plain text because that would be a step too far even for Wayland.

Some stuff should not follow the Unix philosophy, PID 1 and the compositor are chief examples of things that should not. It is better to have everything centralized for these processes.

Click any protocol, very few outside the core and absolute essential extensions have universal support.

X11's problems were rooted in the abstractions presented by the X11 core protocol and its extension mechanisms. The interface, not merely the implementation.

Wayland was correct in first focusing on replacing this interface. The problem is the effort stopped there and left the ecosystem to figure out the implementation part.

In X11, the problem was Xserver. Now, X11's design philosophy was hopelessly broken and needed to be replaced, but it wasn't replaced. As you correctly point out, there is no "Wayland", Wayland is a methodology, a description, of how one might implement the technologies necessary to replace X11.

This has led to hopeless fracturing and replication of effort. Every WM is forced to become an entire compositor and partial desktop environment, which they inevitably fail at. In turn application developers cannot rely on protocol extensions which represent necessary desktop program behavior being available or working consistently.

This manifests in users feeling the ecosystem is forever broken, because for them, on their machine, some part of it is.

There is no longer one central broken component to be fixed. There are hundreds of scattered, slightly broken components.

https://www.bitflux.ai/blog/memory-is-slow-part2/

The underlying syscall doesn't use the C ABI, you need to wrap it to use it from C in the same way you need to wrap it to use it from any language, which is exactly what glibc and friends do.

Moral of the story is mmap belongs to the platform, not the language.

It's simple, I'll give it that.

> Look inside

> Platform APIs

Ok.

I agree platform APIs are better than most generic language APIs at least. I disagree on mmap being the "best".

Compilers aren't deterministic in small ways, timestamps, encoding paths into debug information, etc. These are trivial, annoyances to reproducible build people and little else.

You cannot take these trivial reproducibility issues and extrapolate out to "determinism doesn't matter therefore LLMs are fine". You cannot throw a ball in the air, determine it is trivial to launch an object a few feet, and thus conclude a trip the moon is similarly easy.

The magnitude matters, not merely the category. Handwaving magnitude is a massive red flag a speaker has no idea what they're talking about.

This seems like an incredibly niche product that only a handful of people are interested in to begin with. It isn't an notable or surprising result that building it resulted in little interest from general audiences.

In a security context, it has come to mean days since a mitigation was released. Prior to disclosure or mitigation, all vulnerabilities are "0-day", which may be for weeks, months, or years.

It's not really an inflation of the term, just a shifting of context. "Days since software was released" -> "Days since a mitigation for a given vulnerability was released".

Then again, I don't really believe in performing complex operations manually and directly from a shell, so I don't really understand the use-case for having many small utilities in PATH to begin with.

If these aren't compelling, there's no real reason.

Chuanqi says "The data I have obtained from practice ranges from 25% to 45%, excluding the build time of third-party libraries, including the standard library."[1]

[1]: https://chuanqixu9.github.io/c++/2025/08/14/C++20-Modules.en...

Depends what "senior" means in this context. Someone with 20-years of domain experience in utility billing, who happened to be writing C++ for those 20 years? Probably not.

Someone who has been studying and teaching C++ for 20 years? Yes they are able to tell you the value category at a glance.

Language experience is not something you develop accidentally, you don't slip into just because you're using the language. Such tacit experience quickly plateaus. If you make the language itself the object of study, you will quickly surpass "mere" practitioners.

This is true of most popular programming languages in my experience. I find very, very few Python programmers understand the language at an implementation level, can explain the iterator protocol or what `@coroutine` actually used to do, how `__slots__` works, etc.

C++ is not unique in this, although it is old and has had a lot more time to develop strange corners.

The framing implies they understand little of art at all; beyond gurgling and clapping like a child at the colors and shapes they find most stimulating.

And even if it's not COW, there's nothing wrong or inefficient about opportunistically allocating pages ahead of time to avoid syscall latency. Or mmapping files and deciding halfway through you don't need the whole thing.

There are plenty of reasons overcommit is the default.