Hacker News Reader

Comment by sjroot | Hacker News Reader

I didn't expect this to be written in Java. Do they talk about this decision anywhere? I didn't catch anything in the announcement.

View on HN

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 :)

Wow people really have no imagination when it comes to naming languages.

Could you please provide a link to Flow?

https://github.com/apple/foundationdb/tree/master/flow

> Writing record layer in C++ would be overkill

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.

They acquired the company that made FoundationDB:

https://techcrunch.com/2015/03/24/apple-acquires-durable-dat...

This makes sense. Thank you for clarifying!

Now this is the kind of Embrace, Extend, Extinguish I like. I wish more companies bought technologies just to open source them.

The 4 year gap in the middle is unfortunate though, there could've been much more momentum by now had Apple kept it open all this time.

> ...4 year gap...

I don't think it was open in the first place, was it?

It was iirc

FoundationDB was not open source before it was acquired by Apple. They had a free version you could download and use, though.

There was no gap.

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).

I so miss EOF[1] and really wish it had made the transition to OS X.

1) https://en.wikipedia.org/wiki/Enterprise_Objects_Framework

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?

[0] https://www.foundationdb.org/files/record-layer-paper.pdf

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.

I believe a lot of their backend stuff is in Java.

Reply on news.ycombinator.com