couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Why CouchDB uses JavaScript (Was: make all this extra C optionnal)
Date Fri, 20 Sep 2013 14:56:22 GMT

On Sep 19, 2013, at 11:51 , Benoit Chesneau <bchesneau@gmail.com> 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
-- 


> 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] https://github.com/erlang-unicode/ux
> [2] http://elixir-lang.org/
> [3] https://github.com/rvirding/luerl


Mime
View raw message