

NodeJS: To V8 or not to V8 - fosk
http://www.olympum.com/future/nodejs-to-v8-or-not-to-v8/

======
bronson
This is a stale nothingburger. Summary:

Bruno: "V8 was not designed as a server-side engine, but as a browser-based
engine. Furthermore, V8 was designed squarely to run in Chrome’s multi-process
model. As much as I think V8 is a brilliant piece of engineering, it’s
software that was not designed to run on a server."

Jason: "I don’t know what this means, or if there’s a difference. More details
here would be helpful."

Bruno: "The discussion is not really whether I have technical production
problems or not with V8 (within NodeJS); all software has bugs. My issue is
about project governance. ... It’s not whether Google’s V8 project is open or
not, it’s that since governance of V8 may become a problem in the future, it
requires a solution now so that large organisations can put their full weight
behind NodeJS."

No idea what sort of patch Bruno is looking for and I don't think Bruno knows
either. He's sure not articulating his concern very well.

------
maxogden
At NodeConf Summercamp this week Ryan Dahl remarked that the V8 team is very
responsive and happy to fix to reports such as "this part of V8 is slow and
shouldn't be, can you please make it faster".

He also acknowledged that Google is obviously building V8 for Chrome and not
Node and shouldn't be expected to spend time and money on features that aren't
beneficial to Chrome. One example of this is the time required to spawn a new
V8 context, around 30ms. It could be made drastically faster if all security
features were removed from the V8 boot process (not needed for server side
trusted execution environments) but Google needs secure VMs for Chrome tabs
and it wouldn't make sense for Chrome to spend time optimizing V8 for this use
case.

I didn't get the feeling, however, as this article implies, that V8 is a
"roadblock" for Node.

~~~
mamp
The main item I seem to recall Ryan Dahl and others commenting on was V8's
garbage collection which is pretty laze because web pages don't stay open for
long periods of time. Obviously this is different on the server. If true,
that's pretty deep change inside V8 required for Node.

~~~
mraleph
There are a public issue tracker and v8-users mailing list.

If somebody is experiencing problems with GC then they should stop by and ask
or file an issue or submit a benchmark/testcase...

------
chapel
This is an old post. Google has continually improved v8 and those improvements
have helped Node.js in the process.

I think the hoopla over Node.js using v8 or if it shouldn't has died down and
for good reason.

~~~
merlincorey
What about when v8 is discontinued to promote Dash?

~~~
dmpk2k
Unlikely.

But if that happens, Google isn't the only company in the world with the
knowledge and ability to maintain V8. Joyent does as well.

But let's assume something even more unlikely: Google, Joyent and the rest of
the world drop V8. nodejs is an open-source project.

You might as well worry about being hit by lightning.

------
sambeau
My summary:

Bruno: "Node is doomed as V8 was not designed as a server-side engine. We must
panic now"

Jason: "There is no need to panic now. Once we finish Node v1 we will start
modifying V8 to make Node more awesome. We are not scared to fork if need be"

------
veyron
What alternatives exist in the server side JavaScript space (that are actively
maintained and used by HN readers)?

~~~
nirvana
Depending on what you want to do, Riak is a NoSQL database that uses
javascript for map/reduce.

erlang_js is a competing javascript VM (embeds spidermonkey)

And I'm working on a new web platform based on Riak that allows the developer
to write their apps in coffeescript and I use erlang (and parts of riak) to
distribute the load around a cluster of machines each of which is running
multiple javascript virtual machines. (But this is not yet released... follow
@nirvanacore on twitter if you wish to keep up to date.)

~~~
veyron
Is there a public repo we can peek at / contribute to?

~~~
nirvana
Not yet. I'm working on the "simplest thing that could possibly work" version,
that sets out the architecture. I'm hopeful that, when its released, it will
be compelling enough that people will want to jump in and help me build it
out. But at this point, it would take too much explaining to get the idea
across. Once the simplest thing is done, I'll be able to ship it with a simple
demo/tutorial which will hopefully be setting off lightbulbs above people's
heads.

------
JonnieCache
In case anyone else is getting deja vu here, this is from way back in
february.

------
wavephorm
There seemed to be some backlash when Mozilla started experimenting with a
SpiderMonkey-based NodeJS implementation. I'm not sure why. It seems like it
would be a really good thing to be able to run Node on other JavaScript
engines. Having options is a good thing.

------
nirvana
This is a real problem, if you're from the school that believes that processes
can crash. But it is also an issue if you believe it is possible to overload a
single process on a machine where multiple processes could better handle the
load. Nodejs runs a single v8 instance on a machine, or if you're running
multiple ones in parallel they don't really cooperate as they aren't really
aware of each other. So, if one gets behind its hard for the others to take up
the slack.

Here's a concurrent answer to this problem, that a future nodejs version might
consider adopting (and is the basis of the nirvana web platform I'm building):

Distribute requests across a series of javascript virtual machines running on
a collection of compute nodes. Multiple vm processes per node, and multiple
nodes per cluster.

Thus, if any one V8 process dies for whatever reason, you don't lose many
requests.

In fact, I believe losing even one request due to the crashing of a V8
process, would be considered a bug.

My solution to this involves using erlang at a fundamental level to distribute
load, and passing the requests off to various instances of a Javascript
Virtual Machines to handle the requests. The web developer writes their
application in coffeescript or javascript, and the platform takes care of
distribution, concurrency, etc.

The downside of this, of course, is that given that js isn't a really
concurrent language, there is a bit of an impedance mismatch... but I find
that this is equal to or less than the hassle of dealing with event driven
code in the first place.

If you're interested in my solution, we should hit alpha soon after Riak (the
underlying platform) hits 1.0 later this month. Follow me on twitter for
updates @nirvanacore (that twitter account only talks about the web platform,
no noise.)

