On Jan 31, 2013, at 17:23 , Benoit Chesneau <[email protected]> wrote:
> On Thu, Jan 31, 2013 at 5:19 PM, Jan Lehnardt <[email protected]> wrote: > >> >> On Jan 31, 2013, at 17:14 , Benoit Chesneau <[email protected]> wrote: >> >>> On Thu, Jan 31, 2013 at 4:35 PM, Jason Smith <[email protected]> wrote: >>> >>>> On Thu, Jan 31, 2013 at 3:06 PM, Benoit Chesneau <[email protected] >>>>> 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 <[email protected]> >> wrote: >>>>> >>>>>> On Thu, Jan 31, 2013 at 1:51 PM, Randall Leeds < >>>> [email protected] >>>>>>> wrote: >>>>>> >>>>>>> On Thu, Jan 31, 2013 at 5:23 AM, Jason Smith <[email protected]> >>>>> wrote: >>>>>>>> On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis < >>>>>>> [email protected]>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. Cool, thanks for clarifying, I must have gotten the context wrong! Jan --
