bigdubs
bigdubs on Hacker News
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.
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.
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.
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.
This is not a good comparison because big mining farms are not equivalent to people playing video games at home.
Not every project is large, there are plenty of things that don't need the burdens that larger projects place on the code to just get things done and get them done well.
Rust definitely has advantages for safety and correctness.
Those advantages come at a cost, specifically in terseness and readability, which are both _strengths_ of Python. As a result, they're very different tools, and comparing them shows that the author doesn't grasp their relative strengths and how those apply to their typical use cases.
Big point of strength for TSMC in negotiations is they're the only fab that can make 3nm chips in volume, which gives them a ton of leverage to push back against Apple.
You're obviously allowed to feel what you feel but if you've ever seen a "good" body of work taken on the street, and a "bad" body of work taken on the street, the skill of the photographer matters, and it expresses art.
The low vs. high debate is old as time, with sculptors looking down on painters, with painters looking down on photographers.
The camera is a canvas and the photographer paints with what they put in front of the lens and when they close the shutter. Street photography takes it an extra step further and removes a ton of control over what you're photographing and leaves you creating art out of what is happening before you.
Then it's going to be weaponized to launder money and be made illegal eventually.
a couple high profile projects (k8s) needed generics, there are limited use cases outlined in the planning docs that detail the holes in the language they're filling, it wasn't just squeaky wheels.
It follows because you may be taking off from private land but you're operating in federal airspace (all airspace is federal in the US)
Keyboard wpm is about double; ~37-44wpm is P50. Still not super fast though.
A lot of that has to do with coatings modern lenses use to correct for chromatic aberration, but also how they minimize loss of contrast from light bouncing around inside the lens.
It really is incredible how much a lens affects the final image.