But the async limitations are not because of python or java, just the restrictions of the runtime (appengine). I would imagine the same async limitations would apply to any other language.
T On Oct 12, 5:24 am, Demis Bellot <[email protected]> wrote: > Cool, though Ringojs is no Expressjs and ultimately if I'm not mistaken all > calls will eventually goes through Java's Sync IO and standardized API's no? > > I'm not sure why Java data access is slower than Pythons > (http://gaejava.appspot.com/) but I'm guessing this probably has to do > needing to provide adapter implementations to Java's standard interfaces? > > I never liked adding layers of abstraction on top of already bloated API's > and this would be a chance for a fresh start with no backward compatibility > requirements and existing APIs to adhere to. I'm sure all the BigData access > is async underneath no? And we know Memcached screams in Async/UDP mode! > (http://www.facebook.com/note.php?note_id=39391378919) > > - Demis > > On Mon, Oct 11, 2010 at 10:00 PM, gabriel munteanu <[email protected]>wrote: > > > > > > > > > guys, thanks to java gae, we already have javascript on appspot > > checkout ringojs , a ~commonjs framework. > > or you can go to a much lower level through rhino itself. > > > cheers > > > On Mon, Oct 11, 2010 at 11:38 PM, nickmilon <[email protected]> wrote: > > > 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)" > > > <[email protected]<ikai.l%[email protected]> > > > > 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 < > > > >> [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. > > ... > > 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 [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.
