couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Thu, 31 Jan 2013 16:19:53 GMT

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






Mime
View raw message