Believe it or not, we've talked about this. There's a lot of interest in V8 and JavaScript. From a technical standpoint, there are still advances that need to be made in V8 (garbage collection comes to mind) - see for yourself by searching for articles about Node.js and GC.
Ultimately, it comes down to resources, which is probably why we aren't working on this right away. It makes more sense for us to harden our Java and Python runtimes, allow more classes into the whitelist, and look into ways we can support versions of Python that are higher than 2.5. As much traction as Node.js has in the blogosphere and Hacker News, it's still hard to make a business case for a platform that has, at best, poor tooling and a small (albeit enthusiastic) core community. You have a gripe with Python being slow - I'm surprised this is an issue, as most of your time is spent blocking on RPC calls, not interpreter gotchas. It doesn't matter how fast your Ferrari is if there are stop signs on every block. I'd look into Heroku's experimental node.js support: http://blog.heroku.com/archives/2010/4/28/node_js_support_experimental/ Try building an application using node.js as your full application stack. I'd love to see more article content about the challenges/benefits of doing this. There isn't enough, as far as I am concerned. -- Ikai Lan Developer Programs Engineer, Google App Engine Blogger: http://googleappengine.blogspot.com Reddit: http://www.reddit.com/r/appengine Twitter: http://twitter.com/app_engine On Sun, Oct 10, 2010 at 8:46 PM, John McLaughlin < [email protected]> wrote: > Thanks for the info Demis, I alway like listening to Douglas > Crockford. I also checked out > http://developer.yahoo.com/yui/theater/video.php?v=glass-node. > Very interesting stuff, I can definitely see using it in the future. > In particular using JavaScript as the templating engine seems really > powerful. So you've changed my mind. However since I'm still worried > about the "plethora" part of "...plethora of well-tested JavaScript > frameworks and libraries available...", I'll say that if node.js, > YUI3, and JSLint are defined as best practices -- I'm on board -- > server-side JavaScript all the way. > > - John > > On Oct 10, 4:21 pm, Demis Bellot <[email protected]> wrote: > > 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 withhttp:// > 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... > > > > 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. Seehttp://gaejava.appspot.com/ > > > and > > >http://stackoverflow.com/questions/1085898/choosing-java-vs-python-on. > .. > > > . > > > 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]><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]><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.
