That's a typo in the response, I believe. The screenshot shows 10^100 (10 to the power of 100).

Got a link to one of those debunkings? (If it's so thoroughly debunked, it should be easy.)

You're missing the value of these things in identifying bugs. When you subtract a number of seconds from a temperature, you'll be glad for the compile-time error. There also doesn't have to be a runtime cost, as in C++ (and languages supporting value type instances) they can either be type-erased or cost no more than an integer.

Debouncing doesn't need to delay a touchstart event, in general, so latency shouldn't really increase in a carefully designed system, especially if you can be animating in advance of the touchend event.

This is an interesting take on debouncing, but I found the choice of TV remotes as an example a bit confusing. From my understanding, the issues with remote controls aren’t typically caused by bouncing in the mechanical sense but rather by the design of the IR communication. Most remotes transmit commands multiple times per second (e.g., 9–30 times) intentionally, and the receiver handles these signals based on timing choices.

If there are problems like double channel jumps or missed commands, it’s more about how the receiver interprets the repeated signals rather than a classic switch debounce issue. There’s definitely a similarity in handling timing and filtering inputs, but it seems like the core issue with remotes is different, as they must already handle repeated commands by design.

Then there's the "hold to repeat" mechanic, where if you hold it long enough it'll add virtual presses for you.

That (to quote you) means you have to keep them in the queue until the next time the client connects, which could be a very long time.

To be clear, there's no real difference - in both cases you have to keep messages in some queue and potentially resend them until they've been acknowledged.

That's not the same trick, though it has similarities.

That's simply self-contradictory, as written. You say that it has (opt-in) types, then say that it doesn't have types. You could say "I hate that it doesn't have types by default", but it would be even more accurate to say "I hate that it doesn't enforce types by default", since it does have types, both strict and not.

Being able to open decades-old repos is very much the norm for widely-used version control systems.

What jjav is referring to is "at will" employment - in almost all US states, employees can be fired for almost any reason, with no recourse. So the fact you're saying that firing people is expensive and time-consuming in the US flies in the face of the actual legal environment there compared with most other relevant countries.