couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Thu, 31 Jan 2013 16:14:03 GMT
On Thu, Jan 31, 2013 at 4:35 PM, Jason Smith <jhs@iriscouch.com> wrote:

> On Thu, Jan 31, 2013 at 3:06 PM, Benoit Chesneau <bchesneau@gmail.com
> >wrote:
>
> > Here are some notes following your *enthousiast* mail. There is not
> > intention to diminish the work or things like it. It is intended to
> temper
> > a little this enthousiast and trying to find the right approach on the
> > problems we are trying to solve.
> >
>
> Totally! Like I said, I would never use this code in production. It is a
> highly experimental branch. I have a roadmap for this branch; but the real
> goal is conversation.
>
>
> >
> >
> > On Thu, Jan 31, 2013 at 3:46 PM, Jason Smith <jhs@iriscouch.com> wrote:
> >
> > > On Thu, Jan 31, 2013 at 1:51 PM, Randall Leeds <
> randall.leeds@gmail.com
> > > >wrote:
> > >
> > > > On Thu, Jan 31, 2013 at 5:23 AM, Jason Smith <jhs@iriscouch.com>
> > wrote:
> > > > > On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis <
> > > > paul.joseph.davis@gmail.com>wrote:
> > > > >
> > > > >>
> > > > >> That whole process sounds like not a lot of fun.
> > > > >>
> > > > >
> > > > > Right. That is kind of my point. CouchDB is a JavaScript thing, and
> > > > > nowadays people have a very well-adopted and well-understood
> > JavaScript
> > > > > engine on their computers. Maybe it should just use that.
> > > >
> > > > (Some) developers have node installed (or can install it easily). End
> > > > users are a totally different story. They may be able to install it,
> > > > but we're talking about adding a runtime dependency unless we bundle
> > > > node.
> > > >
> > >
> > >  Quite right. This branch answers half that question: what do you get?
> > >
> > > So far, this is my list of good things I've seen:
> > >
> > > 1. Better code.
> > > 1a. Cut almost 3,000 lines of code
> > > 1b. Exchanged SM build dependency for Node runtime dependency. This
> right
> > > here--this summarizes the whole exercise.
> > >
> > > 2. Very encouraging degree of compatibility. Consider, the 1,500 lines
> of
> > > view server JS code: none of it was ever intended for Node.js. But the
> > test
> > > suite shows, the two are virtually identical.
> > >
> > >  3. Apparently this is already easier to use than homebrew. Homebrew
> pins
> > > SM apparently to support Mongo (unsure if the latter is true).
> > >
> > > 4. Got a lot of enthusiasm. (A lot of people tested it and emailed to
> ask
> > > "why isn't it faster?"). This thread got a lot of feedback about new
> > > protocols, and async APIs, and app-building features. Why? I think when
> > you
> > > say Node.js and CouchDB everybody says "Yes!"
> > >
> >
> >
> > I say "maybe". nodejs is quite trendy. but also quite new and didn't
> really
> > prove anything right now. It is quite surpassed by a pure C thing like
> > nginx/uwsgi when it's about http, and when it's about stability by erlang
> > or some. I also never had any need of nodejs when it was about doing
> things
> > with couchdb. Differerent approach I guess. Not saying the nodejs is a
> bad
> > one. If it solves your problems or at least is easier for you to handle
> > then that's perfectly fine.  One true thing is that javascript is really
> > user friendly and this thing is the one that count.
> >
>
> I agree about the "trendy" concern. That is part of the cost, for sure.
>
> I am not sure what point you are making, about the http stack and
> stability. I believe a pure-node view server can meet your performance and
> stability requirements.
>
>
> > About the number of lines. Well you don't count all the lines in
> nodejs+v8
> > as well ... but the number of loc isn't really an argument I guess.
> >
> >
> > > Imagine you have CouchDB installed and then a future node version
> > > > breaks compatibility for some API used by the node-couchjs. You now
> > > > have to decide whether to upgrade node or try to have multiple node
> > > > versions so couchjs can continue to work.
> > > >
> > > > In short I think this is my issue: we're pushing problems down from
> > > > maintainers and packagers to users.
> > > >
> > >
> > > If you want API stability, then you'll like Node.js. The whole
> principle
> > of
> > > the project is to be "finished" one day.
> > >
> > > Node.js is less likely than Python, say, to break a simple, 300-line
> repl
> > > program. (My point is: not likely.) But yes, you've put your finger on
> > it.
> > > This is a runtime dependency.
> > >
> >
> > This has nothing with the langage. Considering that a lot of big system
> are
> > running under python. You can also write a view server in python in one
> day
> > as fast as the nodejs server using libuv for example.  or other
> eventloops
> > that didn't wait nodejs to exist.
> >
>
> Awesome. Please show us a view server written in Python with libuv,
> completed within one day. That will be very informative to this discussion.
> We can look at all the working, real-world view server implementations, and
> we can compare them.
>


I wish i had time to play with that. The point is that javascript or nodejs
don't change anything. What are advantages of nodejs on a pure technical
aspect:

- v8 for javascript
- libuv for everything else


if you do it in python then you have python and pyuv. Doing the things you
did was the same. Though I don't see the point of having fibers. I think
what you want here is a TCP or UNix socket to allows request to wait and
handle them in a parallel way. It would also remove the number of OS
processes.


> No, I am not ignoring them. I am collecting them. I feel like my list I've
> built is a good start but not yet comprehensive.
>
>
ok

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message