11 ms·

Sayonara, V8

302 points by fridek 13y ago

deleted 13y ago
[deleted]
fotcorn 13y ago
Does node.js have the same problem with the big API changes in v8?
- kevingadd 13y ago
  My instinct is that node probably doesn't interface as tightly with v8, or have as much of a surface area on those interfaces, as something like v8-juice. Given Stephan's claim that the new version of v8 is incompatible with all applications, though, I suspect some energy will be expended to make node compatible. Node at least has a huge pool of users and developers to draw from when tackling a change like this.
  - baudehlo 13y ago
    The porting for Node was entirely done by one person. The bad news is it will also break all C++ extensions, which frankly I'm not looking forward to (both as a developer of said extensions, and a user).
  - sgbeal 13y ago
    The claim that it breaks "all v8 applications" is based on the fact that the v8::InvocationCallback signature (which is used by all client applications who actually embed anything) is now different. It can't NOT be incompatible.
- aegiso 13y ago
  Yeah, we're feeling this in nodeland too. The core team has actually done a great job making sure that the core of node works with the new V8 API; this is already working in the unstable branch, without too much fuss. The much, much bigger issue is the native modules in npm. They all basically have to be ported by hand, and only a handful actually have been. So, transitioning to the next version of node will be an exercise in masochism for us makers. On the other hand, improving V8 with breaking changes is the V8 team's perogative and I trust they're doing it for the right reasons.
  - shmageggy 13y ago
    I'm interested to see how Go progresses over time, as they consciously made the design decision to keep the language easily parseable so that API breaking changes can be accounted for programatically rather that requiring manual porting. See gofix -- http://blog.golang.org/introducing-gofix http://blog.golang.org/introducing-gofix In theory, this should allow them greater flexibilty to iterate and refine the language over time without the negative backlash that we're seeing here.
    - lttlrck 13y ago
      The API in question here is the C++ embedder API. It's altogether a different issue to Google changing some Go library APIs.
      - shmageggy 13y ago
        So are you saying there's nothing that the V8 devs could have done to ease the transition?
        sgbeal 13y ago
        To their credit, they warned us some months ago (April?) on the list that the InvocationCallback signature and Persistent would change. That was a new step for them - the first time i was warned about breakage before it happened. But without concrete change details and a reference build to work against, one can't even prepare for the change until v8 has released something. A flood and backlog of client breakage was inevitable the moment they decided to make the change.
kevingadd 13y ago
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. 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. 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. 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.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.
- fridek 13y ago
  To be fair - I've never seen such docs for SpiderMonkey. I may have just failed at finding them though. Keeping up-to date documentation of compiler is a horrible job. I think it's good enough that V8 may be built as standalone binary with really extraordinary debug options and tools. At the same time, I'd love to see more talks like http://www.youtube.com/watch?v=FrufJFBSoQY http://www.youtube.com/watch?v=FrufJFBSoQY There are also guys who write about V8 from time to time (http://mrale.ph/ http://mrale.ph/ http://floitsch.blogspot.com/ http://floitsch.blogspot.com/ http://wingolog.org/tags/v8 http://wingolog.org/tags/v8) but this is needle-in-a-haystack type of learning.
TallGuyShort 13y ago
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".
- sgbeal 13y ago
  Thank you, TallGuyShort :). i think i did come across as a bit bitchy, but i tried to stay on topic and removed lots of stuff i wrote simply out of primal frustration :/. i'm only human ;). i thought about it for a couple months before writing it, and spent a couple days rewriting it, to make sure i wasn't just sending flame bait.
