Hacker News new | comments | show | ask | jobs | submit login
Show HN: Gin – Golang Martini-like web framework (gin-gonic.github.io)
75 points by manucorporat on June 30, 2014 | hide | past | web | favorite | 29 comments

Real-time code reloading from the author of Martini: Gin - https://github.com/codegangsta/gin.

Quite an unfortunate choice of name.

As author of Gin, I like Gin(the drink) and the martini framework, it was a clear decision to me. I did not know about the existence of codegangsta/gin, I just discovered it with your comment :) You are right, definitely it was not the best choice.

Maybe he was referring to something like this? http://youtu.be/wDIiPIJmXcE

Maybe rename it to vermouth? :)

Maybe Gin could add a module called Martini?

Yeah, there's plenty of other alcoholic drinks this could be named after

How does it compare to Negroni + httprouter? I see Gin uses httprouter and I guess it is the main difference.

Anyway, Gin looks nice too. I like how the routing groups are done.

I used Negroni with httprouter and it is a bliss. Just a note, gin is also a codegangsta tool to live reload your Martini/Negroni app.

Of course you could use Negroni with Gin. Anyway, Gin is a full-featured framework on top of httpRouter, I will explain this later (eventually I would like to merge both in the future, removing one abstraction layer and tunning the performance).

Gin is also a better fit for httpRouter, it's not designed to fit any other framework. I wanted Gin to share the same philosophy than HttpRouter. Basically the Gin/HttpRouter community cares about performance, so you don't. For example in Gin, you can created thousands of nested groups and the performance will be still the same.

Gin is full-featured, to me it means: control flow, middlewares, error management (errors and panics both), easy rendering, easy validation, easy data passing between middlewares. For example you can collect errors (not only panics) and then send them to Sentry easily.

The control flow is interesting: if a middleware calls c.Abort(code) or c.Fail(code, message), the rest handlers in the chain would never be called, this is very useful when authorisation is required. https://github.com/gin-gonic/gin/blob/master/auth.go#L76

Of course authorisation can be just applied to a group, you can see example in the github page. Per-group middlwares and even per-request middlewares!

We added all that features without making it significantly slower (compared to httprouter) and for sure that overhead will be reduced in upcoming releases (no API changes). If you want to use HttpRouter and you also want cool features, in my opinion Gin is one of the best choices. Just try it.

I don't think Negroni and Gin will mix well</pun>

I implemented almost the same features as Negroni's middlewares [0] in my project (a backend for grassroots referendums). I was even asked to do a Sentry middleware [1] to improve it.

I would advise you against merging projects. It would be great if you separate the route grouping code and release it as an independent library to build on httprouter (even merging them) and keep Gin as it is.

Although, my question was performance-wise because I think Negroni will be similar in performance.

[0] https://github.com/imdario/minshu/blob/master/minshu-server/... [1] https://github.com/imdario/minshu/issues/1

It looks promising. However, it is making the same mistake many of the other frameworks are making in that in order to make middleware, you must take on a dependency for this framework and re-implement all middleware for this specific framework. The larger community needs to discuss and agree upon what middleware is and start using those implicit interfaces they're so fond of.

Dear god, can we please stop saying "Golang" before it's too late?

Damage is already done, just look at the comments in every HN discussion thread.

Apparently people are too lazy to write "Go Programming Language" on their searches.

hahaha, do you think so? Using "Go!" can be confusing sometimes.

Looks neat. Very I think it was a smart choice to pick an existing HTTP router. Like was mentioned above, the name was unfortunately used beforehand. https://github.com/codegangsta/gin

Thank you for your efforts. Some people may be giving you flack for "making just another Go web framework", but I wouldn't even be looking at a Go web framework if it was using reflection. Sometimes, you just don't want to pay the performance tax of reflection. I'd actually reckon that the use of reflection is a common reason for why you see alternate implementations of many libraries (i.e. JSON encoders)

Check out some middleware and a benchmark suite test at https://github.com/gin-gonic

Looks like the actual results are not updated/included in the readme though.

I will ask to the original creator of the benchmark suite to run the tests again. My development environment is very different, adding the results for Gin would mean that I should change all the results.

Just a tip, to compare martini with Gin, you can run this:

go test --bench="(Gin|Martini)"

Firefox user. I see the first chart, but all the content sections after that are blank.

thank you! I think I fixed it, does it work now?

Looks excellent! I'll be using this for a little API idea I have.

Why didn't you just contribute to Martini and fix the parts that sucked? It just feels odd to me to re-invent a web framework, utilizing the same interfaces so it's the same to people who use it, yet it's a completely different code base and project.

It seems you could have just helped codegangsta along instead of "yet another web framework in Go."

I feel that this project is very different from Martini from the low-level point of view. While Martini uses reflection to find how to use handlers, Gin utilizes a static context system. Reflection being really one of the core properties of Martini and the key part of its simplicity, this kind of changes would get rejected.

In the same kind of Martini-like web frameworks that don't use reflection, there is also Goji - http://goji.io.

I can explain that.

First. Martini uses reflection, it's IMPOSSIBLE to make it as fast as Gin without removing all the reflection. Obviously it would break all the API, it would not be Martini anymore.

Martini is not slow because a bug, it's slow by design.

Second, Gin uses the fastest http router available, HttpRouter. I strongly believe that people should use HttpRouter, it will work perfect for you unless you need regex to validate the URL. The problem is that HttpRouter is not strongly featured, it lacks things like groups, middlwares, error management, control flow, rendering...

One requirement for my startup was high performance, HttpRouter was the best choice, we added a very lightweight system on top of it, so developers are happier.

The final results, from 20x to 40x times the performance.

As I said, if you need performance and productivity Gin is probably a good way to go :) I hope it was useful.

That's fair. If the change is too big or you can't agree on the changes, there's not much to do. It may have still been possible to do a big rework of Martini or even just deprecate Martini and move to Gin...idk.

I just hate "yet another xxx in yyy" projects, but I'm not downplaying the work involved.

> It may have still been possible to do a big rework of Martini or even just deprecate Martini and move to Gin...idk.

But again, this project (Gin) is completely unrelated to Martini. Martini itself is not that old; deprecating it would be pretty poor form given that refactoring your project to work with Gin would be A Big Deal.

If the author had forked Martini your argument would have made more sense, but we shouldn't be afraid of building something new just because someone else broke similar ground before.

Well, this is a tangent anyway. The main point was "why another go web framework" then he gave a better clarification. As you watch new languages spread, it's amazing how many web frameworks pop up. It's happening to Go and Node. I also inferred that Gin intentionally mimicked the Martini API so as to have a small learning curve and be a potential drop-in replacement.

You say deprecating it is poor form, yet this guy just built a "better" version of the framework and says we should switch to it. I don't see how that's any classier than just saying "Martini sucks."

haha, as an old user of Martini, I was researching ways to improve the performance, I didn't find too much to fix without breaking stuff. Since the Golang versioning system is weak... haha obviously the main developer of Martini would not merge it.

I'm pretty sure The Changelog asked codegangsta the same thing, in this podcast: http://thechangelog.com/117/.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact