← Back to the summary

Gin's Creator on Why the Framework's Simplicity Outlasted the Startup That Spawned It

When it comes to the Go Gin framework, anyone who has done web development probably knows it well, but few know the story of its birth. Here is the story of Gin, told in the first person by its original author.

It was 2014. I had just flown back to Spain from San Francisco, my head still full of unfinished dreams. My manager — who was also my startup co-founder at the time — read a few lines of my code, took off his glasses to wipe them, and said in a tone that meant "I've seen things, but you've got something, kid":

"This Gin thing is almost too simple."

I froze for a second, then smiled. Because I knew that was probably the best compliment I'd ever receive.

How It Started: A Failed Product and a Successful Tool

I was in my early twenties that year. I'd spent a year in San Francisco building SDKs for two small teams, then flew back to Spain to study "Telecommunications Engineering." I had an itch to build something, so I wrote a social network called Fyve — an interest-based one. I chose Go for the backend because Go was just starting to get some traction, and it felt like "a language you can count on, no fancy tricks."

To build Fyve, I needed a web framework. The hottest thing in the Go community at the time was Martini. Its README was beautifully written, its middleware model was elegant, and you could spin up a route and have it running in no time. But the problem was — Martini used reflection for dependency injection. This meant:

It was very "clever" — your handler could magically receive a service object without any explicit wiring code.
It was also very "scary" — when a bug appeared, you had to chase it through a pile of implicit dependencies.
More critically, all this reflection happened on every single request.

I had just watched Rob Pike's talk "Simplicity is Complicated," and one line from it was hammered into my brain like a nail:

"Simplicity" often requires more effort from the builder, but less effort from the user. "Ease" is the opposite — it looks beautiful, but over time, the debt you owe slowly comes back to collect.

Martini was the epitome of "ease." I wanted to build something "simple."

Simple Is Not Easy

Gin's design goal was straightforward: to stand right in the middle between net/http and Martini.

net/http gives you full control but barely helps you with anything. You write your own route parsing, parameter extraction, and response rendering. Every handler repeats the same plumbing work. Not hard, just tedious.
Martini gives you too much "magic." You only write business logic, and it "conjures" the rest for you. But when you need to debug, you have no idea how the magic trick was performed.

Gin's approach was very "crude" but very effective:

No reflection. All types are determined at compile time.
Only one core object: Context. It carries the request, response, path parameters, validation helpers, and rendering methods — everything you need is attached to it, and you just pass it along.

r := gin.Default()
r.GET("/users/:id", func(c *gin.Context) {
    id := c.Param("id")          // path parameter, no reflection
    c.JSON(200, gin.H{"id": id}) // response rendering, one line
})
r.Run(":8080")

There's an interesting "coincidence" about this Context design: it existed in 2014, while Go's standard library context.Context didn't arrive until 2016. When the standard library later introduced it, we kept the name gin.Context but made it implement the standard library's interface. So all existing code continued to work, and new code could use gin.Context as a standard context.Context.

This "backward-compatible intuition" came from a lesson I learned during my year building SDKs: When you design an API, you have to assume that ten years from now, someone will be making a living off it. You can't just casually change it.

Routing: A "Proper" Tree

Gin's router is also a manifestation of "simplicity." Martini matched routes by iterating over a list of regular expressions — flexible, yes, but at the cost of running a bunch of regex matches on every request, and the more complex the routes, the slower it got.

Gin's path syntax is minimal: static paths, named parameters, and wildcards. Just those three. And it's precisely this "limitation" that allowed Gin to use a radix tree for route matching — which is also why httprouter became popular in the Go community.

The benefits of using a tree:

Matching speed depends only on the length of the URL, not on how many routes you've registered.
Routes sharing a common prefix share nodes, so even with thousands of routes, memory usage stays compact.
Path parameters are pre-allocated, with no extra memory allocation pressure.

Good performance doesn't come from Gin doing something particularly "clever," but from it doing fewer things. And "doing fewer things" also makes the code easier for readers to understand.

Zero Breaking Changes, A Ten-Year Promise

What I'm most proud of about Gin isn't actually its performance, but its compatibility.

From the very beginning, I set a rule for myself: Once Gin's public API is released, it will never be changed in a breaking way.

This sounds very "hardcore," and very Go-like, but it's actually "cowardly" — because I knew all too well how many people would curse me out if I casually changed the API. So I developed a habit: before adding any new feature, I'd ask myself one question:

"Am I willing to maintain this API for ten years?"

This rule has been kept to this day. The earliest programs written with Gin ten years ago can still compile and run today. That gives me a greater sense of achievement than any benchmark number.

Later: It "Graduated"

Fyve is long gone. Gin, on the other hand, survived.

A few years later, I handed the project over to the subsequent Gin maintainers, Bo-Yi Wu and Javier Provecho. They took it over, continued to polish it, and did a better job than I could. I've always felt that the highest honor for an open-source project isn't how many stars it has, but that it no longer needs its original author's care.

Bo-Yi Wu is a full-stack Go developer. If Gin was a tree I planted in 2014, then Bo-Yi Wu is the gardener who has been responsible for watering, pruning, and pest control over the long term.

Today, Gin has roughly 90k stars and over 290,000 projects depending on it. Stars are vanity metrics; I generally don't take them seriously. But the dependency count — that represents people betting that your API won't betray them, and that bet has been winning for over a decade.

Finally, An Answer for My Manager

If my manager saw Gin today and asked me, "How is this framework so ridiculously simple" —

I would say: Because from the very beginning, it only wanted to do one thing well, and it was willing to pay a higher price for "simplicity" than for "ease."

Simple does not equal easy. But simple will outlive easy.