aptxkid

Personally I think it’s a great response and very well written. I didn’t jump on the congrats-Databricks wagon when the result first came out because of the weird front page comparison against snowflake. Both companies are doing great work. Focusing on building a better product for your customer is much more meaningful than making your competitor look bad.

People have different skill sets. I bet there are engineers out there feeling more comfortable building a mobile app than a webapp.

To understand how they are different, you need to know Default Initialization, Direct List Initialization, Aggregate Initialization, Default Member Initialization, List Initialization, Value Initialization, Zero Initialization. https://blog.the-pans.com/cpp-initialization/

I agree that positive vs. negative is beside the point. But deadlock and positive feedback loop are different things though.

It sounds more like deadlock than a positive feedback loop (also it’s weird that he calls it negative feedback loop).

Proud to be a Bostonian!

I wrote a post explaining FDB as well, which got retweeted by @FoundationDB https://mobile.twitter.com/aptxk1d/status/141786976657708237...

My post focuses on the correctness, proof of the correctness of FDB’s failure recovery, some of which is missing even from the paper itself.

Some of the paper authors reached out; and I corrected one issue on my blog post pointed out by one of the authors.

It does, which one can argue it’s an implementation detail. The differences I mentioned above eg sharding, transaction boundary, secondary indices, etc. should be generally applicable to a non-relational db and not unique to TAO. I could be wrong though; as I know little about other graph dbs.

It would probably be more productive to compare RDB and Graph with certain workload examples (OLTP, OLAP, joins, scans, etc.).

How a graph DB index the data to support this query?

This is a great topic. I have been working on TAO for many years. I am not very familiar with other graph databases; I assume fundamentally they are more or less the same. Here are some differences between RDB and a graph db IMHO, 1. sharding and transaction boundary 2. Secondary index support 3. How “join” works (eg. give me a list of my friends who follows Justin Bieber)

You’re right that graph db is very easy to use a lot of the times.

Marketing pitch doesn’t have to make sense to be successful. Andy is a marketing genius.

Internet is a utility. Google/Facebook is not. It’s like water is utility but having ice delivered to you is a service not a utility.

The tweet is certainly loaded, hence the point of this HN post lol.

First of all there's std::function, which uses Type Erasure https://blog.the-pans.com/type-erasure/. It means std::function<void(int)> can be the type of anything callable that takes an int and returns void (lambda, function pointer, object with operator() overload, etc.). Notice they are of different types! Hence Type Erasure.

How std::function manages its memory is poorly specified. But the standard at least states that if it's initialized from a function pointer (free, no capture), it's guaranteed that it won't allocate. https://en.cppreference.com/w/cpp/utility/functional/functio...

> When the target is a function pointer or a std::reference_wrapper, small object optimization is guaranteed, that is, these targets are always directly stored inside the std::function object, no dynamic allocation takes place.

In this case, std::function is trivially copyable. However, there's no way to know this at compile time, exactly because the type is erased in std::function.

The answer is yes. And you can verify this by

checking std::is_trivially_copyable<FnPtrType>::value

using FnPtrType = int (*)(int) // for example

folly::Function was added for exactly this reason I think https://github.com/facebook/folly/blob/master/folly/docs/Fun...

LOL sure. I think it's arguably terrible behind the curtain. But the interface provided is pretty elegant IMO.