Hi, I'm slava@rethink, I'm ultimately responsible for what goes into the product and when.
We'd love to get more drivers in (and the new, much simpler protocol we just shipped will go a long way towards community-supported drivers). But we decided that having a high quality product for the people using the drivers we do support is currently much more important than having wider driver support. Once we iron out a few more quirks in the core product, adding more drivers will be really easy. But until then, more drivers will help fewer people than improvements to the core language and product.
(BTW, getting Rethink to JVM users is something I'm personally very interested in, in my case because of Clojure, but Java programmers will also benefit)
I must say that I am very glad to read this, since I am also looking forward to deploy RethinkDB alongside Clojure (or Erlang, but I fear that will have to wait for quite a while).
Nonetheless, I must agree that focusing on the DB itself is for the best. Keep up the excellent work.
I've got a branch of Nashorn (Oracle's Javascript runtime which will be included in OpenJDK 8) modified to build with Java 7. It passes 100% of the ECMA-262 test suite and you can grab it at http://github.com/furosys/nashorn
Nashorn would let you get rid of the Javascript Protobufs implementation and use the Java library from Google, among other potential optimizations.
Still not, but the new protobuf spec (and rewritten existing drivers) should actually make it pretty easy to get one. I've also heard of a couple of people working on Java and Scala drivers (they were following the new protobuf spec branch), but I don't know the status.
So it won't be official and it may break on any server update or lag in features depending on the maintainer boredom. Too bad, your db seems really nice :)
There's no decision made on this yet. So far, as @coffeemug explained in the previous comment we decided to focus all our efforts on improving the server and getting it closer to "production ready" state, instead of spreading our resources thin and creating a lot of drivers that are not as good as we'd want them to be. The initial protobuf spec was complicated and building drivers on top of it would have required a lot of effort (effort that we thought would be better used to improve the spec and the query language, things that everyone would benefit).
All of that work improving the spec and the query language should make it that much easier to make a decent driver. I'd say around the time of it being "production ready" as you put it should be where you have a version that keeps the same protocol so that drivers can be written and not have to be updated for every bug fix?
No, you're absolutely right -- when we mark Rethink as production-ready, we'll also freeze the APIs and ABIs and will be much more careful about breaking things for people.
We'd love to get more drivers in (and the new, much simpler protocol we just shipped will go a long way towards community-supported drivers). But we decided that having a high quality product for the people using the drivers we do support is currently much more important than having wider driver support. Once we iron out a few more quirks in the core product, adding more drivers will be really easy. But until then, more drivers will help fewer people than improvements to the core language and product.
(BTW, getting Rethink to JVM users is something I'm personally very interested in, in my case because of Clojure, but Java programmers will also benefit)