From dev-return-25053-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Thu Jan 31 16:24:13 2013 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 394B4E4DB for ; Thu, 31 Jan 2013 16:24:13 +0000 (UTC) Received: (qmail 35946 invoked by uid 500); 31 Jan 2013 16:24:12 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 35900 invoked by uid 500); 31 Jan 2013 16:24:12 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 35806 invoked by uid 99); 31 Jan 2013 16:24:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Jan 2013 16:24:11 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of bchesneau@gmail.com designates 209.85.223.180 as permitted sender) Received: from [209.85.223.180] (HELO mail-ie0-f180.google.com) (209.85.223.180) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Jan 2013 16:24:04 +0000 Received: by mail-ie0-f180.google.com with SMTP id bn7so1564073ieb.11 for ; Thu, 31 Jan 2013 08:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=91wdDtqt8Yf/WZ/948+CZFuiYUs3mVzTf21+jsXVxIA=; b=feuFRD870I+V0+dB+6Pj8dO1fhcccHNHInqR0M1NgNSODcO/KcySBADG7crc1JUaSl eRZ3RQZIhtlaM6M+kg8CEKVNr85Xj3bxYQm2k9mUIVjG96LWb7lmQBtrjcNOa1NDR6/b 3uS13/xObl4SRRA/HGbLhJnh5CWpGcHv2FMlurwfWr3mdcg9i/rqCz+NEMNyDB+g1vEt OXPyWFR/Un/R1I0ho3VOVb64sTK5k5oJVNWbtCU3Msn+CbBjgq3j3CLKm2jOD/ud7s21 WdyZEdHn0lbDBkAxNypkjjwiOVDkDMph1a1rr4m33VgLLeQwzB046dxkZxwGV8O0oHyB UnJQ== MIME-Version: 1.0 X-Received: by 10.50.187.169 with SMTP id ft9mr1638771igc.25.1359649423361; Thu, 31 Jan 2013 08:23:43 -0800 (PST) Received: by 10.64.29.13 with HTTP; Thu, 31 Jan 2013 08:23:43 -0800 (PST) In-Reply-To: References: <5102B439.10500@lymegreen.co.uk> Date: Thu, 31 Jan 2013 17:23:43 +0100 Message-ID: Subject: Re: Branch to switch from SpiderMonkey to Node.js From: Benoit Chesneau To: "dev@couchdb.apache.org" Content-Type: multipart/alternative; boundary=14dae9340575e608c104d4980c00 X-Virus-Checked: Checked by ClamAV on apache.org --14dae9340575e608c104d4980c00 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Jan 31, 2013 at 5:19 PM, Jan Lehnardt wrote: > > On Jan 31, 2013, at 17:14 , Benoit Chesneau wrote: > > > On Thu, Jan 31, 2013 at 4:35 PM, Jason Smith wrote: > > > >> On Thu, Jan 31, 2013 at 3:06 PM, Benoit Chesneau >>> 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 th= e > >>> 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 > 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 > >>> 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, an= d > >>>>>> 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). E= nd > >>>>> users are a totally different story. They may be able to install it= , > >>>>> but we're talking about adding a runtime dependency unless we bundl= e > >>>>> 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 lin= es > >> of > >>>> view server JS code: none of it was ever intended for Node.js. But t= he > >>> 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 t= o > >> 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 lik= e > >>> 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 hand= le > >>> 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 syst= em > >> are > >>> running under python. You can also write a view server in python in o= ne > >> 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 technica= l > > 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 thin= k > > what you want here is a TCP or UNix socket to allows request to wait an= d > > 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=92t changed since we start= ed > this. JS also gets the most engine development of any of the languages > even outpacing Java, but that=92s 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=92t support the= se > 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=EEt --14dae9340575e608c104d4980c00--