• implement missing CPython features (2.x series is now complete on that front, so they can move on to the 3.x only features)
• make execution of real world applications faster (primarily as measured by the results on speed.pypy.org)
• supporting more C extension modules (a lot of extension modules actually have buggy reference counting, but get away with it due to the CPython interpreter’s own internal reference counts inflating the numbers, as when it comes to refcounts 10 vs 11 is a minor accounting error but 0 vs 1 is disastrous).

For building enthusiasm and motivation, it’s hard to go past a set of concrete goals like that. CPython has nothing that is anywhere near that clear, which is why we have adopted “improve test coverage” as a general “get involved” type goal (it gives people a chance to create patches with a high chance of being accepted, helps flush out lingering bugs in dark corners of the standard library, and generally holds the implementation to a higher standard in the future).

Now, if people specifically wanted to work on the kinds of things that you suggest, then we’d be amongst the first to recommend PyPy as a better platform for experimentation than CPython. However, when we suggest that to people, we currently get pushback on the idea. You know why? Because PyPy isn’t yet a viable drop-in replacement for CPython, so they don’t want to work on an implementation that is PyPy specific.

So even though PyPy is already a much better platform for these ideas than CPython will ever be (e.g. getting rid of refcounting is a prerequisite to basically any interesting copy-on-write based memory savings), the PyPy devs have the right idea in targeting drop-in replacement levels of compatibility. The day that a Linux distro decides to point /usr/bin/python at a PyPy installation rather than a CPython one to provide an immediate performance boost without any additional effort on the part of application developers will be an impressive achievement for all concerned (and my personal assumption regarding that day is that it really is a matter of “when” rather than “if”).

I’m a hardcore C++ desktop apps programmer and have been for the last 15 years – web development is not my primary occupation, but I’ve done it a lot and I like it. And from everything I’ve tried so far on the server-side (Visual Basic .exe CGI’s in the 90′s, ASP, JSP, Perl, PHP, FastCGI modules), nodejs experience is very refreshing and productive.

In the case of nodejs, it is not necessarily the Javascript everywhere that is the attractor for me. It is the speed of that thing, code re-use between the browser/server and no context-switching between languages. The async API of nodejs makes it a bit unpleasant — all those callbacks and callbacks within callbacks are at some point quite horrible.

But I spent 2 days and learned CoffeeScript and node.js experience (as well as browser js experience) has improved dramatically. With CoffeeScript you get the clean syntax of Python/Ruby, the flexibility of Javascript and the speed of nodejs.

So instead of Javascript everywhere, I would vote for CoffeeScript everywhere :).

I’d really like elaboration on what you’re attempting to refute in “You can work fluidly across client and server!”. Can you name some existing projects which purport to do this, or cite any cases where you feel the distribution boundaries between client and server have been made too thin? I’m trying to wrap my head around what is being refuted here; it’s not clear what arguments and examples you are writing in reply to.

Things like server-side DOM are largely for this purpose, except insofar as they are intended to support testing (though testing seems like the majority of uses in what I’ve seen). Well… there are entirely distinct ways to use the DOM as well (e.g., spidering) which don’t rely on client-server integration. Ironically Javascript has generally had really terrible HTML handling (no freakin’ parser!) so at this point it’s still playing catch-up. (But unlike in other languages communities I think the audience will be more inclined to make full use of what it has once it does catch up.)

But you are right that I am refuting a vaguely stated argument — I don’t think I’m imagining the argument, but it’s the feeling I get from a lot of people I personally know who become excited about Node. This excitement is vague because it’s usually not about what they are concretely making, but about their excitement about what they could make with Node. So it’s not like people are making studious arguments about the benefits of Node, nor am I claiming all their enthusiasm is misguided (and it’s fine to be enthusiastic without any justification whatsoever!), but at least on this count I am skeptical.

And in these personal discussions the idea of Javascript on the server and client is clearly a feature of people’s excitement.

What about other non-JS server stacks, which of them go too far in mixing server and client state into one undecypherable intractable ball (in violation of the primary directive of distributed computing)? Was ASP.NET a bridge too far? Rails’ JS integration? And does the mere presence of JS on both sides imply this muddling has already happen, that work is being done too fluidly, code or state shared in some insecure or ill conceived manner?

