Speaking of which, I really hope at one point you reconsider the driver model. Having official drivers for only a few not-so-awesomely-typed languages is a big turnoff.
Speaking of which, I really hope at one point you reconsider the driver model. Having official drivers for only a few not-so-awesomely-typed languages is a big turnoff.
Yes, very similar, but there are a few major differences -- open-source product, horizontally scalable, json data model, packaging/api designed for web developers from the ground up. When you add all of these up, the differences are quite dramatic.
> I really hope at one point you reconsider the driver model.
Yes -- after 2.0 is out, we'll start bringing the community drivers under the official umbrella.
The issue is that modern application need to work on mobiles and browsers, and be responsive. To be responsive you need to bring the part of the state that can be reached via the UI to the device. This suddenly makes your database distributed among your servers and your client devices.
The device may be a mobile phone or a laptop in an airplane, and it needs to work offline and on networks with high latency. This means you need to have an eventually consistent AP database across servers, browsers and mobiles.
Currently databases assume they live on servers and we hack our way with distributed state on the clients, but I hope this won't last.
- Eventually consistent systems are fundamentally more difficult
to program for average developers than immediately consistent
ones (and when a more convenient system is an option, it wins)
- Connectivity is improving and will continue to improve, so
immediately consistent systems will always be a strong option
It remains to be seen whether these hypotheses prove to be correct in practice. We'll find out soon.Looking forward to 2.0.