Whenever an article about App Engine comes through here, I find myself having a strange reaction. It's a mix of surprise and curiosity. Surprise to find that AppEngine is still something that Google's putting effort into, and Curiosity as to who is actually using it anymore.

I would have thought that by now AppEngine would have already cycled through all the developers who were ever curious about it and sent them down the Official AppEngine Cycle: Curiosity, Enjoyment, Frustration, Understanding, Enjoyment, Frustration, Disbelief, Anger, Regret, Searching, Toil, then Relief (with the last few steps being part of the migration off of AppEngine and finally the knowledge that you're finally done with it for good.)

In short, I thought we'd all been burned by it already. I honestly can't imagine where they hope to find the next crop of developers from.

There's an entire class of web apps that works really well on GAE and despite the pricing changes can still be cheaper to run than the alternatives.

I'll put our own app out there http://www.eggtweeter.com as an example. It's the kind of app that needs exactly what GAE is offering in terms of scalability, requires no maintenance of any kind, we've never had to even think about infrastructure etc.

All that being said, yes there are compelling reasons to use another platform for different kinds of apps. We have some ideas for another web app that would be incredibly difficult on GAE and would probably fit in AWS or Heroku's stack better. But for what we need for eggtweeter, GAE seems to actually be a superior choice.

Here, here.

My app, http://sharedcount.com, serves ~100 million API calls a month off of AppEngine, for ~$40/month (or the equivalent of a mid-size MediaTemple virtual server).

s/Here, here/Hear, hear/g

I stopped at curiosity when I realized it was just too expensive. The data store is the big problem. Amazon S3 just slaughters it on price. The pricing is also unclear and hard to calculate, and leaves me with this lurking fear that I'm going to get surprised in a bad way.

Other than that, the app engine itself is definitely interesting. The idea of not having to manage your own infrastructure is appealing. If they could fix their pricing model and add a few features (better SSL support, ability to open raw outgoing connections, etc.) then they'd have something compelling.

Anyone know whether go can compile to NaCl binaries? I'm finding contradictory claims about this, and no detailed instructions about how to do it.

It used to be part of the early releases, but was eventually dropped of.

You can easily find this information if you search on the gonuts mailing list.

Thanks, that makes sense of the contradictory info.

NaCL support existed for a while, but NaCl kept changing and breaking backwards compatibility, so the Go team decided to drop it until it had stabilized, I think now they are mostly waiting for PNaCl as that seems to be what has most future.

I an a Rails dev and want to try something new for web development. Tempted to try Node/express or Go with one of the given frameworks. How do they compare?

Honestly by far the biggest difference between the two is the difference in underlying language. Assuming you already know JavaScript the big question you should be asking yourself (depending slightly on what other languages you already know) is, "do I want to learn a completely new language, with a rather different way of doing things". The answer to this question is far more relevant than any differences or similarities in frameworks.

Other differences include: Go actually scales in multi-core systems and completely avoids callback-hell.

Also learning to is much simpler than learning JavaScript, there are fewer pitfalls and reading the spec is easy.

All network IO in go is non-blocking. Channels and goroutines avoid the nested callback mess. Go is also a better designed language than JS.

Gorilla[1] provides nice libraries for web development in Go.

[1]http://gorilla-web.appspot.com/

Sounds good—I had this feeling too about Go vs Node

Neat... Do the templates still use jinja? How does that work..

Go is not Python, and Go has its own templates package as part of the stdlib (but others also exist):

http://golang.org/pkg/text/template/