Just log to sqlite. It’s literally better than all the alternatives, but for some reason nobody does.
Structured logging with slog
91–100 of 174 posts
Re: Structured logging with slog
#92With this another most requested feature is covered by Go. This leaves error handling, enum type which are often asked by users but are not actively being worked on for now.
The lack of Error Handling in Go is a feature, not a bug. See here: https://go.dev/doc/faq#exceptions . I think I'd be disappointed if Try/Catch ever made their way into the language.
Great, so Go has support for native stacktraces so bubbled errors don't get shadowed?
Just because Go made opinionated design decisions around their error handling a decade ago when developing the language doesn't mean that there's not practical room for improvement as the language is widely in production and shortcomings in its error handling have been found.
The number of hacks I've seen over the years to try and solve the "wait, where did this error originate" problem in Go are legion, with little standardization.
And no, using Errorf with '%w' to wrap error messages along the stack isn't exactly an elegant solution.
Even if they want to keep the core error behavior as it is for compatibility, providing a core library way of wrapping with stacktraces would be a very useful next step, particularly given the most popular package doing that previously is now unmaintained.
Re: Structured logging with slog
#93Earlier quoted context omitted.
The lack of Error Handling in Go is a feature, not a bug. See here: https://go.dev/doc/faq#exceptions . I think I'd be disappointed if Try/Catch ever made their way into the language.
Yeah I have to agree that the Go-style error handling does actually lead to better code. At least when I write it. It makes me think through how I am going to handle error states rather than chucking it in try/except in Python and hoping nothing breaks lol.
Rust-style error handling works better though - similar to Go, but with the addition of enums such that the precise types of errors which may be encountered can be easily documented in the type system.
Re: Structured logging with slog
#94Earlier quoted context omitted.
The lack of Error Handling in Go is a feature, not a bug. See here: https://go.dev/doc/faq#exceptions . I think I'd be disappointed if Try/Catch ever made their way into the language.
Great, so Go has support for native stacktraces so bubbled errors don't get shadowed? Just because Go made opinionated design decisions around their error handling a decade ago when developing the language doesn't mean that there's not practical room for improvement as the language is widely in production and shortcomings in its error handling have been found. The number of hacks I've seen over the years to try and s…
>And no, using Errorf with '%w' to wrap error messages along the stack isn't exactly an elegant solution.
I don't think anyone has ever claimed otherwise. But I do think its a pretty good solution. Whats elegance worth, anyways?
Re: Structured logging with slog
#95Earlier quoted context omitted.
Nice middleware package. I have to admit, the `log.InfoContext(ctx,...` style of redundancy that permeates the standard lib at this point is really gross, especially given that the most common use case for go is going to have contexts everywhere.
Go’s decision to not support function overloading leads to a tonne of really ugly APIs. Obviously every decision in language design is a tradeoff, but IMO they made the wrong call here.
I'm not sure how I feel about this. What are the actual consequences of these apis being "ugly"? Like, why does that matter?
Re: Structured logging with slog
#96Earlier quoted context omitted.
That seems like a problem that should be solved. Logging structured data is a very basic expectation.
This is structured logging. Stubbornly insisting that "structured logging" === "map" is dumb and ignores a large fraction of use cases where performance matters.
Are there languages that solve the “performance“ problem with maps? In fact, isn’t Go one of them?
Re: Structured logging with slog
#97The new structured logging library is a great addition, its nice to have structured logging in the standard lib. It's easy to get started with log/slog and one of the built in handlers, but as soon as you want to change something the library design pushes you towards implementing an entire handler. For example, if I want the built in JSON format, but with a different formatting of the Time field, that's not easy to d…
Nice middleware package. I have to admit, the `log.InfoContext(ctx,...` style of redundancy that permeates the standard lib at this point is really gross, especially given that the most common use case for go is going to have contexts everywhere.
The -Context suffix is only needed when something existed before Context was created. New stuff should be just `foo.Bar(ctx, ...)`
Re: Structured logging with slog
#98Just log to sqlite. It’s literally better than all the alternatives, but for some reason nobody does.
That'd be a slog.Handler, not a reason to avoid the new standard API.
Re: Structured logging with slog
#99I wish there was a better approach for the problem of avoiding function calls when the log level at runtime is higher than the call site. So, slog.Info("failed to frob", "thing", GetThing(1)) Still calls GetThing(1) when the log level is greater than Info. The only solution right now for this is to test the log level before making the logging call. It would be amazing if language designers could make the arguments la…
Re: Structured logging with slog
#100Earlier quoted context omitted.
Go’s decision to not support function overloading leads to a tonne of really ugly APIs. Obviously every decision in language design is a tradeoff, but IMO they made the wrong call here.
I'm not sure how I feel about this. What are the actual consequences of these apis being "ugly"? Like, why does that matter?
To me, at least, it is like listening to a person who constantly says "uh..." while talking. Occasionally, sure fine. But it's so pervasive in commonly used APIs that it becomes annoying.
Let's be clear: this is just a peeve of mine.