[Someone]

Swift doesn't have a mature compiler, either. It isn't old enough to have fought enough battles.

Also, I wouldn't say the rust language definition is less stable than Swift's, which is still very much in flux (with changes such as the removal of C-style for loops in the pipeline or just released)

Also, Swift doesn't do garbage collection. That may cause problems when trying to build a shared GUI famework.

[nostrademons]

Swift is in an interesting position compiler-wise: the frontend is bleeding-edge and often unstable (though many of the crashes, in my experience, were fixed with Swift 2.2), but the backend is rock-solid LLVM, which has had a lot of optimization & stability improvements go into it through Clang and Apple's existing Objective-C toolchain. Rust is in the same position.

[DerekL]

> Also, Swift doesn't do garbage collection. That may cause problems when trying to build a shared GUI framework.

Do GUI frameworks require garbage collection? Cocoa doesn't.

But the current Android frameworks are written to function with GC, so if Google wants to support Swift or any other non-GC language, they would have write and maintain a second framework along side the old Java one.

[Someone]

GUI frameworks do not require GC, as many examples (Motif, Windows, Atari TOS, Mac OS, etc.) demonstrate. But i mentioned a _shared_ framework that is usable from both GC and non-GC languages.

They could, as you indicate, build two frameworks instead, but it would be a challenge to keep parity between them, both in look and feel and in functionality.

Having both opinions look the same is less important on mobile than on the desktop, but feel is important. For example, click delays should be very, very similar, selection methods should be the same, etc.

Functionality would be an even bigger challenge. If they ever release new functionality, say a new kind of control, for one framework first, and for the other a few months later, it would appear as if they do not consider the two languages to be primary languages on their platform.

So, one GUI framework, IMO, would be the best solution, not on technical, but on social/political grounds. As thevibesman suggests in a sister comment, having the non-GC framework instantiate a JVM is a solution, but only technically. Again, that would make the non-GC language look like a second-class, bolted-on thing.

Finally, all of the above applies non-GUI functionality (for example, if functionality gets added to the address book, it must become available in a GC and a non-GC API) and to third-party developers selling libraries to Android developers, too.

[thevibesman]

> But the current Android frameworks are written to function with GC, so if Google wants to support Swift or any other non-GC language, they would have write and maintain a second framework along side the old Java one.

While it is likely that this is how it could play out, it is certainly possible to have a garbage collected language and a managed memory language working together in the same program (e.g. a manual memory managed C program can start an internal JVM and pass data between the two languages).