I agree that zero-initializing doesn't really help avoid incorrect values (which is what the author focuses on) but at least you don't have UB. This is the main selling point IMO.
I "often enough" drive around with my car without crashing. But for the rare case that I might, I'm wearing a seatbelt and have an airbag. Instead of saying "well I better be careful" or running a static analyzer on my trip planning that guarantees I won't crash. We do that when lives are on the line, why not apply those lessons to other areas where people have been making the same mistakes for decades?
It is impossible to post about a language on this forum before the pearl clutching starts if the compiler is a bit lenient instead of triple checking every single expression and making your sign a release of liability.
Sometimes, ergonomics and ease-of-programming win over extreme safety. You’ll find that billion dollar businesses have been built on zero-as-default (like in Go) and often people reaching for it or Go are just writing small personal apps, not cruise missile navigation system.
It gets really tiring.
/rant
Or are you saying that a certain level of bugs is fine and we are at that level? Are you fine with the quality of all the software out there? Then yes, this discussion is probably not for you.
This is the kind of generalisation I'm ranting against.
It is not constructive to extrapolate any kind of discussion about a single, perhaps niche, programming languages with applicable advice for "all the software out there". But you probably knew that already.
There is a lot of subpar software out there, and the rest is largely decent-but-not-great. If it's security I want, that's commonly lacking, and hugely so. If it's performance I want, that's commonly lacking[0]. If it's documentation...you get the idea. We should have rigor by default, and if that means software is produced slower, I frankly don't see the problem with that. (Although commercial viability has gone out the window unless big players comply.) Exceptions will be carved out depending on the scope of the program. It's much harder to add in rigor post hoc. The end goal is quality.
The other issue is that a program's scope is indeed broader than controlling lives, and yet there are many bad outcomes. If I just get my passwords stolen or my computer crashes daily or my messaging app takes a bit too long to load every time, what is the harm? Of course those are wildly different outcomes, but I think at least the first and second are obviously quality issues, and I think the third is also important. Why is the third important? When software is such an integral part of users' lives, minor issues cause faults that prompt workarounds or inefficiencies. [1] discusses a similar line of thought. I know I personally avoid doing some actions commonly (e.g. check LinkedIn) because they involve pain points around waiting for my browser to load and whatnot, nothing major but something that's always present. Software ("automation") in theory makes all things that the user implicitly desires to be non-pain points for the user. An interesting blend of issues is system dialog password prompts, which users will generally try to either avoid or address on autopilot, which tends to reduce security. Or take system update restarts, which induce not updating frequently. Or take what is perhaps my favorite invectives: blaming Electron apps. One Electron app can be inconvenient. Multiple Electron apps can be absurd. I feel like I shouldn't have to justify calling out Electron on HN, but I do, but I won't here. And take unintended uses: if I need to set down an injured person across two chairs, I sure hope a chair doesn't break or something. Sure, that's not the intended use case of a chair, but I don't think it's unreasonable that a well-made chair would not fail to live up to my expectations. I wouldn't put an elephant on the chair either way, because intuitively I don't expect that much. Even then, users may expect more out of software than is reasonable, but that should be remedied and not overlooked.
Do not mistake having users for having a quality product.
[0] https://news.ycombinator.com/item?id=43971464 [1] https://blog.regehr.org/archives/861
And you seem to have ignored a lot of what I said, as if I was just talking about a few rare, critical problems.
[0] https://old.reddit.com/r/unpopularopinion/comments/d6g6qr/it...
Depends.
> Are ads fine if they can be used to track every detail of what you do and want?
Depends.
> Was it fine when CrowdStrike caused Windows systems in airports BSOD and lead to massive delays?
Depends.
That's my whole point. You're presuming some absolutes which aren't universally necessitated or desired.
"It is difficult to get a man to understand something, when his salary depends on his not understanding it."
- Upton Sinclair
and note (because it is not included in the quote) that a literal salary is not necessary or sufficient. Really? Is this not just resigning to subpar software? My counterpoint is that what is popular is not necessarily what should be popular. And I think you're still tunnel-visioning for a specific thing to criticize. Do I have to keep giving examples until I find one you will deign to agree is a serious issue? Just as hasty generalization is harmful, so is hasty specialization. Perhaps you personally don't see a problem, but there can be many reasons for that.
It's getting from point A to point B with whatever works best given the circumstances after considering all the pros and cons. Sometimes that is garbage software. I mean I've even used _____ once or twice! [edit] redacted to not throw any software under the bus
I agree with you on this, but on this forum that's full of people who write software, I'm skeptical that making better software isn't often (usually?) the better choice. But I understand that this is one of those "critical mass" things where a few people can't do nearly as much.
If you have a sparse array of values (it might be structs), then you can use a zero value to mark an entry that isn’t currently in use, without the overhead of having to (re-)initialize the whole array up-front. In particular if it’s only one byte per array element that would need to be initialized as a marker, but the compiler would force you to initialize the complete array elements.
Similarly, there are often cases where a significant part of a struct typically remains set to its default values. If those are zero, which is commonly the case (or commonly can be made the case), then you can save a significant amount of extra write operations.
Furthermore, it also allows flexibility with algorithms that lazy-initialize the memory. An algorithm may be guaranteed to always end up initializing all of its memory, but the compiler would have no chance to determine this statically. So you’d have to perform a dummy initialization up-front just to silence the compiler.
To many people reading this this may be a "duh" but I find it is worth pointing out, because there are still some programmers who believe that C is somehow the "default" or "real" language of a computer and that everything about C is true of other languages, but that is not the case. Undefined behavior in C is undefined in C, specifically. Try to avoid taking ideas about UB out of C, and to the extent that they are related (which slowly but surely decreases over time), C++. It's the language, not the hardware that is defining UB.
C is just one language of many and you do not have to define the rules of a new language to it.
Let me explain. Conceptually, a pointer is an optional reference. Either it's nil or it references some object. (That reference may be valid or not, but that's a separate topic.) Optionals have been well understood in the programming language community for a long time. Many modern languages get them right, usually with some form of what Haskell calls the Maybe monad. May sound intimidating, but the gist is that in order to unwrap the thing inside, you pattern match on its structure. It's either Nothing or it's a value. You can't even syntactically talk about the wrapped thing outside this pattern matching. With such a construction, "dereferencing nil" is not a thing. You either have a pointer (optional reference) which needs the unwrapping, or you already did unwrap, then you have a non-null-pointer (non-optional reference). So, a language can easily encode all this in its type system without runtime overhead.
When inventing a new language that fixes flaws of C, why not fix this one as well?