4 ms·

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

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."

alixaxel 12y ago
I'm pretty sure The Changelog asked codegangsta the same thing, in this podcast: http://thechangelog.com/117/ http://thechangelog.com/117/.
Artemis2 12y ago
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 http://goji.io.
manucorporat 12y ago
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.
- brianbarker 12y ago
  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.
  - manucorporat 12y ago
    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.
  - elithrar 12y ago
    > 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.
    - brianbarker 12y ago
      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."

alixaxel 12y ago

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

Artemis2 12y ago

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 http://goji.io.

manucorporat 12y ago

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.

brianbarker 12y ago
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.
- manucorporat 12y ago
  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.
- elithrar 12y ago
  > 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.
  - brianbarker 12y ago
    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."