Structured logs are great… until you actually have to read them in dev

ynotvim · 2026-02-27T14:32:14+00:00

There are a bunch of slog handlers or formatters for human reading. Even if we don't need more, it's a fun little probject to write. I learned a lot about slog (and Go) by writing one. Mine makes the output look like this:

 INFO | Request processed | sku=24A2 branch=manhattan time="2023-04-02T10:50.09 EDT"
ERROR | Connection failed | time=2024-01-23T17:14:03Z

There's also a popular one that adds color: https://github.com/lmittmann/tint.

ynotvim · 2026-02-24T18:45:24+00:00

For details as well as upgrade guides for humans and LLMs see...

I'm not criticizing in any way, but to me it's still weird to think of things this way. I'm sure it's the future (LLMs writing code, and then writing docs and READMEs for other code to consume), but it just feels...weird.

ynotvim · 2026-02-20T15:56:14+00:00

Is a great book: beautiful writing, brilliant authors.

However, it's not for a beginner (which the OP specifically asks for), and as other commenters have said, it's significantly out of date in many ways.

ynotvim · 2026-02-20T01:05:17+00:00

Always start by checking the docs for the standard library: https://pkg.go.dev/std.

It sounds like you want this: https://pkg.go.dev/slices.

ynotvim · 2026-02-19T16:49:14+00:00

Ah, sorry. I guess that means that I don't browse r/lua actively enough. Good luck with the project.

PS I saw it on Lobste.rs, in case you want to weigh in there.

ynotvim · 2026-02-19T15:05:42+00:00

This is not my project, but it may interest people here. The elevator pitch: "Static LuaJIT runtime with batteries."

ynotvim · 2026-02-19T00:33:34+00:00

Yes, it's a little confusing. Here's my understanding, which may not be exact.

The go fix command has existed since Go was pre 1.0. Originally, it was gofix. It was created to help users deal with rapid changes at the time. This is in 2011.
Then in 2012, Go announces a compatibility promise. That pretty much makes gofix useless.
From 2012-2025, gofix stayed as it was, effectively doing nothing. Other analysis-based tools are developed (go vet, staticcheck, etc.)—more for linting code than for fixing API changes.
2026 go fix is back. The compatibility promise is still in place, but there have been important new features and API additions to Go in the last several years. go fix helps users to modernize their code, even though the old code would continue to work.

tl;dr: the new go fix is 100% rewritten. Even if you had heard of the old one, this one is effectively new. The code is new, and the purpose is importantly different. Instead of changing things that wouldn't otherwise work, it modernizes things that would continue to work (because of the compatibility promise).

ynotvim · 2026-02-17T18:01:28+00:00

From the post (something I wouldn't have guessed right away): "Running the command more than once also provides opportunities for synergistic fixes, as we’ll see below." It makes sense once I think about it, but I am glad they discuss it, so I figured I would flag it for others.

ynotvim · 2026-02-17T17:53:42+00:00

In fairness, the (built-in) separate command is new too. From the linked blog post: "The 1.26 release of Go this month includes a completely rewritten go fix subcommand."

ynotvim · 2026-02-17T17:25:50+00:00

Not trying to do a gotcha or anything, undo-branches/time traveling is just a really powerful vim feature that I love

Totally fair: it's a great feature.

ynotvim · 2026-02-17T15:43:27+00:00

The author knows that.

My personal view is that the vim undo and redo behavior is the best and most human friendly option. Undo and redo are predictable and you can predictably intersperse undo and redo operations with other operations that don't modify the buffer, such as moving the cursor, searching, and yanking portions of text.

He's not complaining about Vim. He's arguing that POSIX (and some other recent Vi-like editors) should not limit undo/redo to the behavior of original Vi.

ynotvim · 2026-02-17T15:41:36+00:00

By "mess," I think he means that the POSIX standard for Vi specifies the (less useful and very limited) behavior of original Vi for undo/redo. He's arguing that Vi-like editors in active development should ignore that part of the POSIX standard for Vi. He has another recent post about current Vi-like editors that makes similar points.

More broadly, he's trying to talk about what system-level defaults should look like in 2026, even (especially?) when those defaults are based on things first written in the 70s. In the earlier post that I linked, he talks about systems that still insist on original vi and the old Bourne shell.

ynotvim · 2026-02-17T15:36:52+00:00

I think you're missing the point of the article. The article isn't about the code of any particular Vi-like editor. The author is arguing in general that Vi-like editors under active development should not follow the POSIX standard for Vi and insist on the undo/redo behavior of Bill Joy's original Vi. Instead, they should be more like Vim since its undo/redo behavior makes far more sense for users.

ynotvim · 2026-02-16T18:43:42+00:00

What a terrific site! I can't wait to share it with my wife, who loves rainbow cookies. (We lived near Bonelle for years. Rainbow cookies were definitely not their best thing, but this still brings back happy memories.)

I vote for the Bronx next. Morrone is a classic. (My wife loves that you can get a piece there that is cut like a slice of cake.)

ynotvim · 2026-02-16T16:03:04+00:00

See also: https://gustedt.wordpress.com/2026/02/15/defer-available-in-gcc-and-clang.

ynotvim · 2026-02-16T00:01:00+00:00

Plus a related recent blog post talking about different ways to implement defer in C.

https://antonz.org/defer-in-c/

ynotvim

TROPHY CASE

Welcome to Reddit,