Voting: std.logger

[via Digitalmars-d]

On Tuesday, 2 September 2014 at 14:53:17 UTC, Dicebot wrote:
> If you are going to speak more about abstract performance I am 
> going to simply ignore any of your further posts on topic.

I am not abstract. These are very concrete requirements:

1. You have to be able to determine types and formatting at 
compile time otherwise you cannot do binary logging.

2. You have to be able to determine types and formatting at 
compile time otherwise you cannot minimize the probability of 
introducing run-time errors by turning on full logging.

This is very important use scenarios:

* Performant fine grained logging (as close to zero overhead as 
you get) in libraries and frameworks is essential for fixing 
cloud-based servers where you typically cannot use regular 
strategies. I don't control frameworks, so it is important that 
they use standard lib logging.

* Performant fine grained logging (as close to zero overhead as 
you get) in client side frameworks is essential for fixing online 
game clients that runs on heterogenous hardware since you don't 
get to run a debugger on all configurations.

I don't know enough about what the limitations for advanced 
compile time reflection is, but it has been claimed in this 
thread that the current design does not make it possible to 
establish this at compile time.

Then I have to conclude that the current design cannot be safe 
enough or performant enough to be useful in libraries and 
frameworks and give D an advantage in the server-market...

Risks:

1. If D libraries and frameworks starts using and 
under-performing logger because it is the official D logger 
library, then you cannot ship products with fine grained logging 
based on these framworks. This is a lost opportunity.

2. If phobos includes under-performing libraries then you risk 
having a new split and have two standard libraries and/or two 
incompatible logging frameworks.