I think Plan 9 gives a nice distinction. We use files as both a persistent store as well as an interface, so it seems nice to separate those two concerns out. That way you could have your logs as a UI into application state and only incur the overhead of serialization and persistence when you deem necessary.
Caveat, my Plan 9 experience is mostly theoretical.
Comments
A related problem is the constant churn of logging.. taking structured data, destructuring it with a string serialization and then parsing it again.
This resource-wasting antipattern pops up over and over again.
Also, logs are message-oriented entries and serializing them as discrete, lengthy files is insane.
Structured data should stay structured, say a time-series / log-structured database. Destructuring should be a rare event.
I think Plan 9 gives a nice distinction. We use files as both a persistent store as well as an interface, so it seems nice to separate those two concerns out. That way you could have your logs as a UI into application state and only incur the overhead of serialization and persistence when you deem necessary.
Caveat, my Plan 9 experience is mostly theoretical.