The V8 team's anti-documentation culture is kind of problematic. As a compiler author targeting JS, it's been consistently difficult to figure out what kind of patterns V8 optimizes for, what patterns cause problems, and what the hell is going on inside their runtime. The rapid pace of changes to V8 - both new feature additions and system overhauls - means that if you're maintaining a complex project that interacts with V8, you're going to have a really hard time.<p>They barely document their engine internals or debugging tools, things change randomly making the existing documentation incorrect, and they frequently break the user-facing development tools like Chrome's JS debugger.<p>The only good things I can really say are that when V8 works, it works marvelously, and that if you can somehow track down a V8 developer they're usually incredibly helpful. Regardless, having to head over to the Google campus and buy a dev coffee isn't a scalable solution to these kinds of problems.<p>I've basically given up on delivering good performance in V8 as a result. The cost is too high. If I see obvious bottlenecks in their profiler (when it works at all), I tune them, but that's about it. I wasted a handful of weeks digging around in debug builds looking at bailout log entries and trying to decipher their IR using the broken log viewer they recommend, and the net result was that my code ended up faster for a few weeks until V8 changed again. Not worth it.<p>P.S. When I say 'anti-documentation culture', I mean it. V8 devs have personally told me they dislike documenting certain aspects of V8 and its internals because they fear that end-users and developers will rely on those internals. They lean towards occasional blog posts and Google IO presentation videos to pick up the slack.
To be clear his complaint concerns the <i>public</i> embedders API, not internals or performance.
This API is vastly under documented, however the example shell and d8 code is very helpful for figuring out most of it.<p>Stephens libraries aim to abstract this API into something more palatable (simpler marshalling back and forth, function signatures, object mapping etc), so clearly breaking changes to this API can result in huge rewrites, and the most recent changes are daunting. Disclaimer: I never used his libraries but was well aware of them.
The modified headline (currently "Sayonara, V8") made me think this was a post announcing Google's abandonment of the V8 engine (and thus presumably introducing or specifying a replacement).
I appreciate his attitude about this - he doesn't come across as bitchy at all (at least not to me). He's essentially saying "you choose not to run the project a certain way, and that's fine, but therefore I can no longer afford to run mine at all, and that's the consequence".
A better headline than either the original or the reversion-to-page-title would be:<p><i>Maintainer of v8-juice/cvv8: "Sayonara, V8"</i>
This is a huge loss. cvv8 has made writing nodejs native addons for large APIs <i>much</i> easier than the standard v8 interface. The entire nodejs community will be pretty significantly impacted - the v8 changes break all native addons for node 0.12.
JSC has a very stable external API and performs competitively (for some reason it always beats V8 on DOM manipulation stuff -- I don't know why v8/chrome haven't been able to make more efficient bindings).<p>It doesn't build outside of the WebKit tree, though... (but there are some scripts which should in theory build only jsc; I think they want all the deps to WebKit, etc, however).
node.js was facing the same issue. In it's current state, node itself works fine but most native modules are broken with the latest v8. The main incompats are: Function callbacks are now a different type than they used to be before. The isolate parameter is required everywhere resulting in large scale deprecation of public api.
The SWIG effort is struggling with the changing API too.<p><a href="https://github.com/oliver----/swig-v8/pull/9" rel="nofollow">https://github.com/oliver----/swig-v8/pull/9</a>
The "Why I quit" blog post serves as a kind of alternative exit interview process for the disgruntled and the outrage junkies. There are some tidbits of useful information, and the discussion here has some good information, but the Goodbye X theme lacks a bit of thoughtfulness in its presentation. Personally I'd avoid such a tacky thing. Google didn't disappear nor has seemed to have changed despite all the "Why I quit Google" posts and I'm sure v8 will be just the same tomorrow. There's a bit of narcissism. The authors attribute a bit of too much self-importance, and yet the thing they left carries on just fine in their absence. Given that these posts actually do contribute useful information, changing the tone to "what I learned at X" from "why I quit X" may see more uptake and less squabbling in subsequent discussions. You'll also avoid burning a bridge.<p>Edit: Every one of the downvotes this post gets are because this post runs counter to the HN echo chamber. I challenge someone to present an argument to explain otherwise. You've soaked yourself in outrage, and hell if anyone will say anything that may disagree with all that anger boiling up inside you. So you see some green nick and click downvote.