I guess you could roll your own... or use the one from the standard library: http://golang.org/pkg/net/http/#ListenAndServe

Incidentally, the same stack that powers dl.google.com.

Having written a few web servers (and other servers) in Go, I assure you that you will be surprised how little work it is. However, I think where Go will shine is in highly customizable "frameworks"—not in the vein of Rails etc. at all but rather collections of components you can piece together for your own needs. You can already see how this will look with the net/http library and its Handlers: just about as easy and clear as hooking in Rack or WSGI middleware/apps, but with the safety and holy-mother-of-job speed that you just don't see in Ruby or Python (okay, the speed isn't that big a deal unless you've only been exposed to Ruby...) and without Java's startup times.

Who cares about startup times for a web server ?

And with JRebel, Play or Grails you have no startup time anyway. You just hot swap the code in the JVM.

I guess you missed the part of my article about auto-scaling and restarts. The Rails app from my day job takes several seconds to come up, causing queuing and slow performance for our users. There are work arounds (idle instances, warmup requests, rolling restarts), but I personally would rather just have it start fast.

Yes. A lot.

...and it's perfectly useful for small things.

...and not really useful for serious web applications.

As the article points out, there's no real web framework for go, so the majority of things (web apps that is) written in it are toys (see http://go-lang.cat-v.org/go-code).

Most pointedly, there's no compelling structured database story, just a mess. The no-sql solutions like mgo are as good as it gets really. ActiveRecord / SqlAlchemy / NHibernate runs rings around anything that currently exists, and without it, your traditional web apps are pretty difficult to build. You'll find a lot of commentary along those lines from people who've tried.

(...but it turns out a lot of people want tiny little web servers that don't do very much, and serve json. It's great for that~)

> As the article points out, there's no real web framework for go [...]

Not true at all. As I covered in the "Go 1.1 released" thread[1], there is no "de-facto" web framework, but there are a handful of good ones: web.go, beego & Revel, to start. Think Flask, Sinatra & Django, respectively, in terms of complexity/kitchen sink.

You are right that there is no "great" ORM in the vein of SQLAlchemy/ActiveRecord, but that's partly because: a) the language is young, and b) the language attracts people that don't like the generalisations/performance issues associated with ORMs.

> ...your traditional web apps are pretty difficult to build.

What's a "traditional web app"? A CRUD app in an MVC style? Sure, you won't be able to turn something "big" around in a short amount of time like you can with Django/Rails, but difficult on the opposite end of the spectrum. You can certainly turn around something performant and scalable, and it's unlikely that you will have to strip components out to keep things fast.

You can, however, bolt together a handful of packages (again, see [1]) and go down the Flask-style route, which seems to be becoming more and more popular these days as people eschew the growing complexity of the bigger frameworks.

[1]: https://news.ycombinator.com/item?id=5702240

All you've pointed out is exactly what I've said; it's fine for small things.

> All you've pointed out is exactly what I've said; it's fine for small things.

Except that's not what I said.

Go can be used for big things on the web. Google uses it for dl.google.com; SoundCloud uses it; amongst many others.

What I am saying is that there isn't a defacto "kitchen sink" framework for Go, but this does not stop large applications from being built.

The same tools for small sites scale nicely to large ones in Go.

Your examples are things that don't use databases.

There's a reason for that.

(and absolutely, yes, for things that don't it's a totally viable solution)

> see http://go-lang.cat-v.org/go-code)

Uriel is dead. So don't link to cat-v.org as if it was an up-to-date resource.

It's roughly the same situation as node thought right? Simple HTTP server class as a first class citizen that makes the application self contained, but if you want more advanced functionality you can throw a proxy (NGINX, say) in front.

Would it be so bad to write your Go app using FastCGI? Let a real web server be the server, and build the app in a fast loading binary that can be restarted from time to time. Force session data externalization from the beginning, and have multiple instances that you can restart from time to time.

I know you can cluster Java servlet containers, but those apps tend to too often be initially architected as the "one true immortal process", stuffed full of long lived session data.

Why not. People wrote Yaws in Erlang. Let's see some web servers in Go and Rust, and compare what's more robust for parallel connections.

Erlang is a way more mature piece of software. It has been around for 27 years and most of the time it was used commercially.

I'd rather compare Rust to Erlang, than Go. At least conceptually. However the fact that languages are young shouldn't stop people from writing servers in them.