This whole discussion seems kind of overblown. Every mainstream systems language is capable of having this kind of vulnerability, Rust included. But runtime pluggability is part of the culture of Java code (and some Python projects, and Ruby, &c) and isn't part of Rust or Go's culture. So every Java project is potentially exposed to this kind of thing, but only the plugin-styled Rust and Go programs are.
You're much less likely to see a deserialization bug in Rust or Go than in Java.
There is nothing intrinsic to Rust or Go that prevents deserialization bugs; they're just not encouraged by idiom like in Java.
> every Java project is potentially exposed to this kind of thing
Many Java projects, but not all. Class-loading permissions in a Java program are subject to the security-manager policy for the program; class loading can be moderated or even fully disabled (once the main program is loaded, of course).
The default is to allow anything to be loaded, however.
The Log4j "lookup" behaviour was, first of all, a really dumb design decision even in Java but it's just wrong to pretend that it would be equally easy for it to be so catastrophic in most languages, not just Rust, even in C++ I think you'd probably realise you'd screwed up while developing a way for the log framework to run arbitrary code.