> I don't believe there's anything you can do in C++ that you can't do in Rust.

I think you'll have to make "can do" more precise for this question to have a meaningful answer. All mentioned languages are Turing complete and thus equivalent on that level.

> you can't access raw memory.

I can wrap a file in a ByteBuffer in java and the JVM will (make a best effort to) perform native I/O on that. Does that pass as "access raw memory"? If not, you'd have to explain how this is different from the abstract machine that C++ is defined on.

Sure, in Java you can't escape the garbage collector, but in C++ you also formally invoke UB if you violate the object lifetime requirements (even though will generally work due to this part of the standard still being... work in progress, let's say).

> I think you'll have to make "can do" more precise for this question to have a meaningful answer. All mentioned languages are Turing complete and thus equivalent on that level.

I actually agree, I was just arguing with the point of the above comment which implicated you can't do lots of things in Rust that you can in C++. I don't know what the author was referring to, so I can't be more specific.

> I can wrap a file in a ByteBuffer in java and the JVM will (make a best effort to) perform native I/O on that. Does that pass as "access raw memory"?

I was referring to directly accessing the memory "owned" by local variables (the stack), the bytecode of the program itself (on von Neumann architecture), etc. It was a counterpoint in that implication that every other language (akin to publishing systems) had no limitations where Rust had. But I don't think that's actually a problem as (if that's ever needed) you can FFI to another language that can do that stuff and (as you said) all those languages are turing complete.

Sorry if it sounded like I was attacking Java & Python, for most applications I don't think the "runtime" limitation isn't a problem and comparing them to facebook is still hyperbolic.