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:23:43 GMT
On Thu, Jan 31, 2013 at 5:19 PM, Jan Lehnardt <jan@apache.org> wrote:

>
> On Jan 31, 2013, at 17:14 , Benoit Chesneau <bchesneau@gmail.com> wrote:
>
> > 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.
>
> Today, CouchDB supports JavaScript for the sole reason that it is most
> widely distributed, developed and exercised programming language and
> that the JS required to us CouchDB is little enough to not be scared of
> it if your main language is another. This hasn’t changed since we started
> this. JS also gets the most engine development of any of the languages
> even outpacing Java, but that’s an aside.
>
> There is no argument to be made that a Python or Ruby or whatever else
> is technically similar or potentially even better. We don’t support these
> today.
>
> To be absolutely clear, if a year from now we support all of them, that
> be super duper fantastic in my book, really and honestly.
>
> But that is not a situation that we are in today, so asking how this is
> better than a Python server is easy to answer: because Python is not JS.
>
> Best
> Jan
> --
>
>
I didn't say python was superior or that I wanted a python version. I
don't. I am all for having JS in couchdb.  I was answering to jason
argument. Javascript has nothing to do with performance or ease of code.
And like I said the true thing is that javascript is really user-friendly
and  has an awesome community that support it.

- benoît

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