It certainly indicates that Go is the language you should probably be using on AppEngine, given that you pay for resource (CPU, memory, etc) usage, and Google themselves are optimising Go to minimise that same usage for their own systems.
I'll try again with something I don't intend to turn into a business. Writing various daemons, tools and helpers in Go has been great, though.
Well, it covers:
Serving (great built-in server for net/http)
Routing
Sessions
Context
--
It's missing:
Authorisation
Authentication
Parameter Validation/Checking
Asset management
Migrations
Cleaner templating (I prefer mustache to the built-in go templates)
HTML Helpers/View Helpers
Form Helpers
ORM or other persistence helpers (controversial I know)
Possibly scaffolding would be nice too and a suggested project structure to encourage sharing
--
So there are a few things which you'd generally expect in a web framework which aren't there yet. Of course some of the above list is subject to debate, some is available in revel, some it not everyone would agree is even necessary, but most other platforms in other languages have a bit more to help you, even if they are minimalist. Even just having an agreed-upon set of conventions and structure for web projects (a la rails), speeds up comprehension when looking at any large code-base.
I'm quite confident Go will get there, and having tried it out am really impressed with the language and the culture, but it would be disingenuous to suggest it has everything you'd need to produce large web apps currently - at present you have to write your own code for quite a lot of the above.
By the time you get to crud admin and plugins, you're at the point where the benefits of the framework start to come with significant additional costs (in maintenance, flexibility, comprehension etc). A pre-built app or plugin gets you up and running quickly but when you start to modify it you really need to understand the entire app/plugin before you can do so efficiently. Often people feel this is as significant a roadblock as simply writing it from scratch in the first place.
Any complex webapp is probably going to outgrow standard admin/scaffolding, and any complex usage is going to require modifications of things like plugins and gems, so while they're nice to have in an ecosystem I don't see them as essential. This is an area where django has more built-in that say rails though, and it'd be interesting to see a Golang framework trying to take the best ideas from all these other popular frameworks.
I would agree if the components were tightly coupled, but Django is very well structured to let you substitute any component. At any rate, it's much better than writing everything yourself outright, and I'm speaking as someone who has launched more than 10 Django-based products.
That said, I really want to try out Go...
Out of curiosity, why do you prefer Mustache to Go templates? They seem extremely similar, with Go templates being slightly more powerful due to easy-to-add template funcs. Both are essentially data-driven though.
Re Mustache versus go templates, I preferred the restrictions and clarity of mustache, because it forces you not to put any code in the view, all you can have are the basic constructs it provides, but it doesn't miss anything major IMHO. Here are the things I needed, which it provides:
* loops
* partials (with the neat {{> partial}} syntax
* nested contexts
* escaping by default
* clear named keys, no '.' prefix, though I guess . would be OK between keys for subkeys (not possible in mustache as yet)
* limited contexts (so that it's obvious what is being called)
The differences are not major, and frankly either is a fine choice, but I actually preferred the limited syntax of mustache, and found the go template setup needlessly complex, in particular when including partials, I didn't spend too long on the decision though so perhaps I just misunderstood...
So add me to the list of people who'd like to see something comparable on Go.