http4s icon indicating copy to clipboard operation
http4s copied to clipboard

Consider Log4Cats for Logging

Open ChristopherDavenport opened this issue 7 years ago • 5 comments

It allows us to abstract out of the logging game entirely. We could have people provide loggers, and we could just use it throughout.

Its relative immaturity holds me back from putting it out there strongly.

However I was wondering if people had opinions. As it would get us out of telling people what they are logging with.

ChristopherDavenport avatar May 09 '18 17:05 ChristopherDavenport

The external liability of a dependency is API churn times adoption. typesafelogging was high in both factors and got dumped. log4s has low churn which has made increasing adoption painless (and contributed to increasing adoption!). log4cats doesn't have the same track record, though we are generally fond of the author's work and one of us has his home address. :wink:

The external upside of a dependency is its use in public API times adoption. Since it doesn't appear in API, the external upside of any choice is zero.

The internal upside of a dependency is that it makes the code more maintainable, and the external upside to that is more maintainable code lets us focus on HTTP instead of logging. log4cats scores highly here if we commit to pure logging and is an obstacle if we don't.

So:

  • It should come with a backend that doesn't require log4s or similar, or the liability is additive.
  • Consider that blaze uses log4s. The liability may be additive for a majority of our users anyway.
  • The API needs to be rock solid, or else you need to go out of your way to scare off other adopters.
  • It requires every logging statement in an effect. It's the FP thing to do, but not yet universal in our code. Are we sure there are no places we want to opt out of that behavior?

I think we should not move on this today, but very strongly consider this as it matures, if it has a good story for the above.

rossabaker avatar May 09 '18 18:05 rossabaker

I'm pro log4cats in a lot of places that aren't performance sensitive (so basically everywhere outside of blaze + the backends).

I'm neutral on this. Logging is one of the few things I don't really care at all about side effecting much (It's almost never a side effect that bites you from my experience).

jmcardon avatar May 09 '18 18:05 jmcardon

So, ember uses log4cats, and is the one that will stay in this repository. Blaze pretty much has to use log4s, but will be moving out of this repository.

I'd prefer to have just one in this repository, so it makes sense to me to replace log4s with log4cats outside of blaze.

rossabaker avatar Apr 05 '21 13:04 rossabaker

The only compelling case for a logger in core is in multipart, if we can't clean up the temp files. It would be nice to eliminate that entirely.

rossabaker avatar Apr 12 '21 04:04 rossabaker

👍 log4s has shimmed the slf4j package on Scala.js which is dubious.

armanbilge avatar May 01 '22 22:05 armanbilge