Unless I'm mistaken about recent advancements, Python belongs in the same performance category as Ruby, Perl and PHP i.e. slow compared against native or optimized managed languages.
I understand there are a number efforts underway to improve performance (e.g. using an LLVM backend with http://code.google.com/p/unladen-swallow/), but I don't think this is actually being used yet? I'm sure with having Guido onboard Python has been heavily optimized for GAE but there is only so much optimizations possible with CPython. The library code may be fast (i.e. thin wrappers over C libs) but the users code is going to be interpreted and slow. Since it impacts the performance of Chrome (one of Google's most valuable assets) and its millions of end users, I would think that more of Google's engineering effort is behind making JavaScript as fast as possible with V8 which I believe shows in the computer language shoot-out benchmarks, where it looks as if V8 is several times faster than any Python implementation available: http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php?v8=on&python3=on&calc=chart The GAE Python API's also exposes sync IO requests and encourages buffering which I believe also contributes a significant performance penalty per request. This is only an educated guess and I'm not sure what these raw language numbers translates in GAE performance though it should be pretty indicative of the perf advantages possible. With the lack of an actual V8 implementation, internal Google Engineers would have the best insight as to the potential gains if any (which I encourage on this thread). As for the language impedance mismatch, I think that having code from the same application being able to run on both client and server is heavily underrated. YUI is show casing some exciting possibilities they're doing around node.js today: http://www.slideshare.net/apmoore/running-yui-3-on-nodejs-bayjax Where currently a lot of their JavaScript libraries already run on node.js, but even more impressive than that they have implemented a server-side W3C DOM that enables the same code they use do generate their DHTML Calendar control can be run on the server and output rendered on clients that have JavaScript disabled. Much of Google's Closure Library and its optimized JavaScript compiler should be able re-used on the server as well. I think this is only touching the ice berg, and Douglas Crockford has an inspirational video presentation on using JavaScript and an event-loop architecture (like node.js) on the server: http://developer.yahoo.com/yui/theater/video.php?v=crockford-loopage Before V8 and node.js I would not have considered it, however with the maturing of these technologies, the plethora of well-tested JavaScript frameworks and libraries available and what I believe is a rejuvenated look back into JavaScript - I think there has never been a better time to provide a server-side JavaScript option in GAE. - Demis On Sun, Oct 10, 2010 at 11:10 PM, John McLaughlin < [email protected]> wrote: > My gut reaction to this is that I'd rather have Python 3 over server > side JavaScript. The Python API is already comparable to (and > possibly faster than) the Java API. See http://gaejava.appspot.com/ > and > http://stackoverflow.com/questions/1085898/choosing-java-vs-python-on-google-app-engine > . > So the performance argument is arguable at best. Additionally I don't > think the value of a tight developer community can be underestimated. > In particular I find these forums to be a huge benefit for learning > best practices, tips, and tricks. But I fear that introducing another > language -- and especially JavaScript, with it's tower of babel of > libraries and coding styles -- would decrease the signal to noise > ratio of the forums and the developer community. And that would > affect my productivity more than "language impedance". > > Don't get me wrong -- I really, really, like JavaScript. It's an > awesomely creative language for making highly functional user > interfaces. But I really, really like Python as well -- mostly > because it is so clear, readable, predictable, and mostly has only one > right way to do things. This seems like a better language choice for > server. At least until GO (http://golang.org/) catches on ;-) > > John > > > On Oct 10, 1:16 pm, Demis Bellot <[email protected]> wrote: > > Thanks for the link, I just added a little excerpt from my post to the > list. > > > > I think the fact that so many other devs are coming to the same > conclusion > > independently speaks of how favourable a JavaScript for GAE solution is. > > > > I'm sure if Google released a poll to gauge public interest about it, you > > would get an positive response from the dev community. > > > > Here's hoping for some positive steps in exploring the idea. > > > > - Demis > > > > On Sun, Oct 10, 2010 at 8:29 PM, Robert Kluin <[email protected] > >wrote: > > > > > > > > > > > > > > > > > I think it would be interesting too. Star issue 35. > > >http://code.google.com/p/googleappengine/issues/detail?id=35 > > > > > Just please do not post a "+1" or "me too" type comment, a star is > > > sufficient. > > > > > Robert > > > > > On Sun, Oct 10, 2010 at 14:56, Demis Bellot <[email protected]> > > > wrote: > > > > Hey All, > > > > Love what you guys have created with Google App Engine although > > > > I'm surprised that you haven't offered JavaScript as a target > language > > > yet. > > > > It's a ubiquitous language known by most web developers and is one of > the > > > > primary languages engrained into Google's DNA as you already provide > a > > > great > > > > runtime for it in V8. The success of node.js/expressjs should prove > that > > > it > > > > is a viable server platform with a willing community. > > > > The way I see it a V8-powered JavaScript hits a sweet spot: I imagine > it > > > > would be faster to run than Python (my major gripe against it) and > more > > > > terse, expressive and functional than Java (my major dislike). As > most > > > gae > > > > apps are websites, JavaScript also reduces the impedance language > > > miss-match > > > > as it will allow you to use the one language for both client and > server. > > > I > > > > would imagine that the per-request model of gae would also be better > > > suited > > > > for JavaScript as opposed to the high start-up cost and long-running > > > nature > > > > of Java. > > > > What do you guys think? I'm sure it's not the first time this has > been > > > > suggested, as it seems like a natural choice. > > > > > > -- > > > > You received this message because you are subscribed to the Google > Groups > > > > "Google App Engine" group. > > > > To post to this group, send email to > [email protected]. > > > > To unsubscribe from this group, send email to > > > > [email protected]<google-appengine%[email protected]><google-appengine%2Bunsubscrib > [email protected]> > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/google-appengine?hl=en. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Google App Engine" group. > > > To post to this group, send email to [email protected] > . > > > To unsubscribe from this group, send email to > > > [email protected]<google-appengine%[email protected]><google-appengine%2Bunsubscrib > [email protected]> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-appengine?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-appengine%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
