[GitHub] [pulsar-client-go] flowchartsman commented on issue #1078: Replace `pulsar/log` and logrus with `slog`

["flowchartsman (via GitHub)" <gi...@apache.org>]

flowchartsman commented on issue #1078:
URL: https://github.com/apache/pulsar-client-go/issues/1078#issuecomment-1680725466

   > Besides, how do you compare among logrus, zap and the new slog? Are they functionally different? Or just we'd prefer a solution out of the box from stdlib.
   
   It's less about functionality, and more about future-proofing, since there will now be standard types that can serve as a compatibility layer without forcing a non-stdlib dependency for implementation. Right now, there are some difficulties I have with the standard logger, where I'm kind of locked in to how I deal with them:
   
   - logs are on by default, and an explicit nop logger must be provided to disable them
   - Default logging is very chatty, but there's no option to simply set a threshold for this without another logger implementation or using the nop logger to turn it off completely
   - Package logs display in a format I don't want to use.
    
   If I want to change any of these things, I must implement the entire interface, including more complex methods such as `SubLogger`, `WithFields`, `WithField`, and `WithError`, which return the `log.Logger` and `log.Entry` types, which means a dependency on `pulsar-client-go`. Or I have to use logrus with the wrapper, forcing me to have a dependency on logrus.
   
   If the library takes a `slog.Handler` or a `slog.Logger`, I can set the threshold and formatting I want on these, and the interface is well understood and can be connected with anything that supports `slog`. or will in the future, since it is likely that future packages will at least have to provide a `slog` compatibility layer, which means easier interaction.
   
   > IIRC pulsar-client-go still supports Go 1.15. What do you think of the migrating plan? As long as we declare to support versions before 1.21, we cannot fully adopt the slog solution.
   
   This issue has two parts: support for Go versions and semver compatibility on `pulsar-client-go`
   
   As far as semver goes, change to the logging interface would have to wait for a major revision number. I don't know if there are any plans to move to `1.0` ever, but that would be the time to do it. Or if this package ever moves to major version mirroring for `pulsar`, that would also be an opportunity. If there is any roadmap to the next major version, I wanted to get a tracking issue here, since that should definitely be on it.
   
   With Go versions, I think that it is okay to follow the support lifecycle of Go itself, which means two minor versions. That would currently put us at 1.20. 1.19 and older are EOL as far as Go is concerned. With the compatibility promise, it does not make much sense to declare explicit support for older versions. This at least opens up the possibility to support `slog` types as additional options without changing the primary logging interface once go1.21 is the oldest supported version.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org