Hey everyone! I wanted to start a friendly debate on the forums about Swift vs Rust. Both of these languages are targeting similar audiences and try to fix very similar problems. As a long-time Swift developer, I really do love the Swift programming language in many ways. I love the syntax of swift along with the type system. Just recently I've been looking into the rust programming language to see how I'd like it and I must say using rust has brought a lot of missing swift features to my attention. I think swift has the biggest issue in terms of the way the core libraries work. In my honest opinion, I feel the core libraries need to be rethought/redesigned from the ground up similar to what rust has done. Rust has build in cross-platform Networking and File IO functions along with async/await. Swift has none of these in the standard library and if people don't want to use the core libraries forces the developer to drop down to C code to get these low level operations done. Also something to mention, the Swift compiler is written in C++, but the rust compiler is literally written in... rust. I think the biggest issues with swift are the lack of built in async/await syntax. Rust just added this and I wanted to ask is this something planned in the near future for swift? Maybe also building in the core libraries better into the language itself rather than core libraries that feel kinda alien to the language sometimes. Also not to mention Foundation and GCD are written mostly in C. I think Swift needs to become a lot more of an independent language similar to something like Rust to start building more momentum outside of the Apple Ecosystem. So to sum this massive paragraph I think Swift needs more language independence & async/await features along with built in (more native) File IO and Network IO functions/handlers. There's a lot that I can go on about but what do you all think? Do you think swift could benefit from becoming more like the Rust programming language? Super sorry for the long post, thank you so much for your time!
Is there a real advantage in using a language to write its own compiler?
The idea of rewriting Swift's compiler in Swift has long been addressed in the Commonly Rejected Proposals document, and I don't see what would be gained outside of the coolness factor. I mean... C++ isn't that bad 
Yeah fair points there, C++ is kinda that super well supported language that everything if built for
Async/Await is definitely on the roadmap. Swift just is not quite there yet as far as features needed to develop async and await on top of.
There are a number of threads on the topic, but this one is current and relevant: Async/await status? - #42 by tera
There is a project to rewrite parts of the compiler in Swift, starting with the driver. See: New project announcement: Swift compiler driver reimplementation in Swift. That project is intended to replace the current driver, meaning the compiler will indeed require Swift, and may start using the language in other components, too.
Not to argue against it, but just curious: Why re-implement the compiler in Swift? To reduce the project's complexity by reducing the number of languages involved? Because of Swift's own advantages?
Truly it has no 'functional' purpose. If I had to go back I probably would have took that bit out of the post but what I was trying to get at was language independence in itself I guess
No wonder Rust is more mature than Swift since it was developed since 2006 (Swift started development in 2010) and had it's first release (alpha) in 2012 (Swift was published first in 2014). Rome wasn't build in one day …
I'm not against C++, however I would make the guess that many Swift developers (myself included) don't know C++, so implementing the compiler in Swift could make it easier for people to contribute to it.
It also wonders me how Swift progress is so slow compare to other relatively new languages such as Rust and Kotlin while in fact Swift is backed up by Apple which is one of the most valuable company on Earth. Resource shouldn't be an excuse. It seems Swift isn't really in Apple's top priority list anymore. Apple seems to only care about Swift in and for its own platforms.
Apple desires some level of stability in the language and its libraries, especially now that ABI stability is a thing.
It might just be a perception problem, but I find myself asking the same. Certainly some time is spent writing frameworks such as SwiftUI, but I think there should be more visible progress on “big” features such as move-only types, async/await, or improvements to generics.
I think perception is definitely an issue. From a user perspective of Swift it's very difficult to know what the roadmap for the language is in the short/long term right now. We know that the diagnostics are being worked on, and there is something going on with the ownership model, but progress on that is unknown.
Release schedules are also unknown and are hidden away because of having to coincide with Xcode release schedules etc (which only Apple knows). Other languages, like Rust (as that's the example being used here) have a predictable release schedule so users can plan in advance for any changes they might have to be aware of, but with Swift we know that 5.2 will be coming out this year but that's as much as we know, it could be WWDC time, earlier, or even later.
I do realise that Apple does not owe it to anyone but their shareholders and until software tooling or software R&D expenditures were deemed to be an impact to revenues and profits, I doubt investors would shout for data.
Apple is improving their platform, Apple is investing in Xcode and Swift, etc... that is undeniable. Could they be doing a lot more or not? Impossible to know since nobody outside of Apple has any visibility on any data from which something concrete could be inferred. So wild speculation, hype, and FUD (“oh no they know native apps are bound to die so they limit the investment!&!&”) abound.
If Apple only cares about its own platforms, then why bother to make Swift open source in the first place? Just to get some attention and (free) support from open source developer enthusiasts? But then again, if Apple doesn't care to support those developers anymore, why bother to make it open source?
At least, give some real roadmap (read: promise) on Apple platforms, plus Linux. Aren't they the main target for making Swift open source? Then let the open source community does the rest e.g. Windows and BSDs. But if Apple doesn't seem to seriously care about Swift development progress, I think the open source community would take back their support and return Swift back to Apple.
I find it crucial for a language to write its own compiler. Otherwise you may end up with core developers with very little Swift experience!
Additionally, I think there is a lot of C++ spill into the language because of this.
Swift being open source makes it easier to understand what the code in the runtime and libraries does and is also useful for debugging. E.g. when using SwiftUI it would help my understanding of the framework if i could see how some things are actually implemented.
It's great for marketing. We will probably never know the whole story, but making the platform attractive for developers is crucial, and open source is a big plus for many coders:
If Linux had been released as closed source, nearly nobody would even know it today.
My, maybe somewhat heterodox, thoughts on this are that Apple open sourced Swift because they thought that with that move they could just naturally get community involvement and benefit from a better Swift language in the long term, as has been the case for most other open source language.
Unfortunately, because Apple doesn't have a long tradition of open-source development, they underestimated the amount of effort that goes into maintaining a healthy open-source community, and made some key mistakes that meant that this effect didn't materialise as expected, such as:
- not prioritising non-Darwin platforms and/or non-mobile applications enough
- not prioritising tooling enough; there's enough hackers for which the idea of "you have to use XCode" is ludicrous and the experience in other editors / IDEs is subpar
- focusing on short-termism for marketing purposes instead of long-term health of the language (e.g. shipping SwiftUI before function builders were really thought out)
- reimplementing a package manager with half the functionality instead of building on the effort made by the community (i.e. Carthage, Cocoapods), not prioritising SPM development enough, and initially not even support SPM from within XCode
- not providing a clear road map / direction for Swift development
- not enough attention paid to fixing bugs in the compiler (some of them have been open for years)
- tying Swift release schedules to XCode
- patenting Swift features (that one really turned off a lot of developers)
- making it too difficult to compile the Swift compiler (to this date, you basically need to mine this forum for the right set of command line switches and it still takes hours and a lot of RAM), and not rewriting it in Swift in order to lower the barrier of entry for contributions
I think the wider developer community has refused to accept Swift (after some initial positive reactions because Swift does bring some good ideas to the table) and probably Apple has realised that and secretly accepted that it's just going to be a macOS/iOS language. But that's just my guess and who knows.
Perhaps that's the reason Chris Lattner left? Who knows.