Agreed - if you're new to programming in Go, I'd recommend using the standard library (supplemented by Gorilla[0] once you get the hang of things).

If things start getting unwieldy as your app grows, you can always try out something like Revel, but by starting with the standard library (which already has a very clean web server built-in), you'll get a sense for the way things work "under the hood" early-on.

If you want to see how a Go web server built with just the standard lib + Gorilla looks, I wrote a simple sample application a while back: https://github.com/ChimeraCoder/go-server-bootstrap . The most verbose part is the oauth2 callback.

I should get around to updating it (it still even uses a Makefile! Eek!), but it gives the basic idea.

(Sidenote: When did Github stop supporting the ".markdown" extension instead of just ".md"?)

[0] http://www.gorillatoolkit.org/

web.go provides a request context, some helper functions (Slug, Urlencode, etc) and so on. pat (if you mean http://www.gorillatoolkit.org/pkg/pat) is "just" a mux/router—although a really nice one.

However, gorilla/pat + gorilla/context + gorilla/sessions* are, IMO, much more flexible than web.go and don't unnecessarily rewrite the wheel as much as web.go tries to. They also plug together easily: there's really no "glue" you have to manage. Just import them and use them as you would.

* web.go pretty much forces you to use cookies. gorilla/sessions can use a cookie store, a filesystem store, Redis (my pick) or the other stores out there (CouchBase, mySQL) thanks to the store API the package provides.

Web.go was around a long time before pat. You're right, though, they're very similar to each other.

I didn't see whether this library handles a middleware layer, but that is the reason I use Slim for my web applications despite PHP having first class support for that sort of stuff already.