5 ms·
1. You're right! Will fix it to handle this as well as the support for relative directories 2. Yes, Will integrate a logging library instead of fmt (https://gi
by stym06 2y ago
1. You're right! Will fix it to handle this as well as the support for relative directories
2. Yes, Will integrate a logging library instead of fmt (https://github.com/uber-go/zap https://github.com/uber-go/zap)
- arp242 2y agoWhat if I don't use zap? Ideally you want to add an option via a function or interface: func New(optOne bool, log func(string, ...any)) { if log == nil { log = func(m string, a ...any) { fmt.Printf(m, a...) } } log("starting; optOne=%v", optOne) } Or something along those lines.
- philosopher1234 2y agoThis is what log/slog is for!
- arp242 2y agoWhat if I don't use slog?
- derekperkins 2y agoChange and use slog with the zap adapter
- antook 2y agoFYI, Go already has a structured logging package called [slog](https://go.dev/blog/slog https://go.dev/blog/slog) in the standard library since V1.21.
- while1malloc0 2y agoBased on the child thread about zap vs slog I think I might not have been clear in my phrasing. The issue isn’t the specific functions used to print to the screen, it’s that library code is doing it at all. As the user of a library, I don’t want that library printing things to the screen if I don’t explicitly tell it to; decisions on logging/printing text to the screen are the responsibility of the person writing the end-user application code, not the library author. If the library author feels really strongly about printing stuff on the screen, they should make that behavior opt in, either with a configuration option or by providing some other mechanism that gives the user as much control over that behavior as possible (hence my example of throwing printing behavior into a user-supplied io.Writer)