nailer 13y ago
Obligatory links: https://code.google.com/p/v8-juice/wiki/HomePage https://code.google.com/p/v8-juice/wiki/HomePage and https://code.google.com/p/v8-juice/wiki/V8Convert https://code.google.com/p/v8-juice/wiki/V8Convert
jey 13y ago
What's the gist of these supposedly major changes to the V8 APIs?
- mraleph 13y ago
  In short it was easy to misuse global v8::Persistent<T>`handles leading to memory corruptions and such. Unfortunately making them safe to use also means making them hard to use directly. Previously they were just interchangeable with normal v8::Local<T> handles for things like calls. https://groups.google.com/d/msg/v8-users/6kSAbnUb-rQ/e-GI0b1ThA4J https://groups.google.com/d/msg/v8-users/6kSAbnUb-rQ/e-GI0b1...
- bradleyjg 13y ago
  This seems to be the biggest issue: Changing all callbacks that return Handle<Value> to return void and instead pass the return value in as a parameter.
  - mraleph 13y ago
    This is actually easy to work around by creating trampolines. Dan Carney creating a small header file with templates to create those trampolines easily: https://github.com/drcarney66/v8-backport https://github.com/drcarney66/v8-backport Amount of typing one needs to do is minimal, I think.
    - sgbeal 13y ago
      That approach doesn't work (without a lot of effort) with templates at the level cvv8 uses them. There are literally thousands of InvocationCallback instances in the cvv8 tree, most of which are bound via the XTo templates, which run through 4 or 5 layers of metatemplate magic to do their things. It's a bit more complicated than a drop-in replacement can solve unless the drop-in replacement has the same signature AND type name as the old one (and even then it would require more effort than i'm willing to commit to).
morgante 13y ago
I totally thought the headline was referring to Campbell discontinuing their disgusting beverage. Sadly this news is much sadder.
- unreal37 13y ago
  Looks like someone needs a V8.
- mjcohen 13y ago
  It's disgusting to you, not to many others (like myself). I even like the low-sodium version (having low standards can be very useful).
lttlrck 13y ago
To be clear his complaint concerns the public 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. 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.
- sgbeal 13y ago
  FWIW: your interpretation of my intentions is how i hoped they would come across :).
randallu 13y ago
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). 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).
- olliej 13y ago
  JSC should build cleanly on its own (e.g. no dependencies on anything on top of it.) It's possible some of the build scripts have developed a bizarro dependency on other portions of the repo, but we'd happily take patches to fix those issues. As far as APIs, JSC has provided a completely API and ABI stable C API for 7-ish years, and there's an ObjC API built on top of that now. Unfortunately the nature of C APIs for interacting with language runtimes makes it somewhat clunky and hard to use perfectly - C++ makes this easier as you can make types with constructors and destructors to make a lot of the otherwise manual work (ref()/deref(), etc) entirely automatic. Unfortunately C++ makes it easy to make an API that has a stable interface, but still isn't ABI stable.
  - azakai 13y ago
    People build jsc on its own on mac, but I have never been successful on linux. Hopefully there is some way though? I've been forced to build all of WebKit-gtk. A bigger concern for me personally is that the jsc shell lacks typed arrays, https://bugs.webkit.org/show_bug.cgi?id=119828 https://bugs.webkit.org/show_bug.cgi?id=119828 edit: i should have said 'full spec for typed arrays', see the linked issue
    - olliej 13y ago
      The typed arrays should be available in trunk, haves you checked recent trunk? I believe the "need all of webkit-gtk" was a pile of sadness in build-jsc + automake that may have been fixed recently. I'm sure Zan, Xan, or Michel would be happy to help if it's still borked. There are _some_ platform requirements that make a generic "linux" not work, as we build on the platform support libraries for threads, unicode, etc so JSC may have random looking dependencies on such
gojomo 13y ago
A better headline than either the original or the reversion-to-page-title would be: Maintainer of v8-juice/cvv8: "Sayonara, V8"
- kevingadd 13y ago
  Wow, what a poor choice on the part of the mod who decided to change this headline.
- fridek 13y ago
  I didn't wanted to make sensational title that says nothing about content. I hate this on HN. Such attention hunting is an act without honor. Article is about V8-juice author abandoning his library for reasons that I don't personally consider right or wrong. I wanted to share this because there is a slight chance that state of V8 documentation (which I've never seen or used myself) is a political decision on a higher level (too little outcome from too much effort) and some discussion around the topic may change that.
glhaynes 13y ago
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).
- shardling 13y ago
  Yeah, whoever changed the headline accidentally made it misleading click-bait.
leokun 13y ago
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. 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.
- oso2k 13y ago
  I've had several interactions with Stephan. He's offered several times (dozens maybe) to do contract work (or otherwise) to create, update and maintain the public interfaces documentation and any supporting documents during the least 3 years. Google's stance (via its devs) has always been that v8's sole purpose (in their view) is as the JS VM for Chrome. It is not a product like GWT. Promotion of its capabilities is as of a consequence of v8 being connected to Chrome. For the most part, Stephan's offers have been completely ignored with a couple devs occasionally accusing him of grandstanding. I do feel that, however, for whatever reason, Google has demonstrated a personal affinity for certain embedders (node.js specifically, CEF maybe) vs. the lesser know embedders (v8-juice, TeaJS, SilkJS, NarwhalJS). I don't agree that Stephan has assigned himself too much self-importance. In fact, Stephan devoted significant time to identifying corner cases in the public interfaces that are beneficial to all embedders and has always chosen to make those learning experiences public, either via the GoogleCode Wiki or on the various v8 lists.
  - sgbeal 13y ago
deleted 13y ago
[deleted]
dpe82 13y ago
This is a huge loss. cvv8 has made writing nodejs native addons for large APIs much 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.
- sgbeal 13y ago
  i'm happy to hand over admin access to the repo as soon as someone asks for it. i would really hate to see cvv8 go to waste (IMH (and biased) opinion it's the best binding/conversion lib for v8), but i can't deal with them pulling the rug out from under me again (this is not the first time they've done it, only the most invasive, and it IS the first time they've warned us in advance).
  - dpe82 13y ago
    I would love to but also don't have the bandwidth. By the way, thank you for all your work. It took me quite a while to wrap my head around the template craziness you use in cvv8 but it turns out being pretty awesome. We have a huge API surface we're using cvv8 on and so far it's working great. IMHO probably the best approach that I haven't seen anyone but the chromium project use would be a bindings compiler that takes WebIDL and generates wrapper code. I started down that path before diving into cvv8, but didn't understand well enough what my compiler should output. May have to revisit that project at some point if we want to upgrade beyond node 0.10.
    - sgbeal 13y ago
      Thank you for your kind words. It took me a good long while to get my mind wrapped around the templates well enough to implement it. It was a very incremental process, starting with the basic type conversions and culminating in the function conversions and XTo templates. It was a really, really fun ride. Anyway... you "could" write a wrapper which generates cvv8 bindings. i did that long ago in a predecessor to generate about a hundred ncurses bindings. But... that assumes cvv8 is usable, which it is not with current v8 versions :`(.
general_failure 13y ago
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.
dottrap 13y ago
The SWIG effort is struggling with the changing API too. https://github.com/oliver----/swig-v8/pull/9 https://github.com/oliver----/swig-v8/pull/9

Sayonara, V8

302 points by fridek 13y ago

deleted 13y ago

[deleted]

fotcorn 13y ago

Does node.js have the same problem with the big API changes in v8?

kevingadd 13y ago
My instinct is that node probably doesn't interface as tightly with v8, or have as much of a surface area on those interfaces, as something like v8-juice. Given Stephan's claim that the new version of v8 is incompatible with all applications, though, I suspect some energy will be expended to make node compatible. Node at least has a huge pool of users and developers to draw from when tackling a change like this.
- baudehlo 13y ago
  The porting for Node was entirely done by one person. The bad news is it will also break all C++ extensions, which frankly I'm not looking forward to (both as a developer of said extensions, and a user).
- sgbeal 13y ago
  The claim that it breaks "all v8 applications" is based on the fact that the v8::InvocationCallback signature (which is used by all client applications who actually embed anything) is now different. It can't NOT be incompatible.
aegiso 13y ago
Yeah, we're feeling this in nodeland too. The core team has actually done a great job making sure that the core of node works with the new V8 API; this is already working in the unstable branch, without too much fuss. The much, much bigger issue is the native modules in npm. They all basically have to be ported by hand, and only a handful actually have been. So, transitioning to the next version of node will be an exercise in masochism for us makers. On the other hand, improving V8 with breaking changes is the V8 team's perogative and I trust they're doing it for the right reasons.
- shmageggy 13y ago
  I'm interested to see how Go progresses over time, as they consciously made the design decision to keep the language easily parseable so that API breaking changes can be accounted for programatically rather that requiring manual porting. See gofix -- http://blog.golang.org/introducing-gofix http://blog.golang.org/introducing-gofix In theory, this should allow them greater flexibilty to iterate and refine the language over time without the negative backlash that we're seeing here.
  - lttlrck 13y ago
    The API in question here is the C++ embedder API. It's altogether a different issue to Google changing some Go library APIs.
    - shmageggy 13y ago
      So are you saying there's nothing that the V8 devs could have done to ease the transition?
      - sgbeal 13y ago
        To their credit, they warned us some months ago (April?) on the list that the InvocationCallback signature and Persistent would change. That was a new step for them - the first time i was warned about breakage before it happened. But without concrete change details and a reference build to work against, one can't even prepare for the change until v8 has released something. A flood and backlog of client breakage was inevitable the moment they decided to make the change.

kevingadd 13y ago

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. 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. 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. 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.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.

fridek 13y ago
To be fair - I've never seen such docs for SpiderMonkey. I may have just failed at finding them though. Keeping up-to date documentation of compiler is a horrible job. I think it's good enough that V8 may be built as standalone binary with really extraordinary debug options and tools. At the same time, I'd love to see more talks like http://www.youtube.com/watch?v=FrufJFBSoQY http://www.youtube.com/watch?v=FrufJFBSoQY There are also guys who write about V8 from time to time (http://mrale.ph/ http://mrale.ph/ http://floitsch.blogspot.com/ http://floitsch.blogspot.com/ http://wingolog.org/tags/v8 http://wingolog.org/tags/v8) but this is needle-in-a-haystack type of learning.

TallGuyShort 13y ago

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".

sgbeal 13y ago
Thank you, TallGuyShort :). i think i did come across as a bit bitchy, but i tried to stay on topic and removed lots of stuff i wrote simply out of primal frustration :/. i'm only human ;). i thought about it for a couple months before writing it, and spent a couple days rewriting it, to make sure i wasn't just sending flame bait.

