bigdubs

Straight into landlord's pockets.

Adding to this, a solution might be enabling continuous releases and leaning into release channels could help in terms of getting more out to users.

In practice it's a challenge because the OS bundles a lot of separate things into releases, namely Safari changes are tied to OS changes which are tied to Apple Pay features which are tied to so on and so on.

It would require a lot of feature flagging and extra complexity which may reduce complexity.

Another way is to start un-bundling releases and fundamentally re-thinking how the dependency graph is structured.

IMHO SD cards fail much more often than the USB-C connector would, what's the worry? If the camera mounts as a mass storage device it's one fewer thing to go wrong.

People assuming this is a competitive posture exclusively are missing the point.

The app store isn't just about making more money, it's about enforcing privacy and security guidelines for apps through the review process and through checks for unauthorized api usage.

Apple's product is privacy; they view privacy as a premium feature worth paying for, and 3rd party app stores that are the wild west for privacy are antithetical to this.

Many ring-buffer implementations grow the backing storage array transparently on enqueue but do so in place, discarding the old arrays; what's the advantage of keeping the previous arrays? Naively I'd say it would reduce GC churn because you wouldn't have to free the old arrays, but I'm curious what the impact of that is in benchmarks.

Separately; the simulator is cool and very helpful!

Quantity may have a quality all its own in warfare but for comments having the invite tree and accountability is pretty nice!

I'd rather have (2) really insightful comments than 300 trying to promote themselves.

Shockingly fast and nice and having the intermediate files be immutable is super nice.

We query them directly in most cases with the httpfs plugin, but for hot paths we fetch them and cache them on disk locally.

What one engineer can operate confidently doesn't necessarily extend to the rest of the team, who will have to support that system if that engineer leaves or has to work on other projects.

The lowest common denominator on a team is boring.

Yes Node.js ships with what is effectively a very thin standard library for some low level things like interacting with the file system, the process model, some security features like TLS.

There is a deeper strategy here with go vs. node; having a standard library maintained by professionals.

I would rather build on a common set of libraries secured by people who are paid full-time to maintain them, and maybe have slightly worse ergonomics, than have a community of libraries that come and go and have inconsistent quality.

This standard library approach yields fewer dependencies, fewer changes over time, and better consistency between projects.

CockroachDB targets a different workload, namely, lots of reads and writes of individual records, versus returning large chunks of even larger tables.

So it might help with inserts but would struggle with larger queries.