Writing scalable App Engine applications

blog.golang.org

37 points·icey··4 comments

I always thought that choosing a language shouldn't get in your way and impact performance in the long run. I thought languages could be abstracted enough from implementation so that services like App Engine would let them be performant no matter what language you choose. But I guess this isn't the case.

When you start a new project you'll have to dedicate a good amount of time in choosing the correct language if you care about performance... too bad... hopefully one day we won't have to worry about the language getting in the way of our performance.

This depends on the cost model of the underlying resources and/or the scale you work at. For Facebook the 20% overhead of PHP of thousands and thousands of machines is significant. On GAE where startup time is expensive, Go's quick start up time is cheap. Most languages have not been created for fast startup times. They load lots of libraries in the beginning with the assumption that the app will run on forever. That's why we went from CGI to app server in the first place. With a shared resource model and dynamic load management, this is not the case anymore.

With the new pricing, using Go on app engine is likely to be costly until they add concurrency support.

I'd think they'd do that soon given Go's built-in concurrency, but last I heard Google wasn't making any promises.

http://code.google.com/appengine/articles/managing-resources... says Note: All Go instances have concurrent requests enabled automatically. then says their Python is not ready for concurrency.

A note I'd make about Go: if error handling is idiomatic Go, there should be some effort to make it less prominent, it's boilerplate.

Reply on news.ycombinator.com