"To ensure memory safety [given that you can't guarantee in the language layer that the bytecode we'll be operating is safe] you need a GC"
Rust invalidates the bracketed assumption. It's been known this is possible for a long time, but Rust is the first time a language with this capability has hit semi-mainstream audiences. C# sure doesn't do it, VB certainly doesn't do it!
Ultimately it comes down to a promise of conceptual cleansliness from the entirety of a language Frontend. It's a big commitment.
Isn't this saying that because the MSIL is generated from C#, VB.Net, F#, etc, that there can be no guarantee? As far as I know, Rust isn't compiling to a CLR, so the GC in .Net is happening at a lower level than the language, it's happening in the runtime.
GC is almost certainly best handled in the RTS if you're going to expect to have one. In theory, Rust could pick MSIL as a new target and then they'd pay overhead for a GC which is not useful at all.
Alternatively, due to the existence of the GC as a given in the CLR, it might be that manual memory isn't exposed (as well or as nicely) in the MSIL making the idea of targeting Rust to it kind of silly. I have no personal clue.
Since you can compile C and C++ to the CLR you can completely circumvent the GC if you want/need to. Interoperability with other CLR languages might be a bit hard, then (which raises the question on why target the CLR at all).
Rust invalidates the bracketed assumption. It's been known this is possible for a long time, but Rust is the first time a language with this capability has hit semi-mainstream audiences. C# sure doesn't do it, VB certainly doesn't do it!
Ultimately it comes down to a promise of conceptual cleansliness from the entirety of a language Frontend. It's a big commitment.