Comment by bcantrill | Hacker News Reader

Comment by bcantrill | Hacker News Reader

This piece is (by far) the best written on the io.js fork and its ramifications. As I have said many times before, we are forkaphilic[1] -- forking is healthy because it allows (and encourages) experimentation with divergent ideas. The primary idea that io.js appears to be experimenting with is "more frequent releases", in particular very closely tracking V8. This is somewhat ironic because the close tracking of V8 has been a major contributing factor to the delay in 0.12: despite good intentions, V8 breaks node.js frequently -- and debugging those problems is a time-consuming and arduous task requiring a great deal of technical sophistication. We have made clear that our technical priorities for the project are production-grade stability and performance; to the degree that other have different priorities, forking should be encouraged. In part to allow cross-pollination from any fork, we eliminated our CLA earlier this year[2]; the community can rest assured that good ideas from either will be able to be in both.

[1] https://www.youtube.com/watch?v=Pm8P4oCIY3g#t=23m43s

[2] https://www.joyent.com/blog/broadening-node-js-contributions

Thank you! I'm glad we were able to share a brain wave. I'm loving the term 'forkophobia', and the comparison to Berlin. Freedom to choose means that people will gravitate to the best ideas. At the end of the day, everyone wins with open source.

> despite good intentions, V8 breaks node.js frequently -- and debugging those problems is a time-consuming and arduous task requiring a great deal of technical sophistication

Can you provide some examples? I'd love to see some debugging war stories.

TJ can provide examples from his perspective; my personal examples are all from keeping the node.js production debugging facilities[1][2] operating properly. We have tried hard to make these facilities independent from V8, but the reality is that they encode how V8 operates and that changes to V8 can break them. Fortunately, the node.js DTrace ustack helper[3] -- by far the more intricate piece -- hasn't needed major maintenance, but the facilities for iterating over all JavaScript objects from a core dump (for example) have been broken quite a few times. I'm afraid the war stories from debugging these aren't terribly heroic -- they boil down to one of the node.js debugging tests failing and Dave Pacheco or me (exactly which one frequently being adjudicated by fingers-on-noses) sitting down for several intense hours to learn how V8 has changed and modify our debugging support accordingly. If you want to see the details of the changes needed to accommodate V8, you can look at some of the specific commits for the debugging support.[4]

[1] http://www.joyent.com/developers/node/debug

[2] http://www.slideshare.net/bcantrill/goto2012

[3] http://dtrace.org/blogs/dap/2013/11/20/understanding-dtrace-...

[4] https://github.com/joyent/illumos-joyent/tree/master/usr/src...

Thank you, I will definitely check those out.

What is node core devs relationship with V8 team and Google,if there is any?

That's what makes me the most worried with nodejs.It depends on a project led by a corporation that is difficult "to read".We're not talking about a C++ lib that has been stable for 20+ years,but something that is likely to change fast and frequently,which will break every native extension written for node.

It seems to me that Goggle isnt that implicated in node development.

It seems to be the issue is a little more than "more frequent releases" but is instead more about the poor stewardship of Node.js by Joyent. It seems to be about increasing transparency and openness instead of just tracking v8 more closely.

Between io.js and node-forward it seems to be working. Hopefully things like the node advisory board are just one step in Joyent being a better steward.

Reply on news.ycombinator.com