35 ms·

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.

by sjroot 8y ago

giancarlostoro 8y ago
They acquired the company that made FoundationDB: https://techcrunch.com/2015/03/24/apple-acquires-durable-database-company-foundationdb/ https://techcrunch.com/2015/03/24/apple-acquires-durable-dat...
- sjroot 8y ago
  This makes sense. Thank you for clarifying!
- cmiller1 8y ago
  Now this is the kind of Embrace, Extend, Extinguish I like. I wish more companies bought technologies just to open source them.
  - manigandham 8y ago
    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.
    - jmull 8y ago
      > ...4 year gap... I don't think it was open in the first place, was it?
      - jbverschoor 8y ago
        It was iirc
        ryanworl 8y ago
        FoundationDB was not open source before it was acquired by Apple. They had a free version you could download and use, though.
    - zepto 8y ago
      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.
ryanworl 8y ago
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 :)
- drb91 8y ago
  Wow people really have no imagination when it comes to naming languages.
- polskibus 8y ago
  Could you please provide a link to Flow?
  - ryanworl 8y ago
    https://github.com/apple/foundationdb/tree/master/flow https://github.com/apple/foundationdb/tree/master/flow
- teacpde 8y ago
  > 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.
  - ryanworl 8y ago
    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.
neurobashing 8y ago
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.
- bluejekyll 8y ago
  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).
  - protomyth 8y ago
    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 https://en.wikipedia.org/wiki/Enterprise_Objects_Framework
xenihn 8y ago
I believe a lot of their backend stuff is in Java.
tylerchr 8y ago
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 https://www.foundationdb.org/files/record-layer-paper.pdf
- rdtsc 8y ago
  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.
karmakaze 8y ago
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 didn't expect this to be written in Java. Do they talk about this decision anywhere? I didn't catch anything in the announcement.

by sjroot 8y ago

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.

giancarlostoro 8y ago

They acquired the company that made FoundationDB: https://techcrunch.com/2015/03/24/apple-acquires-durable-database-company-foundationdb/ https://techcrunch.com/2015/03/24/apple-acquires-durable-dat...

sjroot 8y ago
This makes sense. Thank you for clarifying!
cmiller1 8y ago
Now this is the kind of Embrace, Extend, Extinguish I like. I wish more companies bought technologies just to open source them.
- manigandham 8y ago
  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.
  - jmull 8y ago
    > ...4 year gap... I don't think it was open in the first place, was it?
    - jbverschoor 8y ago
      It was iirc
      - ryanworl 8y ago
        FoundationDB was not open source before it was acquired by Apple. They had a free version you could download and use, though.
  - zepto 8y ago
    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.

ryanworl 8y ago

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

drb91 8y ago
Wow people really have no imagination when it comes to naming languages.
polskibus 8y ago
Could you please provide a link to Flow?
- ryanworl 8y ago
  https://github.com/apple/foundationdb/tree/master/flow https://github.com/apple/foundationdb/tree/master/flow
teacpde 8y ago
> 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.
- ryanworl 8y ago
  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.

neurobashing 8y ago

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.

bluejekyll 8y ago
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).
- protomyth 8y ago
  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 https://en.wikipedia.org/wiki/Enterprise_Objects_Framework

xenihn 8y ago

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

tylerchr 8y ago

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 https://www.foundationdb.org/files/record-layer-paper.pdf

rdtsc 8y ago
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.

karmakaze 8y ago

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.