Possible, yes. But it's not like it's terribly difficult to verify correct usage of "unsafe" that amounts to a basic function call to a C library. Trivial uses of unsafe are pretty innocuous.
>Otherwise, it does not bode well for Rust code because any type safety glitch will be considered a vulnerability.
I mean, this is basically true. And it goes beyond type safety - there have been CVEs filed against the Rust stdlib for TOCTOU problems of a kind that the C++ stdlib is absolutely replete with (often the exact same ones in the exact same places, to the extent that comparable APIs exist) which ended up being fixed quickly in Rust and largely ignored in C++, if anyone bothered to file in the first place.
For sure does create headaches for those who need to categorize CVEs by impact, but on balance I don't think it's a bad thing for the ecosystem. Creating a culture that wants to fix soundness issues rather than mark them as WONTFIX with a line of documentation is a core principle and value proposition of Rust in the first place.
The thing is that if step 2 isn't proprietary, but rather more open source code, then it's not "extinguish" it's just garden variety open source competition.
Considering a substantial fraction of the commit history since then has been removing those instances of "unsafe" not all of are actually usages of "unsafe" (seems like there are a fair number of functions / types with unsafe in the name but not the signature), is that actually still true?
And if nothing else Rust forces you to document where they are, which isn't nothing.
How would that help? These are not general purpose, base system libraries, these are libraries specific to a product that uses them. Either you're not using them and hence they would not be installed in the first place, or you're using them because you have the product installed.
Though I would expect that Insights uses RPM packages to ship components and not the public NPM packages.
There are a number of compiler performance enhancements (and correctness improvements) that are being worked on that are kind of at a chokepoint behind some other piece of work. Unfortunately it's not that easy to discern what state they're in or how quickly they're making progress.
At some point though a lot of work will be able to start advancing at once, so long as people exist to do the work.
And yet, that hasn't translatd into additional support for Ukraine. In fact, Russian oil sanctions are lifted for the second month in a row, and Congress Republicans haven't put a Russian sanctions bill on the table because Trump doesn't want one.
The existence of other influences does not diminish the fact that Trump is enamored with Putin (and most "strong man" dictators generally, but Putin in particular) and it does impact his foreign policy decisions and those of his administration (Hegseth straight up canceled weapons shipments to Ukraine for 2 weeks in the aftermath of the Oval Office meeting thinking it would please the boss).
Because that's exactly what it was. I agree with you, the puritanism around special effects doesn't make sense when there's plenty of high quality archival footage out there, and instead of using that or CGI to look similar, you do something that looks completely wrong.
As a matter of fact he has mentioned that one of the Jacob's Ladder videos was the only time he messed up and came close to actually electrocuting himself (by reflexively trying to grab the leads as they fell off a table). Otherwise all of the shocks are "calculated" to be nonharmful.
Not really though. That's like saying that no language is "safe" because the compiler could have a bug.
It's true that safe wrappers around unsafe code sometimes have bugs in them, but it's orders of magnitude easier to get the abstraction right once than to use unsafe correctly in many places sprawled across a large codebase.