> Though some have questioned why anyone intending to blow up a plane would broadcast the word bomb, many terrorist acts have relied on the threat of a bomb as leverage during attempted hijackings or hostage situations.

There are also cases where I think I know the answer, and I ask the AI, and it produces a more complete answer than I would but I know enough to assess it. It seems like a waste of time to paraphrase the whole thing. That's the "Here's how Claude phrased it and I can attest that it's right" case.

[1] https://news.ycombinator.com/item?id=48243331

https://www.anthropic.com/research/project-vend-1 https://www.wsj.com/tech/ai/anthropic-claude-ai-vending-mach...

(Two different examples of a similar idea)

There are certainly _bad_ abstractions that ought not to exist, which I think is what you're getting at. There are poorly built abstractions, and leaky abstractions. But abstraction itself isn't the problem -- abstraction is what allows us to build anything at all without being crushed by the sheer complexity.

How does the Rust language team weigh the benefits of solving user problems with new language features against the resulting increased complexity? When I learned Rust, I found it to be quite complex, but I also got real value from most of the complexity. But it keeps growing and I'm not always sure people working on the language consider the real cost to new and existing users when the set of "things you have to know to be competent in the language" grows.

It's so easy to forget about the problems we don't have because of the (good) choices people have made in the past.

Comments URL: https://news.ycombinator.com/item?id=47377218

Points: 1

# Comments: 0

The phrase “it turns out” has a surprising way of disarming skepticism in readers. While surprising, it’s easy to understand: the phrase suggests a story of the author’s journey of believing one thing, investigating, and finding something different. That’s more credible than simply saying the thing they now believe. The touch of vulnerability (admitting being wrong) avoids the reader’s ego getting defensive when asked to admit they were wrong. The net result is that it’s surprisingly easy to be convinced without any real argument.

I’ve noticed this as well (often in podcasts and programs like Radiolab) and I think it’s quite valuable to just be aware of it as a reader/listener, if you care about thinking critically about your own beliefs.

Is this a trick question? Humanity survived by having enough people with enough other useful traits (like thinking, including the ability to reason about disease and how to prevent it) to overcome the numbers lost to disease. Humans died to disease in enormous numbers.

> nor that they're all good for _me_ as an individual.

Herd immunity presents a real challenge to idea that people should generally be allowed to make their own choices. One's choice here affects everyone else, in a minuscule way that nonetheless adds up to many thousands of lives saved. I'm not sure what the answer is for this, but generally I come down on the side of: if a democratic process creates rules requiring us all to be immunized for the common good, that's okay with me.

> It's the parents obligation to educate their child.

> It's the child's obligation to use that education wisely.

Two obvious things complicate this:

- You weren't taught how to use a real gun at 6 months old, right?

- Would it not follow from what you said above that if you had accidentally shot and killed yourself at age 7, then it would be your own fault and nobody else's? That seems (to me, at least) like an absurd conclusion.

