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.
> 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.
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.
> 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.
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.
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.
Nominal GDP from https://en.wikipedia.org/wiki/Economic_statistics_of_the_Uni...