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!
We use DuckDB extensively where I work (https://watershed.com), the primary way we're using it is to query Parquet formatted files stored in GCS, and we have some machinery to make that doable on demand for reporting and analysis "online" queries.
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.
I would maybe consider it the other way; these companies are wildly profitable with huge margins, why don't the employees capture _more_ of the value they create?
So far in the betas the generics support has been really great, some issues with inferring the types of functions but otherwise going to be a welcome addition to the language.