101–110 of 174 posts
Earlier 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.
The -Context suffix is only needed when something existed before Context was created. New stuff should be just `foo.Bar(ctx, ...)`
Earlier 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…
What eventually became the standard library error wrapping proposal evolved from the work done on the Upspin project. It did include stacktraces, and believed like you that it would be useful to have them. But analysis of the data showed that nobody ever really used them in practice and, for that reason, was removed from the final proposal.
> particularly given the most popular package doing that previously is now unmaintained.
Lacking wide appeal doesn't mean there isn't a niche need, of course. However, with the standard library accepting a standard for error wrapping, which this package you speak of has been updated to be compatible with, what further maintenance would be needed, exactly? It would be more concerning if it wasn't considered finished by now. It seems the solution for niche needs is right there.
Earlier quoted context omitted.
The -Context suffix is only needed when something existed before Context was created. New stuff should be just `foo.Bar(ctx, ...)`
Isn't slog, like, completely new as of this release?
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
Are there languages that solve the “performance“ problem with maps? In fact, isn’t Go one of them?
In this use case using maps doesn't solve any problem, requires at least one allocation, and requires hashing each key. This is not even an interesting discussion.
Earlier quoted context omitted.
I’ve seen it mentioned before, but I haven’t given it a demo yet. To be honest I wasn’t sure if TUI was the right UI for something like this, as it can’t pull off all of the things a GUI can. It’s not that I have a TUI allergy either (I can’t live without lazygit).
lnav is neat but doesn't really do structured logging AFAICT, just predetermined fields for the format.
I'm iterating on a log pretty printer that accepts structured logs in a pipe and does things like color coding, adding terminal-recognized vscode:// hyperlinks for call stacks, smart wrapping based on the terminal width, and special formatting for panics and stuff.
NCurses is probably coming in a couple months.
Does anything like this already exist?
Earlier quoted context omitted.
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…
> providing a core library way of wrapping with stacktraces would be a very useful next step What eventually became the standard library error wrapping proposal evolved from the work done on the Upspin project. It did include stacktraces, and believed like you that it would be useful to have them. But analysis of the data showed that nobody ever really used them in practice and, for that reason, was removed from the…
I see this all the time:
main.go:141 error: could not transmogrify the thing: a144cd21c48
main.go:141 error: not found
But this would be amazing:
main.go:141 error: not found callstack=...I'm really glad they've introduced this, I just wish it also had the traditional formatting methods, eg Infof, Debugf, Errorf, etc, for backwards compatibility. I've got a few packages that accept a basic logger interface, eg: type debugLogger interface { Debugf(format string, args ...any) } type MyThing struct { logger debugLogger } func New(logger debugLogger) *MyThing { return &MyThing{logger} } I'd love to switch…
I would defend slog's decision there. Infof/Debugf/Errorf are like fine especially when I'm making a little CLI tool for myself, but my main consumption of logs at work is other peoples' logs via a cloud log aggregator, and so when you give other devs who are not me Sprintf they start to do things like "[%s] default/%v - %v" or so, which makes sense to them but doesn't give me great strings to search for when I'm try…
Earlier quoted context omitted.
I’ve seen it mentioned before, but I haven’t given it a demo yet. To be honest I wasn’t sure if TUI was the right UI for something like this, as it can’t pull off all of the things a GUI can. It’s not that I have a TUI allergy either (I can’t live without lazygit).
lnav is neat but doesn't really do structured logging AFAICT, just predetermined fields for the format.
Earlier quoted context omitted.
Have you checked lnav?
I’ve seen it mentioned before, but I haven’t given it a demo yet. To be honest I wasn’t sure if TUI was the right UI for something like this, as it can’t pull off all of the things a GUI can. It’s not that I have a TUI allergy either (I can’t live without lazygit).