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 E3D0CE39B for ; Thu, 31 Jan 2013 16:20:22 +0000 (UTC) Received: (qmail 11238 invoked by uid 500); 31 Jan 2013 16:20:22 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 11202 invoked by uid 500); 31 Jan 2013 16:20:22 -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 11182 invoked by uid 99); 31 Jan 2013 16:20:22 -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:20:22 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [80.244.253.218] (HELO mail.traeumt.net) (80.244.253.218) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Jan 2013 16:20:13 +0000 Received: from [10.0.0.27] (91-66-82-235-dynip.superkabel.de [91.66.82.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.traeumt.net (Postfix) with ESMTPSA id F404C143D0 for ; Thu, 31 Jan 2013 17:15:29 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Branch to switch from SpiderMonkey to Node.js From: Jan Lehnardt In-Reply-To: Date: Thu, 31 Jan 2013 17:19:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5102B439.10500@lymegreen.co.uk> To: dev@couchdb.apache.org X-Mailer: Apple Mail (2.1499) X-Virus-Checked: Checked by ClamAV on apache.org On Jan 31, 2013, at 17:14 , Benoit Chesneau wrote: > On Thu, Jan 31, 2013 at 4:35 PM, Jason Smith = wrote: >=20 >> On Thu, Jan 31, 2013 at 3:06 PM, Benoit Chesneau >> wrote: >>=20 >>> 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. >>>=20 >>=20 >> 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. >>=20 >>=20 >>>=20 >>>=20 >>> On Thu, Jan 31, 2013 at 3:46 PM, Jason Smith = wrote: >>>=20 >>>> On Thu, Jan 31, 2013 at 1:51 PM, Randall Leeds < >> randall.leeds@gmail.com >>>>> wrote: >>>>=20 >>>>> 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: >>>>>>=20 >>>>>>>=20 >>>>>>> That whole process sounds like not a lot of fun. >>>>>>>=20 >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> (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. >>>>>=20 >>>>=20 >>>> Quite right. This branch answers half that question: what do you = get? >>>>=20 >>>> So far, this is my list of good things I've seen: >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 3. Apparently this is already easier to use than homebrew. Homebrew >> pins >>>> SM apparently to support Mongo (unsure if the latter is true). >>>>=20 >>>> 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!" >>>>=20 >>>=20 >>>=20 >>> 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. >>>=20 >>=20 >> I agree about the "trendy" concern. That is part of the cost, for = sure. >>=20 >> 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. >>=20 >>=20 >>> 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. >>>=20 >>>=20 >>>> 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. >>>>>=20 >>>>> In short I think this is my issue: we're pushing problems down = from >>>>> maintainers and packagers to users. >>>>>=20 >>>>=20 >>>> If you want API stability, then you'll like Node.js. The whole >> principle >>> of >>>> the project is to be "finished" one day. >>>>=20 >>>> 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. >>>>=20 >>>=20 >>> 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. >>>=20 >>=20 >> 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. >>=20 >=20 >=20 > 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: >=20 > - v8 for javascript > - libuv for everything else >=20 >=20 > 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=92t changed since we = started 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 = 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 --=20