S/MIME is a core email protocol, millions of people use it. Everyone subscriber to a secure email provider will use it by default, so 10s of million, without even looking up the number, as an easy group.

Professionals don't use Windows, frauds use Windows. People with special needs to use Windows. The computer user who thinks an “any key” exists, use Windows. Professionals don't, and would never use Windows, it's a train wreck. It's completely unstable, broken, glitched, bugged, and crashes so often that you have to be wasting upwards of 70% of time in the best conservative estimate. It's not even passable as an OS, it's a disgrace to the computing world, and I truly mean that. Almost everyone will use more Linux and Unix-based computers then Windows computers, you can't even use the Internet without touching Linux and Unix. Windows makes up, maybe, being exceptionally charitable, 10% of the computer landscape, it's likely much less, but I'm feeling kind.

Seriously, please explain a feature of Word or Excel that is so good you think it can make a good defensive case, I'm drawing a blank. The world does not use MS Office, China jumped ship, Europe is jumping ship, and in every single case the users are happier and get more done, with better tools. Take LibreOffice as a counter example, and just contrast them. What can't you do in LibreOffice that you can do in MS Office, that is a meaningful feature add? I'll even put the abusive, aggressive, and digitally molesting licensing terms aside for the comparison.

I'm not concerned about opinions from people who are so stupid and incompetent they should get an award for wiping their ass. I'm NOT grouping your into that, just to be clear, but the average computer user is a disgrace to computing, and so helpless and retarded they can't even function on their own. I had an IT call from a person on Wednesday who couldn't figure out how to login to Adobe something or other, and the kicker, the login window was OPEN. Likewise, I literally asked them to put their username and password into the dialogue, I swear I'm not joking about that. Furthermore, I had somebody a few weeks ago have a full-blown tantrum because Slack logged out, and demanded I file a bug report with Slack, the issue? Windows corrupted the session (like normal), which it seems to do with alarming regularity, across all manner of applications, even Office.

Depending on the language, that's important. If setting something to null is killing your performance, and resource budget, then you have other, more serious problems. The point of setting an object to null, is to flag it for the garbage collector, try it in JavaScript / TypeScript, you'll probably find the garbage collector is more effective. Of course, if you're using a language that lets you self-manage the memory, then manage it yourself, like in C, the gold standard.

Outlook isn't just slightly broken, it's a massive pile of broken garbage. It doesn't even support S/MIME extensions by default. Outlook is such a poor showing of a product, that if any company released it on its own, they'd be bankrupt quickly. Word, and Excel, both examples of terrible showings in their categories, and I don't think it's out of line to say the worst showing in their categories. Case in point, you can't install O365 on the vast majority of Unix or Linux-based systems, which means, Microsoft knows they are not suitable for any professional.

O365 online, is slow, buggy, glitchy, and crashes so often it's like you're back on early versions of Windows. Do they really want to use O365 as their defence for using Rust? Regardless about Rust, since it doesn't matter, why use some of the worst products the company has designed to make the point?

The problem isn't setting the pointer to 0, it's forgetting to free that pointer. If you wrote the value zero into it, you either did it accidentally, or, you meant to, which you'll find on review. I would add a comment above where you set the pointer to zero, explaining why it's being to set to zero. It wouldn't recommend randomly overwriting variables and pointers, unless you're doing something obvious with line of sight. A good rule of thumb is 50% of your code base should be comment, for that reason.

Do I set things to null for garbage collectors? Usually, depending on the language, when I'm done with them, since it marks the memory as truly free, and generally results in better garbage collection. In TypeScript / JavaScript it's generally a good policy to intentionally mark your structures as free, when you're done with them.

Seatbelts are a safety device, but they don't guarantee you can't get injured in a car accident. The issue is: Rust developers treat the seatbelt as accident prevention when it's not. Unsafe is the same as not putting the seatbelt on, but then claiming it's the same as being accident safe anyway, since someone else is wearing a seatbelt. If you doubt they think that, look up Lunduke, and read or watch his Rust coverage, they absolutely believe that Rust is some kind of magical language that makes the concept of bugs impossible.

I'll even settle this pointless argument if instead of memory safety, we just call it's reasonable memory assurance, which is more accurate.

If I was designing that reason input, you would have to add the reason, the time of relevant, and attach a picture of yourself. Once you do that, you'd have to get at least two other independent officers sign off, with one being your superior, who becomes liable if missed used. Once all of that is done, and confirmed, then you could run your search.

It wouldn't prevent abuse, but it would slow it down, and provide a chain of verification, so a single officer alone couldn't violation peoples freedom.

Everyone knows AI can make stuff up, my grandmothers, one is 86, the other is 94, both know that AI makes stuff up. If a lawyer can't be bothered to read what they submit, why give them an easy excuse / pass? Forget about AI, frankly lawyers mess too much up anyway, and it's unacceptable. I've seen contract reviews, policy reviews, license reviews, where they'll gloss over statements, then act like they didn't when you point that out.

I just finished a policy review for a company I won't name. In two of the policy documents it says paraphrased: “This document overrides all other documents, to be a single source of truth.” The lawyers for the company kept trying to insist that didn't apply in our case because we had a contract, but, there was no exception for that. When I insisted they add that exception into the wording, they refused, had a fit, and basically stormed off like toddlers.

