doolta

Nothing stops us from trying, though. That's partly why I built this: not because buffering is a revolution, but because the shape of logging APIs has calcified and it seemed worth poking at. The primitive I ended up needing wasn't a new level or a new name, it was a scope: a unit of work that can decide, at its end, whether its own history was worth keeping. That's not in the 25-year-old vocabulary.

Whether it's the right idea I genuinely don't know yet. But the space is emptier than it looks, and the cost of trying something is a weekend.

Small correction on the trip methods: they're not the main path. A record at or above the trip level (Error by default) trips the scope automatically and replays everything buffered under it. You don't call anything, you just log the error like you always did.

The explicit Trip(ctx) is the escape hatch for failures that never produce an error log: a 4xx you return without logging, a retry that eventually succeeded but you still want the context, a request you sampled deliberately. That's the minority case.

On config: the threshold is already a knob rather than a hardcoded level, so you can set the trip at Warn, or set what gets buffered below your emit level, from wherever your config lives. What's genuinely missing is the per-logger-name granularity you're describing, log4j-style logger.foo.bar=DEBUG. Go's log/slog has no logger registry to hang names on, so there's nothing to address by name. Scopes are the unit instead, which maps to a request or transaction rather than to a package. That's a real tradeoff and not obviously the right one for every codebase.

Exactly. That's essentially the idea.

The twist I’m exploring is to keep debug logs buffered during normal execution and only release the relevant context when an error occurs. So you get the diagnostic value of DEBUG without continuously storing all the noise.

I built a small Go library to experiment with this approach, but I’m particularly interested in where the model breaks down in real-world systems.

I bet you'll end up loving Go for the same reasons you dislike it at first.

* Simplicity (simple concurrency, readability, interfaces...)

* Static typing (errors caught at compile time)

* Error checking (tedious at first but... you'll see!)

Feynman's Law (if it had existed): "If you can’t make it simple, you don’t understand it yet. Stop shifting the complexity around like a coward and go simplify it, you absolute unit."

Hurd is still alive!!! (well, kind of)

So sad this project never got enough traction to accelerate its development pace. Maybe AI assistance will change that...

No code? No pricing? No way to audit, and no liability?

The issue I'm facing: How to get better at rambling without getting worse at coding. Because rambling is not coding, and coding is a matter of experience/practice as much as thinking.

This issue is not specific to AI: You're good at boxing so you start to teach it. But the more you teach it the less you practice it. Your muscle memory fades, your reflexes decrease, your stamina vanishes and even if your knowledge of boxing remains intact and you become a good teacher, sooner or later you come to realize you're not a boxer anymore.

How to enjoy AI-assisted productivity without losing, focus capacity, language knowledge (and the architecture/performance/security knowledge it implies) among other things?

"They fault these folks for not having any community and argue it's unreasonable for Codeberg to spend its limited CI/CD and storage resources on ghost projects."

From the beginning even GitHub was crippled by project with no community, before it got traction. I understand the cost aspect but blaming people launching their project (even with AI) is not a fair path IMHO.

I was expecting a trap, but no: Some truly useful free tools. (QR code generator, Price calculator...)

Thanks!

Furthermore, each language encourages a particular idiomatic architecture.

Guiding AI to work with that architecture, rather than fight against or simply ignore it, is still an area where we, as humans, add value.

Interesting.

I long for more hardware...