3 comments

[ 0.23 ms ] story [ 14.7 ms ] thread
Very impressive stuff. We should see more and more of this sort of assistive technology, to alleviate and improve on the manual labour of programming. This isn't a language issue, although perhaps this sort of branch annotation in production systems is the sort of thing a futuristic language runtime might offer.
From an operations standpoint while I'd certainly like to see more logging in code branches that aren't seen often or expected by the developers (I am all too familiar with patching code that a developer wrote without knowing how many ways a function can fail outside the confines of their test environment) many of the logging statements I'd like to see are pretty routine and let me know that something is actually running as expected. This methodology errs on the side of removing statements I'd want. In the absence of instrumentation and infrastructure that can definitively tell me that a program has not deadlocked, I'd far rather have a crying baby than a silent baby.

With that said, I've seen developers write some woefully negligent logging statements that cost millions of dollars in production monthly due to the sheer amount of output that's generated and the extra management and storage costs necessary. When your write amplification from a 1 KB input blows up into 100MB minimum and 50% of that is whitespace or semantically useless statements like "ok" you have to start questioning the value of a log statement in that environment at all.

This is a topic that doesn't get much discussion so I'm glad to see people actually studying it.

> From an operations standpoint [...] many of the logging statements I'd like to see are pretty routine and let me know that something is actually running as expected.

Not to mention that these "everything OK" logs allow to track where exactly some data landed or where to look for more context. Logs are not just for reporting errors.