I think so, assuming I'm thinking of the same thing you are, but I think that's somewhat besides the point. What I'm trying to say is twofold:

- The presence of a GC doesn't guarantee memory safety since there are sources of memory unsafety that GCs don't/can't cover (i.e., escape hatches and/or FFI), not to mention the possibility of bugs in the GC implementation itself.

- The absence of a GC doesn't preclude memory safety since you can "just" refuse to compile anything which you can't prove to be memory-safe modulo escape hatches and/or axioms and/or FFI (and bugs, unfortunately). Formal verification toolchains for C (Frama-C, seL4's setup, etc.) and Ada/SPARK's stricter modes are good examples of this.

In the case of Rust:

- `unsafe` blocks (or at least their precursors) were added in 2011 [0].

- Rust's reference-counting GC was removed in 2014 [1].

That's why I think "ripped out their GC" is a bit of a non-sequitur for "got rid of the safeties". Rust wasn't entirely safe before the GC was removed because `unsafe` already existed. And even after the GC was removed, the entire point of Rust's infamous strictness is to reject programs for which safety can't be proved (modulo the same sources that existed before the GC was removed), so the removal of GC does not necessarily imply losing memory safety either.

[0]: https://github.com/rust-lang/rust/pull/1036

[1]: https://github.com/rust-lang/rust/pull/17666

Ah. I believe pretty much every safe language on the planet constantly has bugs in the implementation that can be exploited to cause unsafety. Sometimes they even get CVEs, e.g. in JavaScript VMs.

You've made it clear from this thread that you have no idea what you're talking about. Please do not waste our time by commenting on this topic further.