Hacker News new | past | comments | ask | show | jobs | submit login

The Flow language they implemented for this is interesting. http://www.foundationdb.com/white-papers/flow/

I think we are going to see eventual consistency deflate as people relearn to love transactions. SQL also makes users of a database a lot more productive. The bottom line is you don't want your devs spending time and effort reasoning about database behavior, you want them focusing on business logic. In 5 years hopefully the world will catch up a bit with Google's Megastore and Spanner.




FoundationDB founder here. Flow sounds crazy. What hubris to think that you need a new programming language for your project? Three years later: Best decision we ever made.

We knew this was going to be a long project so we invested heavily in tools at the beginning. The first two weeks of FoundationDB were building this new programming language to give us the speed of C++ with high level tools for actor-model concurrency. But, the real magic is how Flow enables us to use our real code to do deterministic simulations of a cluster in a single thread. We have a white paper upcoming on this.

We've had quite a bit of interest in Flow over the years and I've given several talks on it at meetups/conferences. We've always thought about open-sourcing it... It's not as elegant as some other actor-model languages like Scala or Erlang (see: C++) but it's nice and fast at run-time and really helps productivity vs. writing callbacks, etc.

(Fun fact: We've only ever found two bugs in Flow. After the first, we decided that we never wanted a bug again in our programming language. So, we built a program in Python that generates random Flow code and independently-executes it to validate Flow's behavior. This fuzz tester found one more bug, and we've never found another.)


"FoundationDB founder here. Flow sounds crazy. What hubris to think that you need a new programming language for your project? Three years later: Best decision we ever made."

I don't think that should come as a surprise to anyone. In the long run, language-oriented approach seems to be the best approach to handling the intricacies of complex software systems. The only thing stopping it seems to be a certain lack of skills and experience on part of most developers, and the inadequacy of current language-building tools. (By any chance, are you familiar with the "let's simplify language construction"-related work of people at vpri.org?)


How does the Python program know what the random Flow code is supposed to do?


Hmm, that's the tricky bit to explain in a quick post. It has an independent code interpreter that works on the internal representation of the fuzzed code. The output of that internal representation in fed through the Flow compiler (then C++). There is basically a "check([random number])" statement on every other line of code which should be reached in a known order. We compare the check log of the fuzz tester's interpreter to the check log of the compiled code.


I guess that the Python program generates some sort of internal AST that is either trivial or at least easier to interpret than the fuzz code (enhanced C++, blah...) generated from the AST.


I read the performance analysis comparing it to Go, Erlang etc. Has any comparison been made with Akka (http://akka.io)? How much would this extra efficiency matter when the communicating processes are on different machines? Since speed in communicating between local processes is important to you guys, I am assuming that the actor model is then used for all local and remote communication?


"4GB RAM" in hardware requirements.. Why? It's not Java, it's C++, so why??? 4GB just to store definition of empty storage?

Is Debian 6 supported?


At first I thought you were talking about http://www.flowlang.net/p/introduction.html, a different Flow language designed around data flow to allow automatic parallelization.


Reminds me a bit of OkCupid's Tamer : https://github.com/maxtaco/tamer

Though I believe they go less all out on the actor model, but just focus on concurrent processing, essentially using futures.




Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: