Centralized face recognition where a single entity knows everybody a la Facebook would be a dystopian nightmare. Personalized face recognition where everyone has their own instance trained purely on the data they have access to (e.g. Apple's existing Photos face recognition) and only linking that face to the user's Contacts entry for the recognized person, that's not a privacy violation because that's just offloading information from my brain into my personal digital assistant.

Presumably the exact same thing they'd have done if they hadn't rolled out this Find My feature. They designed it so Apple can't tell where your device is, which means if anyone wants to demand this info from Apple, then Apple has to implement that tracking separately, which they could do regardless of the Find My feature's existence.

If Apple had access to the device data themselves, then that's a huge problem because governments can reasonably start issuing warrants for that info. The fact that Apple doesn't have it means nothing has changed on the governmental front.

2) We know one point of its derivative. This means we know 2 more points of the function (one step in either direction).

3) We know one point of its second derivative. This means we know 2 more points of the derivative, which in turn gives us 2 more points of the function.

etc.

Or at least, that's the impression I get from this thread, since I wasn't familiar with the series before that.

If the use of the abstraction forces your data model into a suboptimal representation, it's not zero-cost. If the compiler emits code that's worse than the straightforward manual implementation, it's not zero-cost. If the emitted code involves runtime checks that aren't necessary without the abstraction, it's not zero-cost.

For example, reference-counting is an abstraction over tracking the lifetime of your object. In some cases (where ownership isn't clear) the retain count introduced by reference counting is required and therefore not a cost, but in most cases the point at which the object ends up freed is actually predictable, and therefore the cost of all the reference counting is something that would have been avoided without the abstraction. Therefore, reference-counting as a replacement for manual alloc/free is generally not zero-cost.

Or how about iteration. Rust has an external iterator model (where you construct an iterator and run that, rather than passing a callback to the collection). In most languages an external iterator model is a non-zero cost, because you need to construct the iterator object and work with that, which is a bit of overhead compared to what the collection could do with an internal iterator model. In Rust, external iterators are frequently zero-cost because they usually get inlined. So you can write a high-level loop that includes a filter and map and the end result is very frequently just as good as (if not better than) what you'd have done if you wrote the iteration/filter/map by hand without Rust's iterator abstraction.

  // C safe subscript
  if (i < size) { return buf[i]; } else { abort(); }

  // Rust safe subscript
  return buf[i];

This part:

> But that's like saying if you don't use rust you don't pay for it. Just because there is the unsafe escape hatch in the language, you don't get to label the language as zero cost abstraction.

Rust isn't "zero-cost" because of the unsafe hatch; that's completely orthogonal. It's zero-cost because if you don't use a feature you don't pay for it. The fact that you need unsafe to get non-checked subscripting isn't particularly relevant to the fact that using non-checked subscripting in Rust means you're not paying for the existence of checked subscripting.

> Under your description an opt in generational GC is zero cost.

You're conflating implementation with semantics. If you have a choice between different allocation strategies that all result in the same observable runtime behavior, using a garbage collector over manual alloc/free is a cost. With manual alloc/free there's no runtime tracking to determine when an object should be freed, it's entirely static. Using a GC dramatically simplifies this from the developer's perspective and avoids a whole class of bugs, but comes with a runtime cost. Meanwhile for single-owner models, Rust's Box type has no runtime overhead compared to alloc/free, since there's no runtime tracking, the alloc and free points are determined statically by the compiler.

What... how... I don't even know where to begin with this.

I would assume the airdrop ensures the GitHub/HN proofs are up-to-date before sending the lumens.

If this surprise gift was for "each active Keybase user", how do they define "active Keybase user"?

Edit: Also, the desktop app didn't show anything about joining the monthly airdrop. I had to fire up the mobile app to see it.

Edit 2: After fully quitting the desktop app (including status item) and relaunching, the Wallet section finally shows an "Airdrop" entry. I shouldn't have to fully quit out of Keybase for this to work though.