Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple Open-Sources FoundationDB Record Layer

github.com

Post reply on HN
Print view View original

31–36 of 36 posts

Re: Apple Open-Sources FoundationDB Record Layer

#31

Post by neurobashing »

zepto wrote: post #23
SquareWheel wrote: post #17

I'm surprised to see Apple using Github; particularly now that Microsoft owns it. It is where the developers are though. And it certainly beats a hidden download on opensource.apple.com.

I’d say Microsoft owning it makes it more attractive rather than less. Less risk of it being acquired by some unknown company in the future or collapsing through mismanagement.

I'd go one step further and say that to Apple, Microsoft is "the devil you know". Apple uses Azure for some of its services, for example.

Re: Apple Open-Sources FoundationDB Record Layer

#33

Post by ryanworl »

teacpde wrote: post #27
ryanworl wrote: post #7

Earlier quoted context omitted.

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 th…

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

Re: Apple Open-Sources FoundationDB Record Layer

#35

Post by rdtsc »

tylerchr wrote: post #29
sjroot wrote: post #4

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.

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 bespok…

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.

Re: Apple Open-Sources FoundationDB Record Layer

#36

Post by karmakaze »

sjroot wrote: post #4

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.

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.
Post reply on HN