GoKawiilIn 2014 I came back from San Francisco with no plan and one useful scar: I had seen what small software teams needed from their tools. I had spent a year building SDKs at Joypad and TinySpark after shipping one of my first games. Then I was back in Spain, about to start Telecommunications Engineering, and trying to decide what to build next.
The answer was Fyve, a social network built around people’s interests. I chose Go for the backend because the language felt plain in the right way. Gin started as the web framework for that product, written while I was still learning Go and still deciding what kind of engineer I wanted to be. The code lives at gin-gonic/gin.
Fyve faded. Gin kept going.
Simple over easy
At the time, the Go web framework people kept pointing me to was Martini. I understood why immediately. The README was small, the middleware model felt elegant, and you could get a route responding in minutes.
Martini used reflection-based dependency injection to wire handlers together. That made the first demo feel smooth. It also moved important behavior out of sight. Services appeared in handlers by magic, control flow became harder to trace, and reflection ran on the request path.
I was reading the Go community through Rob Pike’s Simplicity is Complicated lens around then. The line that stuck with me was not a slogan about minimalism. It was the cost model: simple software often takes more work from the person building it so it can take less work from the person using it.
That became the design line for Gin. Easy is what looks good in the first example: fewer lines, nicer syntax, less ceremony on the page. Simple is lower count: fewer moving parts, fewer concepts to learn, fewer exceptions to remember. Martini made the first version easy. I wanted Gin to stay simple after the codebase was old enough to surprise me.
Finding the middle ground
Aristotle’s version of virtue was the middle ground: not too much, not too little. That was the shape of the framework problem too.
... continue reading