
Writing scalable App Engine applications - icey
http://blog.golang.org/2011/11/writing-scalable-app-engine.html
======
sktrdie
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.

~~~
toddh
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.

------
DennisP
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.

~~~
Detrus
[http://code.google.com/appengine/articles/managing-
resources...](http://code.google.com/appengine/articles/managing-
resources.html) 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.