I think about it like this: as a parent, my jobs include identifying when my child is capable of learning about something new, providing the guidance they need to learn it (which is probably not all up front, but involves some supervision, since it's usually an iterative process), allowing them to make mistakes, accepting some acceptable risks of injury, and preventing catastrophe. I'll use cooking as an example. My kids got a "toddler knife" very young (basically a wooden wedge that's not very sharp). We showed them how to cut up avocados (already split) and other soft things. As they get older, we give them sharper knives and trickier tasks. We watch to see if they're understanding what we've told them. We give more guidance as needed. It's okay if they nick themselves along the way. But we haven't given them a sharpened chef's knife yet! And if they'd taken that toddler knife and repeatedly tried to jam it into their sibling's eye despite "educating" them several times, while I wouldn't regret having made the choice to see if they were ready, I would certainly conclude that they weren't yet ready. That's on me, not them.

You allude to this when you say:

> I am very much for showing kids how to use the internet responsibly, but I'm not of the opinion that parental controls are particularly desirable beyond an initial learning period.

Yes, the goal should be to teach kids how to operate safely, not keep them from all the dangerous things. But I'd say that devices and the internet are more like "the kitchen". There are lots of different risks there and it's going to take many years to become competent (or even safe). Giving them an ordinary device would be like teaching my 2-year-old their first knife skills next to a hot stove in a restaurant kitchen with chefs flying around with sharp knives and hot pots. By contrast, without doing any particular child-proofing, our home kitchen is a much more controlled environment where I can decide which risks they're exposed to when. This allows me to supervise without watching every moment to see if they're about to stab themselves -- which also gives them the autonomy they need to really learn. The OP, like other parents, wants something similar from their device and the internet: to gradually expose elements of these things as the parents are able to usefully guide the children, all while avoiding catastrophe.

> Was that done in this thread?

Well, I raised a general problem around 24/7/365 use cases (rooted in my operational experience, reinforced by the more-current words that I was replying to and the OP) and you called it "tedious", "low-info griping". Yes, that seems pretty dismissive.

(Is it fair? Though I thought the podcast episodes were fairly specific, they probably glossed over details. They weren't intended to be about those issues per se. I did write a pretty detailed post though: https://www.davepacheco.net/blog/2024/challenges-deploying-p... (Note the prominent caveat at the top about the experience being dated.))

You also wrote:

> running an, at the time, outdated postgres, on an outdated OS

Yes, pointing to the fact that the software is old and the OS is unusual (it was never outdated; it was just not Linux) are common ways to quickly dismiss users' problems. If the problems had been fixed in newer versions, that'd be one thing. Many (if not all) of them hadn't been. But also: the reason we were running an old version was precisely that it was a 24/7/365 service and there was no way to update databases without downtime, especially replicated ones, nor a great way to mitigate risk (e.g., a mode for running the new software without updating the on-disk format so that you can go back if it's a disaster). This should be seen as a signal of the problem, not a reason to dismiss it (as I feel like you're doing here). As for the OS, I can only think of one major issue we hit that was OS-specific. (We did make a major misconfiguration related to the filesystem that certainly made many of our issues much worse.)

I get that it sucks to keep hearing about problems from years ago. All of this was on 9.2 - 9.6 -- certainly ancient today. When this comes up, I try to balance sharing my operational experience with the fact that it's dated by just explaining that it's dated. After all, all experience is dated. Readers can ignore it if they want, do some research, or folks in the PostgreSQL world can update me when specific things are no longer a problem. That's how I learned that the single-threaded WAL receiver had been updated, apparently in part because of our work: https://x.com/MengTangmu/status/1828665449850294518 (full thread: https://x.com/MengTangmu/status/1828665439234474350). I'll happily share these updates wherever I would otherwise share my gripes!

It's workload-specific, too. If you want to list ranges of them by PK, then of course random isn't going to work. But then you've got competing tensions: listing a range wants the things you list to be on the same shard, but focusing a workload on one shard undermines horizontal scale. So you've got to decide what you care about (or do something more elaborate).

What you describe is true and very important (more margin lets you weather more disruption), but it's not the whole story. The problem we had was queueing delays mainly due to I/O contention. The disks had the extra IOPS for the maintenance operation, but the resulting latency for all operations was higher. This meant overall throughput decreased when the maintenance was going on. The customer, finally accepting the problem, thought: "we'll just build enough extra shards to account for the degradation". But it just doesn't work like that. If the degradation is 30%, and you reduce the steady-state load on the database by 30%, that doesn't change the fact that when the maintenance is ongoing, even if the disks have the IOPS for the extra load, latency goes up. Throughput will still degrade. What they wanted was predictability but we just couldn't give that to them.

> To be fair, I find oxides' continual low-info griping against postgres a bit tedious. There's plenty weaknesses in postgres, but criticizing postgres based on 10+ year old experiences of running an, at the time, outdated postgres, on an outdated OS is just ... not useful?

First, although I work at Oxide, please don't think I speak for Oxide. None of this happened at Oxide. It informed some of the choices we made at Oxide and we've talked about that publicly. I try to remember to include the caveat that this information is very dated (and I made that edit immediately after my initial comment above).

I admit that some of this has been hard for me personally to let go. These issues dominated my professional life for three very stressful years. For most of that time (and several years earlier), the community members we reached out to were very dismissive, saying either these weren't problems, or they were known problems and we were wrong for not avoiding them, etc. And we certainly did make mistakes! But many of those problems were later acknowledged by the community. And many have been improved -- which is great! What remains is me feeling triggered when it feels like users' pain is being casually dismissed.

I'm sorry I let my crankiness slip into the comment above. I try to leave out the emotional baggage. Nonetheless, I do feel like it's a problem that, intentionally or otherwise, a lot of the user base has absorbed the idea that it's okay for necessary database maintenance to significantly degrade performance because folks will have some downtime in which to run it.*