By that logic, you can't write any safe rust at all because it relies on a compiler written in C++.

We are discussing the languages themselves, not any particular implementation.

Only the codegen and many optimization parts of the compiler is in C++. The rest of it is in Rust.

> You can't write any code at all in Python or Java without relying on unsafe operations. Both of them have their runtimes written in C/C++.

Technically, pypy is a Python runtime written in Python.

> You can't write any code at all in Python or Java without relying on unsafe operations.

There are Python interpreters written in other languages: there is one in Rust, and there is Jython and IronPython.

There are at least three Java runtimes written in Java, Jikes RVM, MaximeVM, and GraalVM.

At least two of which use an unsafe dialect of Java for significant parts of the runtime, which I'm pretty sure you know well (maybe not Graal, but if not it's because it's bootstrapping on top of existing unsafe code).

Easy localizable via grep, and not full of UB and memory corruption issues, which is what the 70% of unsafety issues due to memory corruption on C, C++ and Objective-C relate to.

At some level of the stack some Assembly or compiler intrisics are needed, not at every line of code.

Jikes is the one I'm most familiar with and people working on its runtime absolutely suffered from UB and memory corruption issues... obviously not throughout the whole standard library but that's not the case for other JVMs either. In fact the Jikes people found it nicer to work in Rust than in Java on components like the garbage collector, because it was a better fit for working safely with this kind of code and they didn't have to write in a restricted subset of the language to avoid triggering the GC.

Since when Jikes uses Rust?

Also bootstrapting a language always requiring using its subset for low level layers, apparently not an issue that many parts of C, C++ cannot be implemented only with what ISO provides on the standard.

>You can't write any code at all in Python or Java without relying on unsafe operations. Both of them have their runtimes written in C/C++.

This isn't a meaningful distinction, in the end. Hardware is unsafe too. Real production CPUs have bugs in them which lead to cache lines becoming corrupted, address translations being wrong, branches going to the wrong place, etc. under extremely weird conditions. But, in the end, we don't really do much about it because we trust that it probably won't impact us since we assume the people who built the SoCs or those who wrote the standard library did a good enough job.

I’m not sure going down this road is meaningful because as soon as we get to machine code generators you get a “reset” on safety, no matter the language you implement a compiler in, it can have logic bugs which will result in many sort of serious bugs, including memory ones. This is true of both the rust compiler and Java’s JIT compiler.

Interpreters and the rest of the VM is a different beast, while they also have to be bootstrapped from some unsafe language one way or another, they are usually written in a much more expert, security- and correctness oriented way than your average program. So while they can and do have bugs, they are exceptionally well tested and, well, I wouldn’t expect the JVM to die out under my program the same way you don’t really expect the kernel to freeze either. This is also true of Rust stdlibs, I assume, but is it true of third party libs?