FDB itself is written in Flow, which is 98% C++ with a few extra keywords thrown on top that gets compiled to actual C++. This gives them actor model concurrency in C++ that is completely deterministic by generating very ugly code that uses callbacks instead of threads or coroutines.
The reason for Java being used here, if I had to guess, is they have experience running Java in production and the Java bindings are the most mature (in my opinion). Writing the record layer in C++ would probably be overkill. The reason the Java bindings are the most mature is probably because they needed to be to write this :)
Mind to elaborate on why C++ would be overkill? I understand the layered architecture decouples data model from underlying storage so it can be implemented in whatever language. To me, Flow and not having GC makes C++ a good choice.
It would be a fine choice, (and the document layer is) but the most performance sensitive parts of the entire system when you take it as a whole are already written in Flow. Writing it in C++ entirely would take a lot longer.
Also, it’s just as possible that open sourcing it earlier could have just bogged down the decision making because of alignment issues and caused it to fail.
Open sourcing is great and the more companies like Apple do it the better, but assuming that earlier is always better doesn’t seem justified.
Apple's server-side WebObjects stuff is all written in Java; and IIRC, the original Control Panel for OS X was in Java using the ObjC/Cocoa bridge stuff.
It still makes me sad that Apple dropped the Java Cocoa bindings. That could have been a really great thing for cross platform development (probably the reason).
This was a little disappointing to me; the paper[0] pitches as a design principle it’s efficiency and embeddability but it’s not clear to me how one could achieve this except in another JVM-based language. This is in contrast to the core fdb client library, which is ~easy to embed all over as it’s in C.
So it seems like services in languages like Go, Rust, python, node, etc are essentially forced to dream up a bespoke wire protocol and revert to the client-server approach. Am I missing something?
I think the idea is that this layer could be exposed via a networked API. Though now there would be another layer of services to manage with all the associated, deployment, security, operability issues.
It wasn't directly stated as the reason for this choice, but being a heavy user of Cassandra and migrating away from it likely played a factor. It may have been that they had already developed a lot of supporting functions around Cassandra in Java and naturally led to the development of Record Layer in same.
The reason for Java being used here, if I had to guess, is they have experience running Java in production and the Java bindings are the most mature (in my opinion). Writing the record layer in C++ would probably be overkill. The reason the Java bindings are the most mature is probably because they needed to be to write this :)