This is all very hand-wavey. Are you just describing a chicken-and-egg scenario?
Also, Swift probably can compete with Rust, especially when they finish adding Rust-style lifetimes. But the real advantage of Swift is it has a much more "high-level" feel than Rust – it's much more familiar to use than Rust by virtue of having classes and things. Swift also doesn't instantly force you into weeds of dealing with memory management complexity. I think I'm going to enjoy the "drop into manual memory management for hot paths" approach Swift is taking.
Not really no. It's not a matter of convincing other people to do support, it's a matter of Apple making a long-term on-going large investment into other platforms. They've definitely made some investments and are still making some more, but they're not enough if their goal is to promote Swift as a general programming language for any platform.
I can make some concrete examples: If Apple wants Swift to be successful in the open source world, it needs to at least get basic "passes test" level of support for the BSDs, and some other less common architectures. Look at the architectures supported by the "golang" package in Debian:
Now compare to the list of architectures supported by the Swift package in Debian: ... Oh. There's not one!
If this isn't getting the point across, I don't know what will.
(Side note: There are "official" Swift packages for Ubuntu, even if they're not upstreamed, but they only exist for amd64 and arm64. I know there is "community" support for riscv, which is pretty cool. Still... This is definitely a problem for Swift use in the open source community. Without Swift packages in Debian upstream, for example, I don't even think software based on Swift can be packaged for upstream inclusion.)
I'm particularly interested in this line of thinking, and I'd probably lean the same way. Would love to hear more, why do you think it's a better approach to default to more high-level, with the ability to drop down into manual memory management for hot paths?
Simply because hot paths are less common for a "typical" workload. So you'd want it to be more ergonomic by default. Where possible, jam all optimizations into the compiler so nobody has to think about it. If you can't do that, then allow developers to give the compiler more information even if it's more complex.
Relatedly, it allows the language to help you "first make it work, then make it good".
From an aestethic pov, swift is taking the exact opposite direction than go: it keeps piling on more language features, with much less concerns on keeping the language simple.
As a developer currently working in both, it feels like jumping to another civilisation every time i switch.
Also, Swift probably can compete with Rust, especially when they finish adding Rust-style lifetimes. But the real advantage of Swift is it has a much more "high-level" feel than Rust – it's much more familiar to use than Rust by virtue of having classes and things. Swift also doesn't instantly force you into weeds of dealing with memory management complexity. I think I'm going to enjoy the "drop into manual memory management for hot paths" approach Swift is taking.