Yes, and I abhor this cleverness in other languages even more than in Javascript ;)

IMHO good sharing across systems is done with documents (JSON being a perfectly good document syntax). Frequently the documents are shared over HTTP… but even in Javascript the IPC I’ve seen has been mostly text-based (typically with JSON layered on top, much like HTTP). Once you are doing this level of abstraction it’s pretty much as easy to communicate with other languages as with Javascript, all the dynamic languages handle JSON well.

I’m disappointed in what I perceive as your over-reaction to JSNinjaTrainer, Ian. In spite of his flippant uncalled for ending, the majority of his post was a well reckoned technical rebuttal, one I agree with in quite a few places, and think deserves more discussion. Cutting it short on account of injury is a disservice to the discussion you welcomed in by creating this post. I’d encourage you to move past the injurious LOLCode, which has been apologized for.

I found his entire post snide, and his argument style is one that I find if I engage with only leaves me pointlessly frustrated. But I’ve considered revisiting it with an answer.

Like many parts of the Javascript community that are forming, the tone of the Javascript community is still to be defined. Now is a time when it would be good to be conscious of that tone.

I think .NET and the CLR is a good piece of evidence for this generally: it supports multiple languages, and great effort has been put into this, but ultimately all the successful languages have been new languages designed to fit the environment; ported languages (e.g., IronPython) haven’t been very successful and I don’t have any faith in their long-term viability.

(My opinion is also based on a bunch of very concrete issues with Python in the browser, but that’s where the discussion becomes extended ;)

I’d really like elaboration on what you’re attempting to refute in “You can work fluidly across client and server!”. Can you name some existing projects which purport to do this, or cite any cases where you feel the distribution boundaries between client and server have been made too thin? I’m trying to wrap my head around what is being refuted here; it’s not clear what arguments and examples you are writing in reply to.

What about other non-JS server stacks, which of them go too far in mixing server and client state into one undecypherable intractable ball (in violation of the primary directive of distributed computing)? Was ASP.NET a bridge too far? Rails’ JS integration? And does the mere presence of JS on both sides imply this muddling has already happen, that work is being done too fluidly, code or state shared in some insecure or ill conceived manner?

I’d throw the following into the “pro” side of using JS everywhere: extensions/polyfills like underscore or kaffeine, solved native ser/deser (JavaScript Object Notation), being able to leverage the same documentation frameworks (JSDoc, Doxygen), code style policies, and code quality checks (JSLint). javascript everywhere can be a huge advantage.

From a writing perspective, the conclusion could be a lot more effective, IMO. “But this one argument, I do not think it is very good,” is a weakly linked to the topic, mentioned only at the top (“Javascript on the client and the server!”) and doesnt really draw together what the goal of client and the server both would be and how your arguments against work out.

Mostly, I think this is a result of insufficient exploration of the problem space; what “Javascript on the client and server” is purported to provide isnt linked or discussed anywhere. Instead the conclusion is left to refute a wide focus of things never defined in the first place. Over half the time I’m under the impression this article is an argument against “dual sided” templating/ajax, but the conclusion wanders back to node as webapp framework, which in many cases is altogether very different.

I’m disappointed in what I perceive as your over-reaction to JSNinjaTrainer, Ian. In spite of his flippant uncalled for ending, the majority of his post was a well reckoned technical rebuttal, one I agree with in quite a few places, and think deserves more discussion. Cutting it short on account of injury is a disservice to the discussion you welcomed in by creating this post. I’d encourage you to move past the injurious LOLCode, which has been apologized for.

To be sure, one consideration is memory usage. And a JIT compiler exacerbates this problem. But I wonder if PyPy can adopt any techniques from the Dalvik VM (from Android) to increase the proportion of memory pages that can be shared between processes. Or PyPy could implement the memory dumping technique used by the Emacs compilation procedure to reduce the memory usage of multiple Emacs processes.

Are there any other reasons to favor microprocesses over good old Unix processes?