Joyent responds to Yahoo's issues with V8 being used under Node.js(joyeur.com)
joyeur.com
Joyent responds to Yahoo's issues with V8 being used under Node.js
http://joyeur.com/2011/02/05/on-brunos-concern-about-the-current-coupling-of-node-js-and-v8/
5 comments
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.
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.
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.
A process crash will cause the same problem for thread-per-connection server. There is essentially no difference in stability between thread-per-connection and event-loop based servers.
Yes, Bruno's fundamental point is that "desktop" language VMs will just end a process when there's memory allocation errors. So basically there has to be real means to instrument and error handling has to be robust, he's correct in this assertion.
I guess Bruno's basic point is: V8 is client-side. That's where Google's thrust is; that's what they're concentrating on. But SSJS has some unique issues, which aren't necessarily issues on the client side.
So it's a natural question to ask if Yahoo, as a company, are thinking of investing millions of dollars (in terms of manpower) on node.js .
Jason's response seemed more like "we'll cross that bridge when we come to it". Which is perfectly reasonable (and the norm) in startup-world; but large, established companies with their BCPs and contingency-planning and long product lifecycles don't usually think that way.
IMHO, if Yahoo is planning on going all-out for SSJS, they should develop some in-house expertise on V8 so that they can fork it for internal use and not have to wait on Google.
So it's a natural question to ask if Yahoo, as a company, are thinking of investing millions of dollars (in terms of manpower) on node.js .
Jason's response seemed more like "we'll cross that bridge when we come to it". Which is perfectly reasonable (and the norm) in startup-world; but large, established companies with their BCPs and contingency-planning and long product lifecycles don't usually think that way.
IMHO, if Yahoo is planning on going all-out for SSJS, they should develop some in-house expertise on V8 so that they can fork it for internal use and not have to wait on Google.
Original 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...
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).
"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.
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.
"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
Thank you and it does count.
Why does that quote give you more respect for Joyent?
Not necessarily just that comment, the post in general gives me a new found respect for them. They are opinionated, and have a clear focus for what they want to do, and would rather do it in a way they feel is the right way than cave into pressure from big players to do it the 'safe' way. I don't think Bruno, by extension Yahoo, wants node.js to compromise what makes it great, but it definitely isn't tested and it takes balls for Joyent to invest so heavily on evented I/O for V8.
Until node.js makes their home page intelligible to a novice, none of this matters.
I think this is a valid complaint. Sure, it looks "clean" and has some incredibly simplistic examples, but beyond that it's very much an alpha release.
Of course, once we get to the aforementioned 1.0 release with a stable API, things will get a lot better, either from the node guys or third-party guides.
Of course, once we get to the aforementioned 1.0 release with a stable API, things will get a lot better, either from the node guys or third-party guides.
This is happening.
Perhaps I came across too negatively. But, man, it takes some digging to find out how cool node.js is.
I think what you're saying is very subjective.
What they have is quite nowaday standard (and comparing to many older opensource projects: high above average) in the terms of design, clarity, quick examples showing the essence etc.
You know it always takes some conscious effort to discover if the technology is cool and useful or not - think like "teach yourself programming in 10 years". It's much better to provide useful essential examples and let people think what they want to than to say "hey we're new ubercool thing, join us or you're the looser lol". I for one am very happy to see Ryan Dahl seems more modest person than some of "celebrities" in the Ruby world for example (to be fair: ruby-talk list was always dominated by modest, hard-working people rather than celebrities). Productive community is the best advertisement and smart, experienced newcomer will quickly add 2+2 and see the value.
What they have is quite nowaday standard (and comparing to many older opensource projects: high above average) in the terms of design, clarity, quick examples showing the essence etc.
You know it always takes some conscious effort to discover if the technology is cool and useful or not - think like "teach yourself programming in 10 years". It's much better to provide useful essential examples and let people think what they want to than to say "hey we're new ubercool thing, join us or you're the looser lol". I for one am very happy to see Ryan Dahl seems more modest person than some of "celebrities" in the Ruby world for example (to be fair: ruby-talk list was always dominated by modest, hard-working people rather than celebrities). Productive community is the best advertisement and smart, experienced newcomer will quickly add 2+2 and see the value.
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.