Joyent responds to Yahoo's issues with V8 being used under Node.js
1–10 of 22 posts
Re: Joyent responds to Yahoo's issues with V8 being used under Node.js
#2Original article from Bruno Fernandez-Ruiz (Yahoo): http://www.olympum.com/future/nodejs-to-v8-or-not-to-v8/
Response to OP from Bruno: http://www.olympum.com/future/answering-jason-on-v8-governan...
Re: Joyent responds to Yahoo's issues with V8 being used under Node.js
#3Original article from Bruno Fernandez-Ruiz (Yahoo): http://www.olympum.com/future/nodejs-to-v8-or-not-to-v8/ Response to OP from Bruno: http://www.olympum.com/future/answering-jason-on-v8-governan...
It's kind of off-topic, but I found this statement from Jason weird:
"functioning as a real contributor when there’s an issue (e.g. don’t report a bug unless you have a patch)"
Doubly so as later in the same post he's asking Bruno if the failures he's talking about are real or hypothetical. In other words demonstrating that bug reports are valuable even without patches (though of course their value can vary wildly).
Re: Joyent responds to Yahoo's issues with V8 being used under Node.js
#4There are a few interesting discussion points being thrown back and forth between the Yahoo developer Bruno and Joyent founder Jason.
The most interesting question raised in my opinion is Bruno essentially saying that thread-per-request blocking I/O server design is safer than event based server design. If one thread dies it's less likely to propagate problems that will kill the server. Due to this added complication he thinks that node.js should focus more on reliability and believes that V8, with roots in browser side and not server side JS, is ill-equipped.
Jason wants to focus on two things. First, he keeps asking for specific examples of where problems have arisen (as otherwise it appears to be a theoretical fear) and second he wants to push node.js towards 1.0 and stabilize the API and feature set.
It seems Jason thinks Bruno is looking too far into the future. It's essentially the architectural equivalent of premature optimization - until the API and feature set stabilizes there's not going to be any great call for perfectly reliable production servers.
Even then Jason is confident Joyent can deliver on the latter considering how many active V8 devs they have working for them.
Both guys seem to really love server side JS and want to push for it, they just have different ideas about which direction to head.
Re: Joyent responds to Yahoo's issues with V8 being used under Node.js
#5Original article from Bruno Fernandez-Ruiz (Yahoo): http://www.olympum.com/future/nodejs-to-v8-or-not-to-v8/ Response to OP from Bruno: http://www.olympum.com/future/answering-jason-on-v8-governan...
It's kind of off-topic, but I found this statement from Jason weird: "functioning as a real contributor when there’s an issue (e.g. don’t report a bug unless you have a patch)" Doubly so as later in the same post he's asking Bruno if the failures he's talking about are real or hypothetical. In other words demonstrating that bug reports are valuable even without patches (though of course their value can vary wildly).
Context is important here.
Bruno was saying that Google are the gatekeepers of V8 and that if they didn't plan to support server side use of V8 that it'd be hard to contribute to the official codebase. Jason said that not only did Joyent have many V8 committers but additionally they've worked with the Google guys to submit real contributions. This would mean that any contributions they make in the future are far more likely to be accepted due to both the quality of work and the previous credibility they built up with the Google V8 team.
Simply put you're a lot more likely to accept a large feature patch from someone you know and has contributed previously than from someone who doesn't contribute. He doesn't mean to say bug reports have no value if there's no patch.
Re: Joyent responds to Yahoo's issues with V8 being used under Node.js
#6"We’ll fork it. And fork it hard. Fork it like it’s never been forked before"
Re: Joyent responds to Yahoo's issues with V8 being used under Node.js
#7"We’ll fork it. And fork it hard. Fork it like it’s never been forked before"
I love this comment. I really enjoy node.js but have never really paid attention to Joyent, until now. They have immense respect from me (not that it counts for much) for their candid response and their push for SSJS and node.js
Re: Joyent responds to Yahoo's issues with V8 being used under Node.js
#8Until node.js makes their home page intelligible to a novice, none of this matters.
Re: Joyent responds to Yahoo's issues with V8 being used under Node.js
#9There are a few interesting discussion points being thrown back and forth between the Yahoo developer Bruno and Joyent founder Jason. The most interesting question raised in my opinion is Bruno essentially saying that thread-per-request blocking I/O server design is safer than event based server design. If one thread dies it's less likely to propagate problems that will kill the server. Due to this added complication…
I admit both of them have lots to say about SSJS or even SS-anything. Still I can't understand Bruno's sentiment towards thread-per-request approach, considering that he's talking about the Node here. Node.js is all about a simplicity of evented, single thread design. If someone thinks this "worse is better" approach went too far in this case, why to use Node at all? There are tons of good thread-based solutions nowadays - a fit for anyone's taste.
Re: Joyent responds to Yahoo's issues with V8 being used under Node.js
#10There are a few interesting discussion points being thrown back and forth between the Yahoo developer Bruno and Joyent founder Jason. The most interesting question raised in my opinion is Bruno essentially saying that thread-per-request blocking I/O server design is safer than event based server design. If one thread dies it's less likely to propagate problems that will kill the server. Due to this added complication…
I admit both of them have lots to say about SSJS or even SS-anything. Still I can't understand Bruno's sentiment towards thread-per-request approach, considering that he's talking about the Node here. Node.js is all about a simplicity of evented, single thread design. If someone thinks this "worse is better" approach went too far in this case, why to use Node at all? There are tons of good thread-based solutions nowa…
The issue is that a single V8 thread in Node.js could be handling the event loop for thousands of clients. A process crash here could cause a mini thundering-herd when all the users attempt to reconnect at the same time.
So his question is not baseless - the solution is to have a VM that rarely crashes.
n.b. Erlang also hard-crashes when it can't allocate memory. This hasn't hurt its reputation for reliability.