nailer 13y ago

Obligatory links: https://code.google.com/p/v8-juice/wiki/HomePage https://code.google.com/p/v8-juice/wiki/HomePage and https://code.google.com/p/v8-juice/wiki/V8Convert https://code.google.com/p/v8-juice/wiki/V8Convert

jey 13y ago

What's the gist of these supposedly major changes to the V8 APIs?

mraleph 13y ago
In short it was easy to misuse global v8::Persistent<T>`handles leading to memory corruptions and such. Unfortunately making them safe to use also means making them hard to use directly. Previously they were just interchangeable with normal v8::Local<T> handles for things like calls. https://groups.google.com/d/msg/v8-users/6kSAbnUb-rQ/e-GI0b1ThA4J https://groups.google.com/d/msg/v8-users/6kSAbnUb-rQ/e-GI0b1...
bradleyjg 13y ago
This seems to be the biggest issue: Changing all callbacks that return Handle<Value> to return void and instead pass the return value in as a parameter.
- mraleph 13y ago
  This is actually easy to work around by creating trampolines. Dan Carney creating a small header file with templates to create those trampolines easily: https://github.com/drcarney66/v8-backport https://github.com/drcarney66/v8-backport Amount of typing one needs to do is minimal, I think.
  - sgbeal 13y ago
    That approach doesn't work (without a lot of effort) with templates at the level cvv8 uses them. There are literally thousands of InvocationCallback instances in the cvv8 tree, most of which are bound via the XTo templates, which run through 4 or 5 layers of metatemplate magic to do their things. It's a bit more complicated than a drop-in replacement can solve unless the drop-in replacement has the same signature AND type name as the old one (and even then it would require more effort than i'm willing to commit to).

morgante 13y ago

I totally thought the headline was referring to Campbell discontinuing their disgusting beverage. Sadly this news is much sadder.

unreal37 13y ago
Looks like someone needs a V8.
mjcohen 13y ago
It's disgusting to you, not to many others (like myself). I even like the low-sodium version (having low standards can be very useful).

lttlrck 13y ago

To be clear his complaint concerns the public 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. 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.

sgbeal 13y ago
FWIW: your interpretation of my intentions is how i hoped they would come across :).

randallu 13y ago

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). 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).

olliej 13y ago
JSC should build cleanly on its own (e.g. no dependencies on anything on top of it.) It's possible some of the build scripts have developed a bizarro dependency on other portions of the repo, but we'd happily take patches to fix those issues. As far as APIs, JSC has provided a completely API and ABI stable C API for 7-ish years, and there's an ObjC API built on top of that now. Unfortunately the nature of C APIs for interacting with language runtimes makes it somewhat clunky and hard to use perfectly - C++ makes this easier as you can make types with constructors and destructors to make a lot of the otherwise manual work (ref()/deref(), etc) entirely automatic. Unfortunately C++ makes it easy to make an API that has a stable interface, but still isn't ABI stable.
- azakai 13y ago
  People build jsc on its own on mac, but I have never been successful on linux. Hopefully there is some way though? I've been forced to build all of WebKit-gtk. A bigger concern for me personally is that the jsc shell lacks typed arrays, https://bugs.webkit.org/show_bug.cgi?id=119828 https://bugs.webkit.org/show_bug.cgi?id=119828 edit: i should have said 'full spec for typed arrays', see the linked issue
  - olliej 13y ago
    The typed arrays should be available in trunk, haves you checked recent trunk? I believe the "need all of webkit-gtk" was a pile of sadness in build-jsc + automake that may have been fixed recently. I'm sure Zan, Xan, or Michel would be happy to help if it's still borked. There are _some_ platform requirements that make a generic "linux" not work, as we build on the platform support libraries for threads, unicode, etc so JSC may have random looking dependencies on such

gojomo 13y ago

A better headline than either the original or the reversion-to-page-title would be: Maintainer of v8-juice/cvv8: "Sayonara, V8"

kevingadd 13y ago
Wow, what a poor choice on the part of the mod who decided to change this headline.
fridek 13y ago
I didn't wanted to make sensational title that says nothing about content. I hate this on HN. Such attention hunting is an act without honor. Article is about V8-juice author abandoning his library for reasons that I don't personally consider right or wrong. I wanted to share this because there is a slight chance that state of V8 documentation (which I've never seen or used myself) is a political decision on a higher level (too little outcome from too much effort) and some discussion around the topic may change that.

glhaynes 13y ago

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).

shardling 13y ago
Yeah, whoever changed the headline accidentally made it misleading click-bait.

leokun 13y ago

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. 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.

oso2k 13y ago
I've had several interactions with Stephan. He's offered several times (dozens maybe) to do contract work (or otherwise) to create, update and maintain the public interfaces documentation and any supporting documents during the least 3 years. Google's stance (via its devs) has always been that v8's sole purpose (in their view) is as the JS VM for Chrome. It is not a product like GWT. Promotion of its capabilities is as of a consequence of v8 being connected to Chrome. For the most part, Stephan's offers have been completely ignored with a couple devs occasionally accusing him of grandstanding. I do feel that, however, for whatever reason, Google has demonstrated a personal affinity for certain embedders (node.js specifically, CEF maybe) vs. the lesser know embedders (v8-juice, TeaJS, SilkJS, NarwhalJS). I don't agree that Stephan has assigned himself too much self-importance. In fact, Stephan devoted significant time to identifying corner cases in the public interfaces that are beneficial to all embedders and has always chosen to make those learning experiences public, either via the GoogleCode Wiki or on the various v8 lists.
- sgbeal 13y ago

deleted 13y ago

[deleted]

dpe82 13y ago

This is a huge loss. cvv8 has made writing nodejs native addons for large APIs much 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.

sgbeal 13y ago
i'm happy to hand over admin access to the repo as soon as someone asks for it. i would really hate to see cvv8 go to waste (IMH (and biased) opinion it's the best binding/conversion lib for v8), but i can't deal with them pulling the rug out from under me again (this is not the first time they've done it, only the most invasive, and it IS the first time they've warned us in advance).
- dpe82 13y ago
  I would love to but also don't have the bandwidth. By the way, thank you for all your work. It took me quite a while to wrap my head around the template craziness you use in cvv8 but it turns out being pretty awesome. We have a huge API surface we're using cvv8 on and so far it's working great. IMHO probably the best approach that I haven't seen anyone but the chromium project use would be a bindings compiler that takes WebIDL and generates wrapper code. I started down that path before diving into cvv8, but didn't understand well enough what my compiler should output. May have to revisit that project at some point if we want to upgrade beyond node 0.10.
  - sgbeal 13y ago
    Thank you for your kind words. It took me a good long while to get my mind wrapped around the templates well enough to implement it. It was a very incremental process, starting with the basic type conversions and culminating in the function conversions and XTo templates. It was a really, really fun ride. Anyway... you "could" write a wrapper which generates cvv8 bindings. i did that long ago in a predecessor to generate about a hundred ncurses bindings. But... that assumes cvv8 is usable, which it is not with current v8 versions :`(.

general_failure 13y ago

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.

dottrap 13y ago

The SWIG effort is struggling with the changing API too. https://github.com/oliver----/swig-v8/pull/9 https://github.com/oliver----/swig-v8/pull/9