HN user

havermeyer

184 karma
Posts5
Comments39
View on HN
Hyrum's Law 2 years ago

I reviewed a CL from Hyrum at Google where he was trying to remove a `set_timeout(float)` method in favor of `set_timeout(absl::Duration)` and changed the former to delegate to the latter. It turned out that there was some special handling of inf/nan in the legacy API, despite no mention in the documentation, and his CL broke a number of tests. It was amusing to experience Hyrum's law so directly :)

Sorry, I didn't check comments for a while. The target date funds tend to have higher management fees and yes, worse composition of stocks versus bonds compared to holding a mix yourself, IMO, based on your goals.

The C API for Julia also has almost no documentation. There is a getting started guide, which is great, but if you want to do anything more advanced (e.g. creating structs like in your example), you'll end up reading the source code to try to puzzle through which functions to use in julia.h. There's also an apparent limitation that whichever thread initializes Julia is the only one that can later eval code, which was surprising. The language itself is very cool, but it has a long way to go to be easy to embed like Python is.

Gordon is amazing, and it's almost impossible to beat him to an answer for certain types of questions :) I had the chance to meet him a few years back to talk through some new SQL features coming to BigQuery (I'm at Snowflake now). He had a lot of great insights into what could make the product better, and what he thought was missing relative to other OLAP databases.

I hadn't heard about this mantra before:

Management's reasoning fell in line with CEO Mark Zuckerberg's early mantra, "company over country," according to the book.

"As a private global company, Facebook did not want to engage in geopolitical skirmishes, and it certainly didn't want to be in the middle of contentious national elections," the authors write. "Facebook was, above all, a business."

I saw a lot of this when I worked at Google, both with internal-facing products and external-facing ones (software, though, not hardware). Organization A would build their own query engine, for example, but then organization B would build their own competing one because A's solution didn't quite work in the ways that they wanted it to. The result, of course, was that now you have a proliferation of query engines, and if you're a neutral party, you just end up being confused about which to pick since they all have tradeoffs, and none of them have sufficient headcount to build out more complete functionality. In terms of external products, there's a long line of competing chat, video calling, payment, etc. solutions, most of which have been killed off by now.

My takeaway was that I wish leadership had thought more critically about how to invest resources across organizations to build fewer but more adaptable products, but I don't think the right incentives existed :/

I'm curious about the options that they'll offer initially. With the Model 3, Tesla only sold the long-range, premium version at first, which IIRC is more profitable than the basic $35k version. Maybe they'll repeat this with the Y and sell just a more expensive model first as well.

This sounds like a terrible idea. You can provide a way for people to opt out of legacy behavior, but don't break them outright unless you want to lose your most faithful, long-term users.

I'm biased (I work on the BigQuery team) but I'm always excited to see more public datasets made available in BigQuery: https://cloud.google.com/bigquery/public-data/. It would be great to have government data available through a variety of cloud services with free exports.

Some personal favorites among BigQuery public datasets include NOAA GHCN[0], the Census Bureau's Zip Code Tabulation Area [1], and FEC Campaign Finance [2].

[0] https://console.cloud.google.com/marketplace/details/noaa-pu... [1] https://console.cloud.google.com/marketplace/details/bigquer... [2] https://console.cloud.google.com/marketplace/details/bigquer...