The Sad State of Debug Performance in C++

You should read "the practice of programming", he (well mostly Rob Pike if I understand the relationship) has some well reasoned criticism of the ways people use debuggers. In fact it is not silly - debuggers often make people feel more productive than they really are, so if you use a debugger (which I do once in a while) be careful to be objective about them.

> Computers are finite automata, they can't beget true randomness

Plenty of peripheral inputs that can be used to induce true randomness.

Your comment strikes at a deeper issue than what I suspect most replies it gets will address. The example of your never having needed nor missed std::move in all the code you've written rests on the distinction between specific uses and generality.

The reason modern C++ has become what it has become (in both good and bad senses) is because template generic programming has led it down a path of built-in constructs needing to consider an ever-growing zoo of weird cases. For every simple answer to the question, "how should this thing work?" there's a counter-example, "what if the type doesn't have that property?"

That's where we get things like std::move, etc. By contrast when dealing with your own code you can use knowledge of what is actually going to be passed to ignore many of these concerns or change your abstraction-using code to have or not have some property.

Overall, simplifying the use-case or restricting the domain is more pragmatic than making things fully general. C++, in its standard library / template utility headers is painted into a corner in that respect since it doesn't control the use-case, and the effort to restrict the domain (i.e. concepts) was delayed as well as representing itself another layer of complexity rather than a pure simplification.

>Computers are finite automata, they can't beget true randomness

"Non-deterministic" in this context means that the behavior of the program is not deducible from the state of the current thread of execution, or more generally, from the state of the system being analyzed. If another thread modifies the current thread's memory, that modification is non-deterministic because you couldn't have foreseen it by following any pointer that's reachable by the current thread. If a cosmic ray hits a computer chip and flips a bit, that bitflip is non-deterministic; you couldn't have predicted that that bit would be flipped by looking at any part of the computer.

In other words, an effect is non-determistic with respect to a causal chain if it's causally unrelated to it.

A tracing GC is non-deterministic for two reasons. First, it causes effects (namely, pauses) in all threads, even those that never allocate any memory. Second, it makes the lifetime of objects unpredictable. Thread A can allocate an object and then drop it, and when that object will be destroyed depends on the behavior of the entire system, not just thread A's. RAII doesn't exist in GC'd languages (except through using or try-finally hacks).

Reference counting is completely deterministic. If a thread holds the last reference to an object you can predict with certainty when that object will be released and which objects will also be released as a consequence, before actually releasing the object. You don't need to know what any other thread is doing to make this prediction.

Crucially, if you find that sometimes a reference counting program spends too long releasing an object graph, all you need to do to debug it is to run the program again under the same conditions and break when it reaches that point. Try doing the same with a garbage collector.

> Reference counting is completely deterministic. If a thread holds the last reference to an object you can predict with certainty when that object will be released and which objects will also be released as a consequence, before actually releasing the object. You don't need to know what any other thread is doing to make this prediction.

You're contradicting your own definition of determinism here. Other threads may be holding references to the same object, and unless you know what the other threads are doing, you _cannot_ predict when an object is going to be released just by looking at the execution of a single thread.

You need to look at the overall behavior of the application, with the complex object graph spanning multiple threads.

> all you need to do to debug it is to run the program again under the same conditions

this is much easier said than done.