Unlikely, rust is rather inconvenient for gui allocations.

And not at all compatible or easily bridgeable with obj-c, which was not optional.

Is there a way they could have known that?

Not really. The two are somewhat sister languages, but they have been syntax-optimized toward completely different focuses.

Swift for example defaults to copyable value types and reference types that are refcounted because that is what is most often needed for evented application code, while Rust defaults to non-copyable objects (with wrappers for things like reference counting) because of its systems development focus.

Swift also had a hard requirement of a decade of co-existance with Objective-C. A significant number of Swift types toll-free bridge with objc (and corefoundation) alternatives, and that had a considerable impact on the standard library. Their base library would be different from Rust's "std" due to needing different implementations of strings, vectors, dicts and so on.

The two do take quite a bit of inspiration from one another, and will gradually grow to support an ever-larger overlapping set of use cases, but the design constraints of the existing language will still mean that one or the other is better for a specific task.

No, that's not possible. Just one example -- In Rust/C++, developer is responsible for managing the memory, while in Java/Swift etc the language does most of the work for you. This alone can fundamentally change many aspects of language design and mean completely different experience for developers

Ah I see, I didn't know Swift was garbage collected. That makes sense.

EDIT: wait, I'm reading that swift does not have a garbage collector. I guess I don't see how it differs from Rust then.

EDIT2: ah I see, everything's a smart pointer basically and memory's released at the end (RAII-style), whereas Rust has the borrow checker (but it's still RAII-style). I guess both implement RAII ideas, but Rust seems to do it at compile time and Swift at run time.