Hey all. Slava here @ RethinkDB.
If you have any questions about the release, product roadmap, or anything RethinkDB-related, please ask! I'll be around all day to answer questions and incorporate your comments into the development roadmap.
If you have any questions about the release, product roadmap, or anything RethinkDB-related, please ask! I'll be around all day to answer questions and incorporate your comments into the development roadmap.
I followed the relevant issues on GitHub closely, and for what it's worth I think you made the right choice - certainly this fits the way I want to store binary data in the database. It's a better system than even CouchDB attachments, what I'm currently using[0], and so much better than GridFS, a great solution to the wrong problem of how to engineer a storage layer on top of MongoDB, when my actual problem is: "how do I store this avatar image alongside this user as simply as possible."
Knowing how much attention was paid to "getting it right" on this one feature I paid particular attention to significantly bolsters my faith[1] in the engineering quality of the project as a whole.
[0] and what ultimately made me chose Couch over Rethink for my current project
[1] which was already high.
FYI, the filesystem feature is still on the horizon. The current implementation is good for small files like avatars, the upcoming one will be good for large files like videos. The distributed FS will almost certainly be use `r.binary` as a building block, which will result in a neatly modularized design overall.
I should have a better idea of what the comparison looks like after we get a little further along.
Here is how the R&D projects have worked thus far. We implemented a RethinkDB protocol compatible server in JavaScript (which is surprisingly easy), so that a lightweight version of the server can run in the browser. If you use the JS driver in the browser with this server, all queries continue to just work.
Behind the scenes the in-browser server can sync up data with the real server, so everything can work while the browser/mobile device goes offline.
It's not too hard to build a prototype (and we've seen a few), but getting it to production involves a non-trivial effort; plus we'd have to support the feature indefinitely which would add a significant development cost.
Lots of people have asked for this, so I'd like to find a way to make it happen. @neumino has a version of this in the works right now, so we might just polish it up and release it to the community.
What are the plans for supporting java/clojure/scala and go-lang?
We've been working really hard to keep the surface area of the product minimal so the dev team can stay nimble, which so far allowed us to ship features and stability improvements very quickly. We have a lot of really exciting updates planned for the next few releases, so we'd like to stick to the current model for now. After that, we'll start expanding the dev team and bringing some of the community drivers under the official RethinkDB umbrella. I don't have an ETA for this yet, but I expect this will happen within a year or so.