They were (and are), mad, they wrote a set of bad policy documents, and they are seemingly more annoyed that someone read them, and located issues. To be fair, I'm not asking them to rewrite multiple policy documents, just change: “This document overrides all other documents, to be a single source of truth.” to “This document overrides all other documents, to be a single source of truth, unless, the parties have an otherwise formalized policy / license negotiated.", or something like that.

Actually, I don't mind that person, I know we disagree a lot, but, I enjoy the back and forth with them.

That's actually hilarious!

We're clearly not going to agree, which is fine, I think we're divided enough as to render any more functional talks about this pointless.

Safety is either absolute or it's not, a degree of safety, which is what Rust provides, is the same as not having safety at all, from a functional standpoint. All I'm saying by that statement is you have to assume you have no safety. Why start with the assumption that what you're going to build is safe, so you can be unprofessional, rushed, sloppy, and careless? What if a bug in the Rust compiler removes that assumed safety? That would be fundamentally like a linter missing where you forgot to call free and release the memory you're holding.

I can take a C program, lint it with multiple linters, compile it with multiple compiles, a smart check to do when its critical code, and be sure the code is safe. Any reasonable project is going to have test cases, fuzzing, and all manners of checks / verifications, which any developer worth 2 cents is going to write. With AI being fairly advanced now, you can ask AI to review your code, so if the code you wrote turns out unsafe, that's really on the developer. Use static code analysis tools like Qodana, and SonarQube, to add more assurance you can trust the code. C isn't unsafe just by existing, C code can be unsafe, if you're not careful, don't understand memory / hardware, and write code that should never leave your computer.

Lets be clear about something, I'm not claiming I write perfect, bug free code. However, when I do make a mistake, I don't blame the language or compiler. The platform I'm working on right now, in TypeScript not C, has nearly 100k test cases, with two different test platforms, one in Playwright, and one in GO, that both have to pass validation runs before my code can deploy. I'm not relying on TypeScript to make sure my code is "safe". TypeScript has strict checks, for instance not misusing NULL, but do you trust them, or, do you write code to check them?

They'll reject the code, they do source level review, I've been in those meetings. Specially they complained about an inline ASM block that was setting up boot parameters for a PIC32 microcontroller, that had to use that initialization routine, due to a bug in the USB stack. The other point you brought up, C is not unsafe, the developer writes unsafe C code, C is just as safe as Rust, if you're not a fraud as a developer. If memory can be corrupted, then you can't claim memory safety, it's black and white, there is no grey in this analysis.

The point people keep making about Rust is that it's memory safe. Except for the large flashing issue in the room, that it is not memory safe, objectively, it has a keyword, to disable the safety. This is black and white, if Rust is memory safe, so is C, you could avoid pointers, overflows, underflows, and all the other ways to corrupt memory, and by the logic of Rust developers, that's memory safety. I'm not suggesting anything major, just drop the idea of memory safety, or, remove any ability to interact directly with memory, in a way you could corrupt it.

I asked ChatGPT, and it's making the same argument that I'm making: “https://chatgpt.com/share/6aa807d4-b858-83ea-8fb1-b8fe5dbb6c16”, it's memory safe, with qualification, which means it's not memory safe. The qualification point is a big point, just so we're on the same page, the problem I have with the claim of memory safety, is that it convinces bad programmers they have that safety net when they don't.

I've seen this time and time again where a language has a feature, such as “memory safety”, or “type safety”, but then the developer uses “any” instead of a type, and thinks their type safe. I had a Jr Dev submit code full of $any() in the HTML of an Angular application. He then explained to me, it was safe since Typescript has type checking, therefore, $any() is a good workaround to building a proper type and interface for what he was doing.

Either learn to program and develop code safety, making yourself the first line of defence for mistakes, and they happen, and once you're sure the code is functioning at near 100%, then you can rely on the “memory safety” or “type safety”, or “X”. The idea that Rust makes things safer or more trusted is nonsense, it might be a very capable language, but the safety, and the trust is based on the developers / engineers, not the language.

When you have to write safe code, that is used for automotive, or military, you can't use pointers, function pointers, or the cool new features of most languages. The code has to be simple, basic, and clean; otherwise they don't certify it, even if you can write the code safety, and assure all paths have full cleanup and checking being done, you still can't use pointers. Maybe this has relaxed in the last 10-years, but 10-years ago that was the standard I had to write code to, for our two military clients.

Out of fairness, I'm not opposed to that idea. There are some books I have never tried to revisit; however, I have tried with an open mind to read some works again, and my opinion didn't change enough to sway my overall view. You're pointing out one of the point I raised, the audience is wrong for these works, which is why kids don't continue to read. This is why free choice the route schools should take.

That really gets to the core of the issue, why doesn't the teacher, professor, or whatever want to discuss the book? Even if you disagree wholeheartedly with the theme / plot, you need to be open as an educator.

That could easily lead into a very dark place, and if that happened, that's a different topic, but for the most part, just keep it open.

Yes, you could write your program to not use it, but, how about all the libraries, and tooling? Unless your entire chain / stack is free from any unsafe keywords, it's basically useless. Even if your stack has no use of “unsafe”, the fact “unsafe” exists at all, destroys the concept of memory safety. If Rust is going to claim memory safety, without being memory safe, why not just claim anything at all? Rust is the only language that can make mythical unicorns real, it's just as valid a statement as being memory safe, in that it's a completely false statement.

Fine, if we're not going to agree, fair enough, have a great week!