int08h

AI tells are all over this. Not even a light editing pass has been attempted.

This is more a hybrid "physicist writes a cryptography/graph-theory paper".

This paper takes secret sharing as a black box and asks the question: once you have your N shares, where on a network should you put them?

The author's claim is that placement is a first-class security parameter, not an implementation detail, because both recoverability and exposure depend on the topology of who holds what.

It's not a cryptography paper, the threat model is very weak by cryptographic standards — e.g. random compromise rather than adaptive or targeted adversaries, no correlation between hacking a vertex and its neighbors (the author flags this extension as realistic but out of scope), and only N-of-N (not M-of-N as one might expect) reconstruction.

I read it as a foundational framing paper that connects share placement to network reliability theory and statistical physics.

Right, I understand your meaning better.

I agree with you: no matter how good of a job the code (by construction or types or otherwise) does of “making unsafe states unrepresentable”, that in no way makes a real world complex system “safe” by itself.

Code can be structured so that valves may only be open OR closed, but nothing stops the real world from returning a sensor reading that says “the valve is <undefined>”. To remain a “safe” system, the system must deal with inconsistent states like “heisen-valves”.

Hmm, it seems you actually agree with the OP:

OP says (your quote):

> [Most production incidents] are due to the code entering a state that should never have been possible.

You say:

> [...] it is more true that most production incidents are due to the system entering into one of thousands of unsafe states which were possible and latent in production potentially for years

I see you both agree that a broken system enters an "unsafe state" (your words) or a "state that should never have been possible" (OP's words).

"Unsafe state" and "state that should not have been possible" are, in practice in a real system, the same practical thing. I suspect you both would agree "system confuses a string for an integer and acts based on erroneous value" or "system acts on internal state that indicates the valve is both open and closed" would be states that a system should not be in. Outside pedantry, your descriptions are practically synonymous with each other.

> In that sense, Rust enables escapism: When writing Rust, you get to solve lots of 'problems' - not real problems, mind you, but fun problems.

If this is true for Rust, it's 10x more true for C++!

Lifetime issues are puzzles, yes, but boring and irritating ones.

But in C++? Select an appetizer, entree, and desert (w/ bottomless breadsticks) from the Menu of Meta Programming. An endless festival of computer science sideshows living _in the language itself_ that juices the dopamine reward of figuring out a clever way of doing something.

Sit in a Compare-and-Swap loop on `ping` and `pong` as uint32s. Go even faster in the shared memory case. Zoom zoom.

Dmitry Vyukov has forgotten more about non-blocking synchronization (lock- and wait-free algorithms) that most developers presently remember.

Re: getting tooling "right" and that driving adoption/popularity.

I'll argue that Java and the JVM are very similar in this respect. Few will argue Java is a "good" language and the JVM has many shortcomings.

However the ecosystem of IDEs, JVM tools, and decades of big company investment (Sun, IBM, Oracle) have created an amazingly productive environment.