I think a new language should be out of the question, well until current platform is stabilized. But .... then again who am I to tell big G what to do and what not. ;-)
On Oct 11, 10:06 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com> wrote: > 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 < > > > > > > > > johnmclaugh...@massanimation.com> 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 <demis.bel...@gmail.com> 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 < > > > > johnmclaugh...@massanimation.com> 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 <demis.bel...@gmail.com> 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 < > > robert.kl...@gmail.com > > > > >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 < > > demis.bel...@gmail.com> > > > > > > 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 > > > > google-appeng...@googlegroups.com. > > > > > > > To unsubscribe from this group, send email to > > > > > > > google-appengine+unsubscr...@googlegroups.com<google-appengine%2Bunsubscrib > > > > > > > e...@googlegroups.com><google-appengine%2Bunsubscrib > > e...@googlegroups.com><google-appengine%2Bunsubscrib > > > > e...@googlegroups.com> > > > > > > . > > ... > > read more » -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
