4 ms·

https://pkg.go.dev/golang.org/x/exp/slog#hdr-Levels https://pkg.go.dev/golang.org/x/exp/slog#hdr-Levels seems to fall into the same trap that drives me _starkra

https://pkg.go.dev/golang.org/x/exp/slog#hdr-Levels https://pkg.go.dev/golang.org/x/exp/slog#hdr-Levels seems to fall into the same trap that drives me _starkraving_ about the 18,000 different(!) golang logging packages: there doesn't seem to be a sane way of influencing the log level at runtime if the author doesn't have the foresight/compassion to add a command-line flag or env-var to influence it. A similar complaint about the "haha I log json except this other dep that I import who logs using uber/zap so pffft if you try to parse stdout as json"

onionisafruit 3y ago
That bugs me too. I consider it a red flag for a library to log to anything except a `log.Logger` passed in from the caller. Now I'll expand that to include a `slog.Logger` as well. If the library is logging directly to stderr or stdout, that is a sign that it probably has other design issues as well.
- lokar 3y ago
  Put the logger in the context
  - vl 3y ago
    Isn't it considered bad practice?
    - tptacek 3y ago
      It's already idiomatic for OpenTelemetry, and otel has use cases that overlap slog.
    - preseinger 3y ago
      yes, in general the context stores request-scoped data, whether or not the logger is a request-scoped value is a grey area and to reply to sibling comment, opentelemetry is basically a house of antipatterns, definitely do not look to it for guidance
      - tptacek 3y ago
        I don't enjoy the otel APIs, but they are implicitly scoped; contexts are a natural place to store them.
      - mdaniel 3y ago
        > opentelemetry is basically a house of antipatterns "Look on My Works Ye Mighty and Despair!" https://github.com/open-telemetry/opentelemetry-collector/tree/v0.80.0/cmd/builder#tldr https://github.com/open-telemetry/opentelemetry-collector/tr... -> https://github.com/open-telemetry/opentelemetry-collector-releases/blob/v0.80.0/distributions/otelcol-contrib/manifest.yaml https://github.com/open-telemetry/opentelemetry-collector-re... ... and then a reasonable person trying to load that mess into their head may ask 'err, what's the difference between go.opentelemetry.io/collector and github.com/open-telemetry/opentelemetry-collector-contrib?' $ curl -fsS go.opentelemetry.io/collector | grep go-import <meta name="go-import" content="go.opentelemetry.io/collector git https://github.com/open-telemetry/opentelemetry-collector"> Oh, I see. Thanks.
      - euroderf 3y ago
        "The context stores request-scoped data" might be another Go-team dogma due for course correction RSN.
        preseinger 3y ago
        huh? there's no dogma involved here, it's just an observation of the properties of the type a context is created with each request, and destroyed at the end of it and values stored in a context are accessible only through un-typed, runtime-fallible methods -- not something you want to lean on, if you can avoid it
        euroderf 3y ago
        In practical terms there's pros & cons I guess, but in general doesn't loading a Context with session variables make code more concise and easier to understand ? DB connections, loggers, and the like. If you really want to pass around Context's in all your API signatures then at least try to make the most of it. Are pitfalls ever actually encountered ?

onionisafruit 3y ago

That bugs me too. I consider it a red flag for a library to log to anything except a `log.Logger` passed in from the caller. Now I'll expand that to include a `slog.Logger` as well. If the library is logging directly to stderr or stdout, that is a sign that it probably has other design issues as well.

lokar 3y ago
Put the logger in the context
- vl 3y ago
  Isn't it considered bad practice?
  - tptacek 3y ago
    It's already idiomatic for OpenTelemetry, and otel has use cases that overlap slog.
  - preseinger 3y ago
    yes, in general the context stores request-scoped data, whether or not the logger is a request-scoped value is a grey area and to reply to sibling comment, opentelemetry is basically a house of antipatterns, definitely do not look to it for guidance
    - tptacek 3y ago
      I don't enjoy the otel APIs, but they are implicitly scoped; contexts are a natural place to store them.
    - mdaniel 3y ago
      > opentelemetry is basically a house of antipatterns "Look on My Works Ye Mighty and Despair!" https://github.com/open-telemetry/opentelemetry-collector/tree/v0.80.0/cmd/builder#tldr https://github.com/open-telemetry/opentelemetry-collector/tr... -> https://github.com/open-telemetry/opentelemetry-collector-releases/blob/v0.80.0/distributions/otelcol-contrib/manifest.yaml https://github.com/open-telemetry/opentelemetry-collector-re... ... and then a reasonable person trying to load that mess into their head may ask 'err, what's the difference between go.opentelemetry.io/collector and github.com/open-telemetry/opentelemetry-collector-contrib?' $ curl -fsS go.opentelemetry.io/collector | grep go-import <meta name="go-import" content="go.opentelemetry.io/collector git https://github.com/open-telemetry/opentelemetry-collector"> Oh, I see. Thanks.
    - euroderf 3y ago
      "The context stores request-scoped data" might be another Go-team dogma due for course correction RSN.
      - preseinger 3y ago
        huh? there's no dogma involved here, it's just an observation of the properties of the type a context is created with each request, and destroyed at the end of it and values stored in a context are accessible only through un-typed, runtime-fallible methods -- not something you want to lean on, if you can avoid it
        euroderf 3y ago
        In practical terms there's pros & cons I guess, but in general doesn't loading a Context with session variables make code more concise and easier to understand ? DB connections, loggers, and the like. If you really want to pass around Context's in all your API signatures then at least try to make the most of it. Are pitfalls ever actually encountered ?