Do people really want to roll their own Webservers in Go? That's like a lot of work and sounds like disasters waiting to be happening. Sure it has potential, but I'll wait till something mature comes along and then use that. In mean time if you want to get of Ruby, I'd use something proven and fast like Java. There's really nothing wrong with Tomcats.
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.
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.
...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.
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.
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.