Hacker News Reader

Thanks very much for sharing this - it has become one of my favourite articles! I especially like the idea of being able to replay a scenario just from the logs. Now to convince the rest of the team at work to switch to such a strategy.

There is a conclusion here that I'm missing which could have easily been made. It's that excessive logging often attempts to replace tests. Using the trivial example from the article, you wouldn't feel compelled to log the result of Add(x, y) if the Add was unit tested.

> if the Add was unit tested

The author talks about pure functions; "unit testing" sort-of implies a similar thing (something executable in isolation, turning arguments into return values). (Impure functions sort-of imply integration testing, etc.)

This is actually the fundamental concept behind time travel debugging; recording sufficient information to reconstruct past states of your system.

The primary difference is that time travel debugging solutions are more fully integrated because they will automatically insert exactly the necessary logging and they are integrated with interactive debugger state visualization tools so you do not need to do the state reconstruction manually/mentally, you can have the machine do it for you.

Repeatable Execution (2020)