couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Why CouchDB uses JavaScript (Was: make all this extra C optionnal)
Date Sat, 21 Sep 2013 09:51:36 GMT

On Sep 21, 2013, at 11:48 , Benoit Chesneau <> wrote:

> On Fri, Sep 20, 2013 at 4:56 PM, Jan Lehnardt <> wrote:
>> On Sep 19, 2013, at 11:51 , Benoit Chesneau <> wrote:
>>> Hi,
>>> I am thinking to make all this extra C optional in couchdb. By extra C I
>>> mean:
>>> - snappy compression
>>> - couch compare function using ICU
>>> - JS views
>>> - JSON encoding
>>> Basically anything that is not included in the erlang standard library or
>>> not in Erlang. The reason for that is to allow a simple distribution on
>>> different platforms or vms things like erlangonxen. Also it would
>> improve a
>>> lot the way we can upgrade a full release or change a module live.
>>> First one is easy, the second I don't know I guess we can have a more
>>> simpler binary comparison is possible or maybe better providing a pure
>>> erlang implementation of it using ux [1] wich is probably enough faster
>> for
>>> our need (we only require to compare ids or keys).
>>> We mostly have JS because it's easy to handle for an end-developer and
>> also
>>> trendy among some circles.
>> I massively support moving to a tiny Erlang-only core for CouchDB with
>> additional features on the side.
>> We need to differentiate between what the core of CouchDB is and what the
>> distribution we ship to end users includes. I would not feel comfortable
>> shipping a major version of CouchDB in the future that doesn’t include
>> JavaScript powered views. Instead, I think it should be very simple for
>> us to ship, or for users to compile, a version of CouchDB that is just
>> the core, or just the core and only the extensions they are interested
>> in, not the ones that we think are a good default for everyone (someone
>> might want to have a CouchDB distribution without a replicator and that
>> should be totally easy to set up).
>> (Not saying it was suggested that CouchDB-core should be the default
>> distribution, I just want to point out that it is an important
>> distinction to make)
>> Why do I think we should not ship a CouchDB version without JavaScript?
>> This is a direct reaction to “trendy among some circles”. JavaScript is
>> by far the most deployed, the most programmed and the most understood
>> programming language in the world and it is only gaining at this point.
>> To pretend that it is a niche phenomenon is ignoring the massive
>> advantages we gain from shipping JavaScript support by default. Nearly
>> everyone knows at least enough JavaScript to get something done in
>> CouchDB, that is a benefit that I don’t see go away any time soon and
>> I think it is *very* important for us to keep this going.
>> I am very eager to support JS alternatives, and I am #1 in longing for
>> a neat DSL (hopefully done on top of Erlang or Elexir) that allows us
>> to define views and other useful things in a neat declarative way. But
>> we don’t have that yet, and for when we do, I still thing enough use
>> cases that require a bona-fide programming language and the best one
>> for that in today’s world and the near future is JavaScript. I’m not
>> saying JavaScript is the best programming language, but given what we
>> need a programming language for, JavaScript is the best option we have.
>> That’s why I think Apache CouchDB should ship with a JavaScript
>> interpreter by default for the foreseeable future.
>> I also very much support the idea of a pure-Erlang core for the users
>> that need that, but we need to make sure we do the right thing for most
>> of our end users in a way that doesn’t disadvantage the rest and I
>> think the scenario of a small core as suggested + addons that make up
>> a default distribution with the possibility of making custom
>> distributions easily gets us exactly that.
>> Best
>> Jan
>> --
> We can disapprove or not about the the popularity of Javascript neither if
> it's really understood by most or if it is the best programming language.
> It really depends in which branch you are working in computer industry:
> web, game, science, ...  or which kind of company. Each have their winner,
> and for example  in the game industry, javascript is only starting to come
> in, some are using different scripting languages...  It is also depends on
> what you consider programming is, if you value the readability or not, such
> things. Only the future will tell us, which kind of programming will win,
> even if some are trying hard to remove the choice these days by imposing a
> language in their UI or their devices.
> Anyway I don't really care if Apache CouchDB has to be shipped with
> Javascript support or not. The point here is more here to have a way to
> disable it, to make it optional so people can deploy and upgrade it more
> easily according their needs. And I don't see any reason for now to not
> ship Apache CouchDB with javascript until it can be made optional during
> the build.

Yeah, that’s exactly what I thought you mean. I just wanted to make sure
we don’t end up in a situation where we start arguing for the removal of
JavaScript :)


> - benoit
>>> But i think we could provide here another
>>> default. That can be elixir [2] or lua using luerl module [3]. The second
>>> one may be the easier since it is also provide for free the sandbox we
>> are
>>> supposed to have in JS. Not sure it is easy to do with elixir.
>>> Thoughts?
>>> - benoit
>>> [1]
>>> [2]
>>> [3]

View raw message