Live data from Hacker News

Apple Open-Sources FoundationDB Record Layer

github.com

21–30 of 36 posts

Re: Apple Open-Sources FoundationDB Record Layer

#21

Earlier quoted context omitted.

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.

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.

Re: Apple Open-Sources FoundationDB Record Layer

#22

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.

The opensource.apple.com site is really more for software that they snapshot and release (open source, not open process). They've had other projects for a long time developed in the open, and used to run https://www.macosforge.org to host them.

Some of those were acquired (either as a core developer in the case of CUPS, a codebase in the case of WebKit) but I'm not sure of other examples of open sourcing an acquired technology like this.

Re: Apple Open-Sources FoundationDB Record Layer

#23

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.

Re: Apple Open-Sources FoundationDB Record Layer

#24

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.

This is not exactly a new thing: https://github.com/apple/swift

There's also: https://github.com/apple/foundationdb

Re: Apple Open-Sources FoundationDB Record Layer

#25
post #7
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.

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…

Could you please provide a link to Flow?

Re: Apple Open-Sources FoundationDB Record Layer

#26
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…

Could you please provide a link to Flow?

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

Re: Apple Open-Sources FoundationDB Record Layer

#27
post #7
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.

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.

Re: Apple Open-Sources FoundationDB Record Layer

#28
post #20

Earlier quoted context omitted.

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

Re: Apple Open-Sources FoundationDB Record Layer

#29
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 bespoke wire protocol and revert to the client-server approach. Am I missing something?

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

Re: Apple Open-Sources FoundationDB Record Layer

#30
post #20

Earlier quoted context omitted.

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