dwattttt

I didn't have budgets handy, but GDP is another way to normalise its cost to the country; ~$2.2B cost in 1942 with a nominal GDP of $166B, nominal GDP of $29.2T in 2024 puts the Manhattan Project's cost relative to GDP at $386B in 2024.

Nominal GDP from https://en.wikipedia.org/wiki/Economic_statistics_of_the_Uni...

The fact that 'unsafe' also enables all unsafe operations in the function body just makes it even messier

This changed in the 2024 edition to now fire a warning lint, asking you to wrap your unsafe operations in an unsafe block, even inside an unsafe function.

Why are there exceptions in the first place then? If that's what you want, write ON ERROR RESUME NEXT and be honest about it.

I think this point gets missed too often in the face of technical things the Rust compiler does.

There was a world where everyone just used the unsafe keyword everywhere, and Rust code crashed & had memory issues all the time.

The big thing Rust did wasn't invent borrow checking or memory safety; it's the ease of use, the defaults, and the social aspect of "if unsafe is used, a memory bug is in the unsafe part".

It's not as pessimistic as it sounds. The task of "make the handling of the unsafe as safe as possible" can be quite easy; in some cases, hiding the unsafe in a module and only exposing a safe wrapper means there's only a small amount of code you have to review.

it simply marks parts where the compiler ignores parts of its rule set

This is a common misconception, in a literal interpretation. It doesn't invalidate your point, but since people get the wrong impression: unsafe doesn't turn off any of the checks the Rust compiler does.

It allows you to perform 5 additional operations, and that's it. Using those operations wrong is what breaks the safety promises of the language. As an example, you could dereference a raw pointer and tell the Rust compiler it lives forever, when it's really a pointer to an object that's about to be freed.

Relative "number of unsafe keywords" or "lines inside unsafe blocks" isn't a good metric.

It's unsafe to call a C library that gives you a raw pointer, that can be a single line. It's unsafe to use that pointer, that could be a second single line. Carrying that pointer around, the data structures it's in, that's all safe, and doesn't implicate lifetime checking at all, so Rust will let you do silly things with the actual lifetime.

A better metric would be absolute unsafe keywords (because each carries a need to review), or "code in a module that uses unsafe anywhere" vs total code, because module boundaries isolate unsafe.

I've heard that project architecture has a strong enough impact on feature completion rate that you can infer how tightly coupled vs loosely plugin based it is just from graphs of feature release.

Drivers still need to pass certification & get signed. Microsoft does get to reject them.

I can't imagine the group doing this validation is sufficiently manned/funded; it's a cost centre, and the effects of cutting it don't show up for years.

You may have missed this in their comment:

resolving identifiers as symbols, and then choose legal names for them in the target language

The responsibility for avoiding collision with the target language is in the transpiler; it should mangle identifiers appropriately to ensure you can't accidentally hit a keyword in the target language.

Or scenario D:

A text editor stores a URL in a location on disk, and another component then fetches and executes that with its current privileges.

I can't tell if this is germane to the analogy or not, but the air flow over your hand, even behind a book, is still a function of the car's speed. As an illustrative example, imagine the feeling when the car is at 0 compared to when the car is at 60.

Levenshtein distance and semantic distance can be wildly different. Deed -> dead, for instance.

Is there a "Rust compiler's rule" you can point to that's harder than avoiding UB in C or C++ in similar circumstances? They strike me as very similar beasts.

The safety aspects do get very hyped. It's better to consider the language strict about correctness; memory safety falls out of that, but so does other stuff, like less logic bugs.

Which is the worse surprise, when you update your dependency during development and get a fault, or when a user somehow ends up with a fault because of the previous default?

And I don't see how this affects how "professional" this is, unless "professional" is just performative nonsense and nothing to do with the substance of the text?

It changes my opinion of whether I trust ark to actually be right, or whether he has (and will continue to) let his emotions get in the way. The particular quote I noted was

We probably tried to tell you to try enabling it and you didn't listen. We have good advice, damn it!

He wanted to say this, more than he wanted to know if he was right. It reduces my trust in his judgement.

I don't know why choice of language is having such sway in determining what you view as professional

This is a blog post: it's purely textual, language is the only thing it uses to convey meaning. The words chosen to do so reflect what the author thinks.

where I'm from people just use the words they need to to communicate what they're trying to say

Yes. What ark is trying to say, via the words he chose, is what's earning him the description of "unprofessional".

He could say every factual thing in the blog post without being unprofessional, he just chose not to.

"a stinky manager ... Just a total shit show" are examples I would reach for to demonstrate someone is not being professional.

We probably tried to tell you to try enabling it and you didn't listen. We have good advice, damn it!

Not knowing whether you actually gave the advice you're blaming them for not taking isn't professional, it instead comes across as bitter.

I think https://news.ycombinator.com/item?id=48766436 is a practical answer. A marker that can't be forged (without explicitly malicious code being written), which is needed by the "yield to suspend/shutdown" function.

Missing the "wipe key from memory" means you don't have the marker, and trying to continue the suspend/shutdown will fail to compile, because you don't have the marker.

You're also not restricted to 4 digits. A full passphrase is an option.

5. Therefore, anything that enables people to write faster is good for the students, who can get more paper written, or the paper better revised, during the finite time available for writing.

I think you're missing some logic in there somewhere. If a student fills in as many pages as they can, each with the number 1 written on it as large as possible, was this a good conclusion? The quantity of writing is not a good metric.

EDIT: to give a closer to reality example, an essay that's 4 times longer than a competing essay does not make it better.

If your test is bottlenecked on the speed it takes to write it, you're testing writing skills.

I also challenge that "hand writing is harder to revise"; again, why is the speed it takes to write it at all relevant?

Yes. The work to assert each pointer passed into a function isn't "high"; it's purely mechanical, it could almost be refactored automatically. But most of all, the effort required to prove you don't need to is _way_ higher.

You're not "extending" the valid state space. That null value being passed to that function is already a potential state of your program.

You're actually pruning the valid state space; before, when the null value is passed to the function, there are more operations performed that have uncertain consequences. If you assert-and-fail when you get the null input, you've pruned those states.

Because no one is expecting it to work if a null is passed. Your total range of behaviours left are crashes, doesn't crash and is silently ok, or doesn't crash and causes something worse (data corruption, you get your product in a CVE, that area).

My proposition is that "it's silently ok" isn't likely enough, which is in line with your position on "don't extend the contract to accept null". So what's left is crash, or something worse.

So if those are your choices, don't waste time justifying that a null can't get there, just add a check to ensure you get the better behaviour. It takes seconds.

No. I'm talking about adding the check to reject NULL. Then you don't have to spend time justifying or figuring out why a NULL can't turn up here.

I haven't seen hundreds of dependencies in C projects either. But I _have_ seen on the scale of 1s to 10s of libraries and algorithms vendored in (sometimes just a header or 5).

It's also an indirect risk, but I've seen C projects reimplement things that would be a dependency in Rust, and introduce subtle (or not subtle) bugs.

It takes a lot longer to figure out if it'll be a problem than to just add the check. And you don't have to ponder whether it's possible for a null to get there, because now it's fine if it does.