Also, banks are really different from domain registrars in several important and relevant respects, but, for the record, I don't have to tell it to the banks I use, and if I did, I'd probably be looking for a bank that I don't have to tell it to.

More seriously, though, thinking about this pretty silly (in my view) question makes me want to talk to some Rabbis to clarify some things. AFAIK, the existence of free will is pretty fundamental to Judaism (unlike Islam or branches of Protestantism), and having pretty materialistic views on the question of free will myself (i.e. it doesn't exist, obviously), I struggle to imagine how the alternative views can survive contemplating if you can let your AI-agent run on Saturdays. I mean, I think I understand how, say, Orthodox Christians can keep these views today, but they don't really have such meticulous legal system built upon purely theological discussions. So, as an Orthodox Christian, even if you fully understand the implications (which, of course, most people don't, but that's besides the point) it isn't really a problem to consciously accept whatever beliefs about free will while still being very materialistic about most practical questions. But since my knowledge of Jewish theology is extremely limited, I have no idea if you even have to have some specific views about determinism for halakha to be self-consistent.

And ironically, I think that this one is kinda fair. I mean, you specifically asked your software to generate whatever pseudo-random bytes it wishes to loosely based on some text prompt. It did that. Now, apparently, these pseudo-random bytes turn out to be personally identifiable. So what? I suppose they didn't claim their PRNG to be cryptography-grade. They could even make it seem like an accident, should they be bothered to. Make it way less obvious.

Now if it would insert watermarks on save (like printers do), that would be really outrageous. But when you trust software to produce "whatever", you probably shouldn't be really mad about it doing anything more than you asked to.

Anyway, I wouldn't say it currently behaves nicely (like something I would like to reuse anywhere whatsoever). Tested on Firefox opening Bookmarks on the left. First off, there is this ugly flicker, as browser first renders the "wrong" version, then your JS "fixes" it. Second, there is some concurrency problem, as by opening and closing Bookmarks repeatedly I somehow managed to render both versions: centered to viewport and covered by sidebar.

And, yeah, as others have said, I also think that allowing sidebar to cover your webpage content is absolutely bogus and don't foresee myself wanting this behavior, ever. But that's up to you.

It starts with the premise of "C/C++ have pretty fucked up type systems, and look how much nicer integer type names are in Rust" and also that we should use unsigned integers as the first approximation if we are trying to model ℕ. Was I supposed to disagree with that? It didn't seem like the author was arguing against them, and they seem like pretty trivial, obviously true statements.

Then it starts to talk about how we cannot properly use unsigned in C/C++, because it's fucked up, and it cannot be fixed properly because the proper handling of integers is too expensive. This all sounds sadly familiar and we are nodding and saying: "Well, such is life." But at least we still have Rust, that doesn't suffer from the same inherent UB curse, right? I mean, I'm not deep enough into the details of current compiler implementation, but I've got the impression that the described problems don't apply to Rust. All good then? (edit: obviously, except for the fact that we still allow wrapping in prod builds, because it's expensive not to. But we all knew this already.)

Then it follows up with some pretty contrived (IMO) example of how we cannot mindlessly swap int with uint (obviously? I mean, you basically explicitly check for `i == -1` in this example), framing is as "uint is unintuitve". Was it supposed to be a strawman? It surely is a strawman, but the author doesn't argue against it.

And then a couple more of statements to the support of Stroustrup's "just use signed" (in C/C++), which also don't seem to apply to (saner) Rusts choices.

And then it ends w/o a conclusion. So, what was the conclusion supposed to be, please? I really don't understand what the author tried to convey.