4 ms·

This doesn't look like it expands much on what the Go web server does and it also looks like it's been abandoned. Last commit was ~5 months ago from today, with

This doesn't look like it expands much on what the Go web server does and it also looks like it's been abandoned. Last commit was ~5 months ago from today, with most of the rest being 7-8 months ago and 40-something issues piled up. For some better web experiences in Go I'd check out revel[1] or gorilla[2] 1. http://robfig.github.io/revel/ http://robfig.github.io/revel/ 2. http://www.gorillatoolkit.org/ http://www.gorillatoolkit.org/

marketer 13y ago
web.go was started a couple months after Go launched, and the web server back then was much more primitive than it is now. It's meant to be a nicer interface on top of the net/http server. In reality it's very difficult an ambitious web framework (like Rails) in Go.
elithrar 13y ago
web.go is definitely pretty old/semi-abandoned. I wouldn't recommend Revel to many (it's Play heritage isn't well suited to Go, IMO) but the Gorilla toolkit—a collection of useful packages that extend net/http, rather than a full-blown framework—is exceptional. mux/pat, schema and sessions are all such useful tools and I've been working with them for a couple of months [in my spare time] as I build a web app w/ Go as a non-programmer. Some other solid Go web packages/tools: • beego (https://github.com/astaxie/beego https://github.com/astaxie/beego) - a well-maintained, active project if you want to head down the framework route. Closer to Sinatra/Flask than Django/Rails. • "Bones" (https://github.com/peterskeide/bones https://github.com/peterskeide/bones) - a useful template for an application/some good design patterns • nosurf (https://github.com/justinas/nosurf https://github.com/justinas/nosurf) - CSRF middleware that plugs into net/http (and therefore works with gorilla/mux or pat) • gorilla/context (http://github.com/gorilla/context http://github.com/gorilla/context) - request context. Great for passing per-request variables (i.e. CSRF tokens, saved forms, etc) between your middleware and your wrapped handlers. Set up some Get and Set wrappers around your specific keys so you can avoid writing out type assertions every time you want to retrieve the stored object. • go.stripe (https://github.com/drone/go.stripe https://github.com/drone/go.stripe) - a fairly complete Stripe library. • blackfriday (https://github.com/russross/blackfriday https://github.com/russross/blackfriday) - Markdown processor. Obviously, frameworks (and ecosystems...) like Flask, Sinatra, Django and Rails have an advantage in that you can get stuff done today: they do a lot for you. And, for many use-cases, performance will never be a problem. Saying that, writing HTTP logic in Go has been surprisingly easy, and the small amount of extra boilerplate you have to write (if you're sans-framework like me) is nice when you realise how darned fast your application is. Being able to deploy a single binary and front-end it with nginx also reduces a ton of complexity. PS: Once I finish this thing off over the Christmas break, I'm hoping to write up a few articles on the bits-and-pieces that took a bit of time to "get right". Also have a minimalist (i.e. wraps HandleFunc, not Handler) CSRF package in the works.
- skrebbel 13y ago
  > Being able to deploy a single binary and front-end it with nginx also reduces a ton of complexity. Just wondering, how is that different for other compiled languages, like Java/Scala (Play) or C#? You copy all jars over, optionally put an nginx in front, and off you go. And is it really that different for Ruby or Python with virtualenv? What's the added complexity there, in terms of deployment? Note, I don't really mean to be critical or something, rather I wonder whether there's some advantage of Go that I've not understood.
  - elithrar 13y ago
    > What's the added complexity there, in terms of deployment? You need to install the interpreter/runtime (and sync versions/use rbenv/etc) + you need to install your libraries + ensure that they are kept up to date (i.e. virtualenv or bundle install). A lot of this is shortcut these days thanks to rbenv, virtualenv, etc, but it's still not automatic. I can import a ton of libraries into my Go project on OS X, cross-compile a binary (`$ GOOS=linux go build`) and upload it. If I update the packages on my dev machine, it doesn't matter. Recompile, upload, restart. This goes for many languages that compile native binaries, but Go does make it really easy.
    - deckiedan 13y ago
      Don't you also have a load of static content (js, css, etc), templates, and configuration files to upload / sync as well? But yes, it does sound a bit easier.
      - Octplane 13y ago
        With some clever compilation stuff, you can also pack most static assets directly in your application (see https://github.com/jteeuwen/go-bindata https://github.com/jteeuwen/go-bindata ). This gets even more magic...
      - philips 13y ago
        We use go-bindata on etcd to build the frontend components of the dashboard into the binary: https://github.com/coreos/etcd/blob/0.2/mod/dashboard/resources/bindata-file.go https://github.com/coreos/etcd/blob/0.2/mod/dashboard/resour... https://github.com/coreos/etcd/blob/0.2/mod/dashboard/build https://github.com/coreos/etcd/blob/0.2/mod/dashboard/build https://github.com/coreos/etcd/blob/0.2/mod/dashboard/dashboard.go#L14 https://github.com/coreos/etcd/blob/0.2/mod/dashboard/dashbo...
_sabe_ 13y ago
This is Go's biggest problem right now. New libraries crop up and gets abandoned just as fast.
- cdoxsey 13y ago
  I have mixed feelings about this. On the one hand its true that there are a lot of abandoned libraries out there, but on the other Go isn't like node.js. They don't reinvent the wheel with every release, and changes have been very conservative (and they have tools to automatically upgrade your code for you). In general Go libraries are at their best when they follow the unix philosophy: Write programs that do one thing and do it well. Those programs, even after being abandoned for years, still work fine. (for example: https://github.com/dchest/siphash https://github.com/dchest/siphash) They're at their most brittle when they are highly platform dependent (like bindings to some C libraries) or massive never-finished frameworks.
twotwotwo 13y ago
From very quickly playing with it for a toy app, Revel is impressively easy to get started with. I do agree with elithrar that some things don't seem quite "Go-y" (variable names passed to Render turn into template data names...how?), and it sort of makes you say "huh" that today's 4 years of Go post mentions Gorilla and not Revel. Even in my short time playing wiht it part of me kind of wanted to go back to net/http to not use magic I didn't understand. Maybe that part would prefer Gorilla. But, anyway, if Gorilla is a better alternative to Revel, Go does not lack for decent Web toolkits. :)

marketer 13y ago

web.go was started a couple months after Go launched, and the web server back then was much more primitive than it is now. It's meant to be a nicer interface on top of the net/http server. In reality it's very difficult an ambitious web framework (like Rails) in Go.

elithrar 13y ago

web.go is definitely pretty old/semi-abandoned. I wouldn't recommend Revel to many (it's Play heritage isn't well suited to Go, IMO) but the Gorilla toolkit—a collection of useful packages that extend net/http, rather than a full-blown framework—is exceptional. mux/pat, schema and sessions are all such useful tools and I've been working with them for a couple of months [in my spare time] as I build a web app w/ Go as a non-programmer. Some other solid Go web packages/tools: • beego (https://github.com/astaxie/beego https://github.com/astaxie/beego) - a well-maintained, active project if you want to head down the framework route. Closer to Sinatra/Flask than Django/Rails. • "Bones" (https://github.com/peterskeide/bones https://github.com/peterskeide/bones) - a useful template for an application/some good design patterns • nosurf (https://github.com/justinas/nosurf https://github.com/justinas/nosurf) - CSRF middleware that plugs into net/http (and therefore works with gorilla/mux or pat) • gorilla/context (http://github.com/gorilla/context http://github.com/gorilla/context) - request context. Great for passing per-request variables (i.e. CSRF tokens, saved forms, etc) between your middleware and your wrapped handlers. Set up some Get and Set wrappers around your specific keys so you can avoid writing out type assertions every time you want to retrieve the stored object. • go.stripe (https://github.com/drone/go.stripe https://github.com/drone/go.stripe) - a fairly complete Stripe library. • blackfriday (https://github.com/russross/blackfriday https://github.com/russross/blackfriday) - Markdown processor. Obviously, frameworks (and ecosystems...) like Flask, Sinatra, Django and Rails have an advantage in that you can get stuff done today: they do a lot for you. And, for many use-cases, performance will never be a problem. Saying that, writing HTTP logic in Go has been surprisingly easy, and the small amount of extra boilerplate you have to write (if you're sans-framework like me) is nice when you realise how darned fast your application is. Being able to deploy a single binary and front-end it with nginx also reduces a ton of complexity. PS: Once I finish this thing off over the Christmas break, I'm hoping to write up a few articles on the bits-and-pieces that took a bit of time to "get right". Also have a minimalist (i.e. wraps HandleFunc, not Handler) CSRF package in the works.

skrebbel 13y ago
> Being able to deploy a single binary and front-end it with nginx also reduces a ton of complexity. Just wondering, how is that different for other compiled languages, like Java/Scala (Play) or C#? You copy all jars over, optionally put an nginx in front, and off you go. And is it really that different for Ruby or Python with virtualenv? What's the added complexity there, in terms of deployment? Note, I don't really mean to be critical or something, rather I wonder whether there's some advantage of Go that I've not understood.
- elithrar 13y ago
  > What's the added complexity there, in terms of deployment? You need to install the interpreter/runtime (and sync versions/use rbenv/etc) + you need to install your libraries + ensure that they are kept up to date (i.e. virtualenv or bundle install). A lot of this is shortcut these days thanks to rbenv, virtualenv, etc, but it's still not automatic. I can import a ton of libraries into my Go project on OS X, cross-compile a binary (`$ GOOS=linux go build`) and upload it. If I update the packages on my dev machine, it doesn't matter. Recompile, upload, restart. This goes for many languages that compile native binaries, but Go does make it really easy.
  - deckiedan 13y ago
    Don't you also have a load of static content (js, css, etc), templates, and configuration files to upload / sync as well? But yes, it does sound a bit easier.
    - Octplane 13y ago
      With some clever compilation stuff, you can also pack most static assets directly in your application (see https://github.com/jteeuwen/go-bindata https://github.com/jteeuwen/go-bindata ). This gets even more magic...
    - philips 13y ago
      We use go-bindata on etcd to build the frontend components of the dashboard into the binary: https://github.com/coreos/etcd/blob/0.2/mod/dashboard/resources/bindata-file.go https://github.com/coreos/etcd/blob/0.2/mod/dashboard/resour... https://github.com/coreos/etcd/blob/0.2/mod/dashboard/build https://github.com/coreos/etcd/blob/0.2/mod/dashboard/build https://github.com/coreos/etcd/blob/0.2/mod/dashboard/dashboard.go#L14 https://github.com/coreos/etcd/blob/0.2/mod/dashboard/dashbo...

_sabe_ 13y ago

This is Go's biggest problem right now. New libraries crop up and gets abandoned just as fast.

cdoxsey 13y ago
I have mixed feelings about this. On the one hand its true that there are a lot of abandoned libraries out there, but on the other Go isn't like node.js. They don't reinvent the wheel with every release, and changes have been very conservative (and they have tools to automatically upgrade your code for you). In general Go libraries are at their best when they follow the unix philosophy: Write programs that do one thing and do it well. Those programs, even after being abandoned for years, still work fine. (for example: https://github.com/dchest/siphash https://github.com/dchest/siphash) They're at their most brittle when they are highly platform dependent (like bindings to some C libraries) or massive never-finished frameworks.

twotwotwo 13y ago

From very quickly playing with it for a toy app, Revel is impressively easy to get started with. I do agree with elithrar that some things don't seem quite "Go-y" (variable names passed to Render turn into template data names...how?), and it sort of makes you say "huh" that today's 4 years of Go post mentions Gorilla and not Revel. Even in my short time playing wiht it part of me kind of wanted to go back to net/http to not use magic I didn't understand. Maybe that part would prefer Gorilla. But, anyway, if Gorilla is a better alternative to Revel, Go does not lack for decent Web toolkits. :)