uvdn7
|
4 years ago
|
on: Snowflake’s response to Databricks’ TPC-DS post
I genuinely think DeWitt clause is good for the users (bad for researchers). Without it, especially in the context of cooperate competitions, the company with the most marketing power will win. Users can always compare different products themselves. I am likely wrong but please help me understand.
uvdn7
|
4 years ago
|
on: Snowflake’s response to Databricks’ TPC-DS post
I disagree. It makes sense for Snowflake to response to what-they-think-is an unreasonably bad result published by Databricks. And they focused more on Snowflake’s result and only compared dollar cost against Databricks. It’s consistent with their philosophy that public benchmark war is beside the point and mostly a distraction.
uvdn7
|
4 years ago
|
on: Snowflake’s response to Databricks’ TPC-DS post
Exactly. That’s why I think public benchmark war is just a waste of time. There will ALWAYS be some subtle differences between the two platforms that results will never be apple to apple.
uvdn7
|
4 years ago
|
on: Snowflake’s response to Databricks’ TPC-DS post
Snowflake claims the snowflake result from Databricks was not audited. It’s not that Databricks numbers were artificially good but rather Snowflake’s number was unreasonably bad.
uvdn7
|
4 years ago
|
on: Snowflake’s response to Databricks’ TPC-DS post
I don’t think they are saying benchmark is not important but rather public benchmark war being a distraction.
uvdn7
|
4 years ago
|
on: Snowflake’s response to Databricks’ TPC-DS post
It’s probably just me but the distinction between datalake and data warehouse seems like splitting hairs. Unstructured data can always be stored on structure databases. What’s the main reason for both to coexist?
uvdn7
|
4 years ago
|
on: Snowflake’s response to Databricks’ TPC-DS post
Whose result can be trusted is beside the point - I actually believe both experiments were likely conducted in good faith but with incomplete context. But that’s beside the point. The point is there’s no good reason to start a benchmark war to begin with.
aptxkid
|
4 years ago
|
on: Snowflake’s response to Databricks’ TPC-DS post
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.
aptxkid
|
4 years ago
|
on: Show HN: My wife is pregnant; naturally I made a baby-name app to prepare
People have different skill sets. I bet there are engineers out there feeling more comfortable building a mobile app than a webapp.
aptxkid
|
4 years ago
|
on: Another reason why C++'s horrifying – initialization
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/
aptxkid
|
4 years ago
|
on: Flexport CEO on how to fix the US supply chain crisis
I agree that positive vs. negative is beside the point. But deadlock and positive feedback loop are different things though.
aptxkid
|
4 years ago
|
on: Flexport CEO on how to fix the US supply chain crisis
It sounds more like deadlock than a positive feedback loop (also it’s weird that he calls it negative feedback loop).
aptxkid
|
4 years ago
|
on: Vscode.dev
Proud to be a Bostonian!
aptxkid
|
4 years ago
|
on: FoundationDB: A distributed unbundled transactional key value store
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.
aptxkid
|
4 years ago
|
on: Ask HN: Why are relational DBs are the standard instead of graph-based DBs?
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.).
aptxkid
|
4 years ago
|
on: Ask HN: Why are relational DBs are the standard instead of graph-based DBs?
How a graph DB index the data to support this query?
aptxkid
|
4 years ago
|
on: Ask HN: Why are relational DBs are the standard instead of graph-based DBs?
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.
aptxkid
|
4 years ago
|
on: You Are Overpaying Jeff Bezos for Your Databases
Marketing pitch doesn’t have to make sense to be successful. Andy is a marketing genius.
aptxkid
|
4 years ago
|
on: Ohio sues Google, seeks to declare the internet company a public utility
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.
aptxkid
|
4 years ago
|
on: Why C++ Is Terrifying
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.
