Not really. Of course you can copy immutable data upon update, but persistent data structures (large shared state between data versions)[1] are hard to write without GC...
Reference counting [1] and atomic reference counting [2] are supported within Rust, and are sufficient for any persistent data structure without cycles. There's also a prototype crate for a mark and sweep GC [3], which would likely work for anything else. Writing such data structures using these features might be a bit more tedious than writing them in a GC language, but I suspect the increased explicitness provides a worthwhile tradeoff. See the crossbeam library [4] for some examples of lockless concurrent data structures implemented in Rust.
As an alternative GC in Rust, you also have Josephine[1], which uses the SpiderMonkey[2] GC. It's cumbersome to use though[3] and should probably not be used outside of Servo.
If you don't have cycles, ref counting can work (it's a kind of GC after all), but it indeed comes with a big performance overhead compared to a modern GC.
The problem with shared mutable state might appear to be then “mutable” but it’s the combination of shared+mutable.
Ownership removes one (if it’s mutable it’s not shared). Immutability removes the other.
The outcome is the same: you can reason about your code, including concurrent code.
The price of ownership is some extra mental overhead. The price of immutability is some extra copying and cumbersome updates.
In JS/Elm you have no choice but to manage shared mutable state using pure functions and immutable data. In rust you can use either model.