LLM tells:

> Fyve faded. Gin kept going.

> the honest version of web programming: no magic, explicit control flow, and a handler shape you can hold in your head.

> keep the request path explicit, run no reflection there, and put the boring work behind one object you can inspect: the Context.

> None of it is hard. Enough of it becomes noise.

> we didn’t rename ours — we made gin.Context satisfy the standard interface, adding full compatibility

> Params land in a small slice, the matched handler is already sitting on the final node, and the request path avoids reflection.

LLMs tend to write in this style full of short sentences or phrases separated by commas.

It's actually hard to understand what the point is at times:

> The work follows the length of the URL, not the number of routes registered in the app.

> That is the kind of performance work I trust: fewer operations on the hot path, and fewer concepts in the programmer’s head.

> The quiet goal was zero breaking changes.

Adjectives such as "honest" and "quiet" are LLM tells.

I released Gin in Hacker news more than 10 years ago! Changed my career and allowed me to meet a lot of interesting people. Thank you HN!

Congrats on the traction you’ve got with this project. We used Gin back in 2016 for a while. I honestly don’t understand those Go devs who claim that the standard library is sufficient for building a serious API — there’s still so much boilerplate, and you end up writing your own mini-framework anyway.

The main reason we don’t use it anymore is that the default handlers don’t return the error type, which means error handling and HTTP status tracking get tricky and non-idiomatic as soon as your handlers start calling functions that can fail. It’s essentially a function coloring problem.

One could argue that HTTP status is a totally separate thing from normal errors, and I get that perspective, but that’s a significant ergonomic hit to take for the sake of philosophical purity.

Thanks for the detailed walk-through @manucorporat . On designing for zero breaking changes, I see that is also a core value at Go. However, how did you actually apply it to software design and architecture? Got any resources to share here? Did you had to put more effort on other projects not running on Go to keep it also free from breaking changes?

I'm mainly building tooling in other runtimes like Rust and TS, and I'm interested to hear your take on it.

Related: Rich Hickey's 'Simple Made Easy' (2011) https://youtu.be/SxdOUGdseq4

Classic talk that still influences my design decisions today.

> You write the same plumbing for route params, request parsing, validation, and responses in handler after handler. None of it is hard. Enough of it becomes noise.

As a human, I would have written something like: > You write the same plumbing for route params, request parsing, validation, and responses in handler after handler. None of it is hard, but it makes the code noisy.

Whether or not an LLM wrote this, it's a writing style that sounds like a politician or a sophist, and it sucks.

Cool! I used gin once on a company project.

I'm not sure if I could use a framework that shares the name with an alcoholic drink in a professional setting.

Plenty of people who struggle with alcohol and who would benefit of not being reminded of it at work too.