Hi,
Log4j types of logging systems do a reasonable job at capturing log entries, but they are poor at helping the human make sense of the produced log. Of course, they do attempt, but given that they see the log as a long string, there is a significant mechanism built around formatting.
This is broken because it implies that the human should read the log as a way of understanding it. This works fine for a couple of lines but fails miserably for even Mb logs (not to mention larger logs). One could tweak the formatting to make it machine readable, but in practice all logs I have seen in enterprise systems are mostly unstructured and one has to spend great effort to extract the useful information out of them. For example, I use the information in logs to understand performance and diagnose errors, and I am using automatic tools for that. But, to build those tools, the hardest part is to parse the log. That cost should not exist.
The object as an item of logging preserves the original information so that the machine can read it. String is just a way of serializing an object, and we should only use it only in this way. Formatting still has a place, but it should be clear that it is just one tool - most often the least useful one. That is the reason why in Beacon, there is no formatting in the core.
Priority is another thing I find rather artificial. For example, developers should mark as DEBUG things that are not useful in production, but in the end, they mark as DEBUG things that are too large to have in production all the time. The problem with this is that sometimes you really want to have access to a very specific event regardless of "priority". So, a better way of looking at filtering is by allowing the developer to cherry pick any event at any given moment.
We definitely have to get good at the backend, but logging objects should provide a significant advantage.
Cheers,
Doru