Node.js® Enterprise Support
New comprehensive plans availableLearn More
Thank you for contacting us. We will get back to you shortly.
February 05, 2011 - by jason
Bruno Fernandez-Ruiz (Yahoo! Fellow, VP and Platform Architect) wrote about his concerns around the current tight coupling between node.js and V8. Feel free to take a moment and read the original article: "NodeJS: To V8 or not to V8".
A reply doesn't fit into a twitter response, and an update mentioning my reply would be great.
I haven't had a chance to meet Bruno, we've only exchanged a couple of emails in the past. Bruno forgot or doesn't know a couple of key things about node.js and Joyent. I'm always happy to talk about development process at Joyent.
Because I actually have answers to his questions, comments and concerns, I'm going to reply below. They are trimmed down and if I've missed one in particular, please let me know in the comments.
Update: Bruno took the time to follow-up with responses to my queries, while former Yahoo Principal Engineer (and current "Desperado at Facebook") Peter Greiss has waded into the debate as well.
Yes, agreed. You've both been saying it and SSJS does matter.
Bruno: "NodeJS is currently tightly coupled to Google’s V8 engine."
Bruno: "V8 was not designed as a server-side engine, but as a browser-based engine."
I don't know what this means, or if there's a difference. More details here would be helpful.
Bruno: "It’s software that was not designed to run on a server."
I'd also like to know exactly what this means, and more details would be helpful.
Don't even get me started on language virtual machine implementations, just go ahead and compare the quality of V8 with Ruby. I would say something about PHP but the honest truth is that it's been years and years since I've cared about it and my opinions are out-dated.
Bruno: "It’s really up to Google to work with the community to make V8 work on the server-side."
Up to a point. It's actually Joyent's responsibility that node.js runs well period. We're not afraid of a language VM.
Bruno: "Sometimes Google is responsive, but sometimes it might not [sic]."
Yes, that might be the case. I generally find that responsiveness is aided by a few of things: Previously working with members of the other core team at the same companies, functioning as a real contributor when there's an issue (e.g. don't report a bug unless you have a patch) and actually participate in cutting quality code (e.g. adding DTrace and other instrumentation capabilities into V8).
Bruno: "It varies as it depends how fixing a bug or applying a patch may align with Google’s product roadmap and plans."
That doesn't matter to us. If there's an issue with V8 that affects node.js, we'll fix it. If the patch never makes it into the mainline V8 tree, well ... then it looks like we'd be a branch that would continue to track it. We have experience doing this.
Some examples: We "branched" the Solaris 11 Kernel in 2005 and tracked all Nevada put backs for 5 years (this did eventually lead to a full fork); we've been a NetBSD pkg-src user and contributor for 4 years; we worked with Apple on the version of Ruby (with DTrace probes) that shipped back with Leopard.
If we end up in a situation like OpenSolaris's dissolution, then we'll do what we did then: We'll fork it. And fork it hard. Fork it like it's never been forked before.
Let me pull a recent example from Bryan Cantrill's blog:
Bruno: "I don’t Google’s plans [sic], and I suspect most NodeJS committers don’t know either."
I'm under the impression that actual node.js committers (who all work at Joyent) know quite a bit and have pretty good relations with the V8 team. If they didn't, we'd address it, we'd come up with evidence for our concerns, then we'd actually fix it and we'd put it back.
Bruno: "But to Yahoo!, and to others, it’s a big deal and we believe this is fundamental to the success of the NodeJS project."
Joyent is the company behind node.js. I'm one of two founders of Joyent. You have an e-mail from me in your inbox from months ago. Respond to it. We have product people on node.js, business people on node.js and Ryan's there leading it and doing all final commits.
I don't know what you mean my "fail". Is this actual failures, you've been burned by a bug recently or do you mean "OHAI FAIL?"
Bruno: "Even the really smart V8 folks have explicitly designed V8 for failures to happen and safeguard the browser. In a browser, a JS engine failure it’s an inconvenience to the user: damn, you lost a tab. In a thread-per-request blocking I/O server design it’s also not a big deal, you lose one in-flight request. But in an event-driven web server, it’s a major flaw, you lose thousands of in-flight requests you have already accepted."
OK. Reliability is important in event'ed systems under load. I don't think you'll get any disagreement there.
Has this happened to you? Is there something in particular?
I think your point is that failures (e.g. in a PHP stack?) will not impact as many requests because it's "thread-per-request blocking I/O server design" and less scalable and slower on a per process basis. Interesting arguments.
One key step is actually instrumenting in production. This first link is to an image showing some examples of this in V8 and node.js. The second link, I'd recommend coming back to it later.
Yes, ok. Example please.
I mean you need to understand that we use node.js as the core in our instrumentations, agent designs, API end-points, machine-to-machine work and a large-scale telemetry system.
Besides our use, I can safely say that we're the world's experts in instrumenting it within a complete system context.
Bruno:"Google may invest on supporting V8 on the server-side, just like the Mozilla folks do."
Bruno:"Or somebody else might invest and ensure V8 is rock-solid on the server and Google may merge the patches nicely."
You think? Node.js is not being worked on in a vacuum.
Bruno: "Or maybe not, and the community may need to fork V8. Or something else … Nobody really knows."
Actually, I do know. We're engineers at Joyent and we like working on hard problems.
Perhaps a complaint would be "but Joyent is a start-up!"
Yes, we're a 7 year old start-up with offices in San Francisco, Vancouver, Geneva, the People's Republic of China and Singapore; we're a start-up that rarely depends on outside software engineering in what we ship and we've been either deploying or shipping globally for years; we're a "start-up" that's made it on the Gartner Magic Quadrant for Infrastructure as a Service (the criteria for inclusion there is clear), will be on the one for Platform as a Service and we're an "enabler" that ships to global telcos too.
And finally, you'll notice that we did sell a chunk of the company to Intel at the end of 2009 and now even share a board member. I don't see us being worthless or failing anytime soon. (Tab back to the board, see any VCs there?)
The closest complaint is that we're "stealthy" or perhaps the historical lack of marketing people combined with plenty of geeks suggests we don't shout often enough about how awesome we are.
Perhaps a comment would be "but Joyent can't actually work on or contribute to a language VM!"
Well. Actually we could. We come from companies like Intel, Sun Microsystems, Oracle, Google, Apple, Amazon Web Services, Microsoft, Sprint, AT&T, Verizon and Exodus.
We love working on hard shit and we already work on kernels, userlands, virtualization methods, runtimes and there's even unique things that we do.
We also hire people and tweet about it (that tweet is from last year).
And by the way, if you know anyone that's interested in a software engineering gig working on V8 (with the intent of helping with Google's Project), let me know.
Bruno: "Either way, it’s time for the NodeJS community to realise there is a roadblock and discuss it openly."
If there are actual technical problems with V8's reliability and these affect the use of node.js in production then I'd like to see details, and if another large company is capable of contributing, then I'd love to see a patch.
After all, we are still working on getting it to 1.0.