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.

Well if this is an improvement or not depends on the use case. E.g. std::function does exactly this.

What it achieves is exactly erasing the type (conforming to an affordance). The cost is definitely there. You pay vtable lookup when using std::function.

However the Type Erasure described here doesn't need to know T even when you use it. E.g. it enables things like

for (auto x : vec) { x.foo(); }

I don't think this is true. Continuous transition can't be modeled as a state machine as far as I know.

The hard thing to do, which Bezos does very well, is to stay focused, patient and stay invested. Now it’s even easier to be even more patient as amazon has a very deep pocket.

To me, using vim is more about forcing me to understand how things work, or rely less on some IDE magic. IDEs are powerful. It’s too powerful that I don’t know how certain functionalities work. Maybe it’s just me lol.

Thanks! That makes much more sense!

If you read it closely, this is very similar to RAMP transaction. Both has pretty significant write amplification for storing transaction metadata and multiple versions of each key. By storing txn metadata and multiple versions, it provides many nice attributes like non-blocking, concurrent transactions, etc.

The difference between Abadi's proposal and RAMP is that it moves the "second phase" to the worker, which performs the remote read, to figure out the txn decision.

I think this proposal should be better compared to RAMP instead of 2pc. And even in RAMP paper, it states that this doesn't solve all the problems. E.g. how would you do the traditional read-modify-writes?

Adding abstraction over MySQL is not novel. Facebook did it many years ago https://www.usenix.org/system/files/conference/atc13/atc13-b...

Congrats, Ted!

BTW, Box is HIPPA compliant