Hi Ryan, Some further thoughts on all this:
First, I perfectly understand your concern about keeping node.js as fast and simple as possible, and thus sticking to pure JS and callbacks. I don't have any issue with this and I've already said that I'm not advocating for anything to go into core. I think that node.js is just victim of its success. Of course, it is foremost appealing to pure JavaScripters. It is even more appealing to people who are writing the new kind of very innovative, real-time, scalable, I/O centric applications in Javascript. These people love node, they love Javascript, they love callbacks. They are your early adopters and greatest fans. They are usually high profile engineers with a strong background in networking and system level programming. They are obsessed by performance and they contribute very clever I/O libraries. But node.js is also a very appealing platform for a much larger crowd. People who may be building more mundane applications but want to take advantage of a very fast and popular scripting language and see the benefits of a pure async platform. What are the alternatives for them? Erlang? Very cool technically but not really mainstream. Java, .NET or Scala with async libraries? Much more mainstream but their async story is a lot less appealing because they come with lots of sync baggage... Node just has a unique blend of mainstreamness, innovation and overall coolness. So these people come to node. This is a different crowd with a different focus. They are ready to trade a bit of performance for productivity, they have used different languages before: PHP, Python, Ruby, Java, C#, ... Of course they like JavaScript but if you show them CoffeeScript they'll find it cool. They are more into application building than library building. I think that the core team should engage differently with these two different audiences (and reality is probably much more complex with lots of people who come to node for lots of other reasons). These audiences have different needs. What's the point of "teaching callbacks" to the second audience? They did not come to node to write I/O libraries, they just want to write applications. They may not know anything about networking protocols but they may know how to compute a payroll slip and they may need to generate PDF files. They want to take advantage of node but they did not come to it to learn new programming paradigms. My plea is that the core team recognize this and start considering node as a runtime. I'm not asking them to change their focus. I'm perfectly happy that they continue to serve best the first audience (which, in the end, will just benefit everybody). Just that they stop considering that everyone must program to the metal with callbacks. If someone has developed a language tool or a library that can ease the life of the second audience, he should be able to talk about it without triggering a war. In one of the replies on my blog, I compared node.js with Linux. Linux is an very appealing platform. The core is written in C but many people are developing in C++, Java, PHP, Ruby, etc. Linus Torvalds does not like C++ at all. He said it very loud and clear (http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918). Yet the Linux core team is not at war with the C++ community. And Linux is the big winner, partly because of the richness of its language ecosystem. We can speak different languages and yet get along. There is one topic, though, that really justifies a war: semicolons :-) Bruno On Sunday, April 15, 2012 2:35:09 AM UTC+2, [email protected] wrote: > > On Sat, Apr 14, 2012 at 9:30 AM, Bruno Jouhier <[email protected]> wrote: > > I posted a follow-up on my blog: > > > http://bjouhier.wordpress.com/2012/04/14/node-js-awesome-runtime-and-new-age-javascript-gospel/ > > Bruno, we are evangelizing callbacks because this is the only it can > possibly work in JavaScript. You can add a preprocessing step (which > is apparently what streamline is doing) - we will not do that. You can > add some crazy longjmp in your extension and juggle executions stacks > and try to forget how much memory they are or fight with stack over > flows - we will not do that. JavaScript has a run-to-completion model > which we do not seek to circumvent. Node is JavaScript - even more > than that - Node is V8 JavaScript. If V8 adds generators, we will have > them - if not then not. One of the key reasons Node is successful > (unlike all of other server-side JS systems) is because it actually > uses JavaScript and not some JavaScript-like language. > > I'm glad you like Node. As you said, it is simple and fast. It got > that way by keeping things simple and fast. It will remain simple and > fast by continuing to strive for those goals. > > This is a discussion to bring up with the EcmaScript committee. > > On Sunday, April 15, 2012 2:35:09 AM UTC+2, [email protected] wrote: > > On Sat, Apr 14, 2012 at 9:30 AM, Bruno Jouhier <[email protected]> wrote: > > I posted a follow-up on my blog: > > > http://bjouhier.wordpress.com/2012/04/14/node-js-awesome-runtime-and-new-age-javascript-gospel/ > > Bruno, we are evangelizing callbacks because this is the only it can > possibly work in JavaScript. You can add a preprocessing step (which > is apparently what streamline is doing) - we will not do that. You can > add some crazy longjmp in your extension and juggle executions stacks > and try to forget how much memory they are or fight with stack over > flows - we will not do that. JavaScript has a run-to-completion model > which we do not seek to circumvent. Node is JavaScript - even more > than that - Node is V8 JavaScript. If V8 adds generators, we will have > them - if not then not. One of the key reasons Node is successful > (unlike all of other server-side JS systems) is because it actually > uses JavaScript and not some JavaScript-like language. > > I'm glad you like Node. As you said, it is simple and fast. It got > that way by keeping things simple and fast. It will remain simple and > fast by continuing to strive for those goals. > > This is a discussion to bring up with the EcmaScript committee. > > On Sunday, April 15, 2012 2:35:09 AM UTC+2, [email protected] wrote: > > On Sat, Apr 14, 2012 at 9:30 AM, Bruno Jouhier <[email protected]> wrote: > > I posted a follow-up on my blog: > > > http://bjouhier.wordpress.com/2012/04/14/node-js-awesome-runtime-and-new-age-javascript-gospel/ > > Bruno, we are evangelizing callbacks because this is the only it can > possibly work in JavaScript. You can add a preprocessing step (which > is apparently what streamline is doing) - we will not do that. You can > add some crazy longjmp in your extension and juggle executions stacks > and try to forget how much memory they are or fight with stack over > flows - we will not do that. JavaScript has a run-to-completion model > which we do not seek to circumvent. Node is JavaScript - even more > than that - Node is V8 JavaScript. If V8 adds generators, we will have > them - if not then not. One of the key reasons Node is successful > (unlike all of other server-side JS systems) is because it actually > uses JavaScript and not some JavaScript-like language. > > I'm glad you like Node. As you said, it is simple and fast. It got > that way by keeping things simple and fast. It will remain simple and > fast by continuing to strive for those goals. > > This is a discussion to bring up with the EcmaScript committee. > > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" 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/nodejs?hl=en?hl=en
