
Sayonara, V8 - fridek
https://groups.google.com/forum/#!topic/v8-users/MUq5WrC2kcE
======
kevingadd
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.

~~~
mraleph
[disclaimer: I worked on V8]

I must say that public facing API is well documented right in the header
files. Each class and majority of important functions have long comments[1].
So claiming that V8 has an anti-documenation culture is incorrect. Next I
would like to note that V8 is surely open to patches that improve
documentation of public V8 interfaces. I don't remember a lot of those patches
flying in though.

Finally, documenting internals is completely different from documenting API. I
don't think it is feasible to maintain such documentation. Internals exist
only to rely on them in an extreme cases and in such extreme cases reaching to
V8 developers directly or reading the source code is the only way to get
correct and what is more important up to date information given how things are
constantly in flux.

[1]
[https://code.google.com/p/v8/source/browse/trunk/include/v8....](https://code.google.com/p/v8/source/browse/trunk/include/v8.h?r=16177)

~~~
kevingadd
I apologize if you got the impression I was claiming you don't document your
public-facing APIs. I'm talking about V8 as a system; intended behaviors and
recommended usage patterns and strategies, documentation of downsides and
weaknesses and such. The debug-related parts of the 'public' (? not sure if
they're actually public) API were very poorly documented when last I checked,
though - some of the debug flags you can pass to d8 were only documented in
old obscure blog posts.

~~~
ahomescu1
The problem with documenting internals is that it becomes a contract.
Developers then start relying on those documented behaviors, and it later
becomes much more difficult to change them.

It's bad enough as is with developers relying on undocumented behavior, see
the troubles Wine (and Microsoft as well) with applications that touch Windows
internals.

~~~
harlowja
Isn't it the right thing to do though? Open source should not be about hiding
behaviors behind undocumented code. Open source is about documenting it so
that others can learn and jump in and help. It seems totally non-open if this
is how V8 is developed.

~~~
spiffytech
There is a distinction between documenting the portions of your app you intend
people use, and effectively promising to maintain side effects and accidents
of your existing design. mraleph says the public API is documented, which
fulfills the obligation an open source project has.

However, the discussion here is about side effects of the V8 implementation,
as they relate to performance. That is to say, the V8 team is reluctant to do
anything that suggests "if you write javascript using this pattern, your code
will/will not run fast, but only because that's just how this week's code
branch works out". If the team made those sorts of promises with a project as
complex as V8, they effectively become locked in to their existing code,
unable to change or improve much of anything because they'd be breaking the
promises of performance patterns they previously issued.

The authors who are working with V8, on the other hand, require those promises
to be made. It's not enough for the performance patterns to be documented,
these authors need them to be fairly stable as well.

It's a tough situation - the V8 authors have made all the promises and
documentation that's practical for them to do, but it's not enough to satisfy
these other project authors' needs.

------
lttlrck
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
FWIW: your interpretation of my intentions is how i hoped they would come
across :).

------
glhaynes
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
Yeah, whoever changed the headline accidentally made it misleading click-bait.

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

------
gojomo
A better headline than either the original or the reversion-to-page-title
would be:

 _Maintainer of v8-juice /cvv8: "Sayonara, V8"_

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

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

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

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

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

------
dpe82
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
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
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
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
:`(.

~~~
dpe82
I meant to generate a full binding instead of using cvv8. bea[0] does
something similar, but is somewhat limited.

[0] [https://github.com/codeboost/bea](https://github.com/codeboost/bea)

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

~~~
Meai
Well I spent around 5 minutes downloading and trying to build, immediately
hitting this wall on Windows:
[http://i.imgur.com/J9Gs6wb.png](http://i.imgur.com/J9Gs6wb.png)

Seems that nobody has tried that in a long time, or who knows why it
references something in C:\tools

~~~
voltagex_
Yuck. If you are interested, perhaps a directory junction would get it far
enough along to fix the problems.

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

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

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

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

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

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

------
leokun
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
Again, Stephan has created and maintained multiple (46 in fact, [1])
treatments on what he has learned about v8. He even separated and a special
wiki category, called "BitchAndMoan" [2], just so people wouldn't be confused
about what were personal critiques and what were technical critiques. This
isn't an "HN echo chamber" or a "woe is me circle jerk". This is a critique of
Google's technical handling, feeding and nurturing of a (non-)product. I've
embedded JavaScript for almost 15 years, since Mozilla's SpiderMonkey was
ported to DOS/DJGPP[3][4]. There's dozens and dozens of successful embedders
of various size and purpose [5][6] supported by Mozilla via SpiderMonkey
and/or Rhino. While in college, I added LAM/MPI hooks and developed multi-
monitor applications years before multi-monitor graphics cards were
commercially available. Stephan is a former SpiderMonkey embedder[7]. I'm
former colleagues with Shanti Rao of JSDB (SpiderMonkey) while at NASA/JPL
[8]. There is a huge difference in support in what Mozilla provides [9] vs.
what Google provides [10]. Stephan's critique is, without a doubt, a fair
critique.

[1][http://code.google.com/p/v8-juice/w/list](http://code.google.com/p/v8-juice/w/list)
[2][http://code.google.com/p/v8-juice/wiki/CommentaryOnV8](http://code.google.com/p/v8-juice/wiki/CommentaryOnV8)
[3][http://marc.info/?l=freedos-
dev&m=94670703232745](http://marc.info/?l=freedos-dev&m=94670703232745)
[4][http://web.archive.org/web/*/http://dominic.liquid3.com.au/j...](http://web.archive.org/web/*/http://dominic.liquid3.com.au/js/)
[5][https://developer.mozilla.org/en-
US/docs/Web/JavaScript](https://developer.mozilla.org/en-
US/docs/Web/JavaScript)
[6][http://en.wikipedia.org/wiki/JavaScript#Uses_outside_web_pag...](http://en.wikipedia.org/wiki/JavaScript#Uses_outside_web_pages)
[7][http://spiderape.sourceforge.net/](http://spiderape.sourceforge.net/)
[8][http://www.jsdb.org/](http://www.jsdb.org/)
[9][https://developer.mozilla.org/en-
US/docs/SpiderMonkey](https://developer.mozilla.org/en-US/docs/SpiderMonkey)
[10][http://code.google.com/p/v8/w/list](http://code.google.com/p/v8/w/list)

~~~
sgbeal
If i ever commission a biography, i'm coming to you to write it for me ;).

