Clever Functional Design
ferd.ca
ferd.ca
Yes! This is what I think most languages retrofitted to include functional features miss: the constraints of immutability and (customarily) no global variables force you to think about what data you actually need where, and often lead to a cleaner design.
Constraints are incredibly valuable.
Also, those constraints create consistency though necessity. For example, you can write immutable code in Javascript/Python/Whatever, but because it doesn't force it on you through constraints of the language, you have no guarantees that other parts of the application follows your immutability rules, so many of the benefits are lost. Being able to make assumptions about a program, because the language enforces them to be true, is very useful.
* https://hackernoon.com/constraints-and-creativity-14831a5386...
* https://www.fastcompany.com/3027379/the-psychology-of-limita...
* https://www.forbes.com/sites/groupthink/2013/07/12/creativit...
This is key. Because you have to be explicit about what state is retained, and how it is passed, you are forced to consider it more carefully. For most software, operating on data and storing state are the most important things -- it feels right to be forced to focus on it.
A log is normally considered a stream that's too large to keep in memory and needs to be incrementally persisted to disk on the fly, in timestamp order. (Or at least, the traditional file-based way does that, which affects the API.) But each HTTP request happens in memory and its log could be kept there.
A downside might be if the server crashes in the middle of a request, the request is entirely unlogged? But maybe you could log some values to disk and merge them later.
That's not the key insight though. The key insight is not to try to log the time something took -- instead, log the beginning and the end, and calculate the duration later. This makes the logging apis much simpler and enables measuring times between events in different scopes without coupling the different scopes.