Edit: Just discovered [Martini](https://github.com/codegangsta/martini), that's exactly what I wanted.
That's where I say NO. go's reflect package is slow and a nightmare to use. Go's JSON parser, which uses reflect, is 2.5x slower than Node.js (in my own benchmarks [1]). And Go 1.1 was 3.5x worse that Node.js at parsing JSON. Again, those are my benchmarks, but they seem consistent with what other people are finding (from my Googling around).
I would not make this trade off, I would not use reflect on EVERY request, just so that my request handlers are compatible with http.HandleFunc. It almost seems silly to do that. That's why other frameworks (like Revel) are using custom Request objects.
However, I do understand why the author is emphasizing this feature. If your handlers are incompatible with http.HandleFunc (i.e. if they take a custom Request object), you need your own Router which invokes the handlers, and you need your own ServeMux, so you end up giving up on a lot of functionality from net/http. That's why Revel has a ton of custom objects that mirror what net/http has and it proxies method calls.
So you keep wondering: "why the hell am I writing so much seemingly unrelated code? I just want to add a 'user' property to each request, but now I've coded so many struct's and created so many files". It makes you feel unproductive and it bloats the code.
Again, I've made my choice, but you should be aware of such caveats and, of course, benchmark things yourself.
1) My benchmark results. For some charts, higher is better, for others, lower is better. Use your judgement. http://goo.gl/xfWFXo
How's the performance? I'm a little afraid of the "reflection" boogeyman, but I don't have any experience to say what kind of impact we're talking about here.
I'm coming from Rails day-to-day, and a very light, compiled Go web backend is a refreshing change of pace. I'm leery of giving up the simplicity of net/http, but if it stays small maybe it's the way to go. Right now I'm popping in gorilla toolkit, though, so if martini is as "light touch" as that, I'd be up for using it.
BTW, great work, that's exactly what I was looking for.
[1] http://gruntjs.com/ [2] https://github.com/gruntjs/grunt-contrib-watch
https://github.com/codegangsta/dotfiles/blob/master/vim/vim/...
I've even made it rewrite (eradicate) templates that don't compile (threats).
https://github.com/aybabtme/brog/blob/master/brogger/templat...
At this point, the code is kind of messy, so please overlook that. I also have a bare deployment on an t1.micro : http://www.antoine.im/
Just trying to express the same redneckbeard said: until it is a very thin bottleneck, this should be no problem.
1) I didn't want routes in a text file. This is whiny, I know. Just a personal preference. 2) Go is the only programming language that has held my attention long enough to actually finish a fairly usable framework. Writing a framework is a good exercise in software design, so I felt like I had to use the opportunity.
I ask because I am looking to put my weight behind a framework and am undecided, but not at all attracted to Revel...
Lots of people have abandoned Rails for Sinatra, or Django for Flask. That's totally cool, and there are good reasons to do so. There are also very good and obvious reasons to use something that further abstractions common patterns if the software you are building conforms reasonably well to those patterns.
But in 2013 do I really want to use server side HTML tempalating? Why not just connect a webservice to a HTML/JS presentation layer like I am suggesting? If all you are doing is building a webservice then the abstractions beyond net/http + Gorilla are not buying you much IMHO, but they do come at quite a performance cost: http://www.techempower.com/benchmarks/#section=data-r7&hw=i7...
My first couple Go web applications did things the html/template way and were structured on the way I used to go JSF applications- but since I switched to the above approach my projects have been better performing, faster to develop , better scaling and easier to maintain. As we all know, we seldom get all those things in one technology choice without trade-offs.
I personally have seen a great improvement in code simplicity, readability, and overall DRYness when projects are written using Martini.
Choosing a framework isn't about following some sort of socially acceptable way to build your web apps. Just build them! If a framework solves a problem for you then use it, otherwise keep using net/http handlers.
