Swift isn't going to penetrate to the bottom of the stack with pervasive reference counting. You'd either have to start managing memory manually (as per C) or implement a borrow checker (as per Rust), and even then your entire ecosystem is still going to use reference counting pervasively due to the language's defaults. One of the benefits of Rust defaulting to linear types and borrowed references is that it creates an entire package ecosystem where dynamic memory management is the exception, not the rule.

For the record, I think Swift is super fantastic as a language and I'm thrilled that it's going open-source. I think the two languages will work swimmingly together. :)

I would formulate this a bit milder: many desktop applications are written in C++ and many system applications (e.g. UNIX command-line tools) could be written in Swift or Go. So, there are certainly areas where C++, Rust, Go, and Swift are or will be in competition.

Of course, if you require strong safety guarantees and the absence of a garbage collector, Rust is probably the only modern option.

No, it's optional if you don't need to interact with Obj-C frameworks (ie. Cocoa). And memory is not managed dynamically. Swift uses ARC.

Like I said, I just don't see Rust sticking around for long. Swift will suck all the developers out of it since you'll be able to actually get a job programming in Swift.

If anything, Rust is the only modern language that's not threatened by Swift, by virtue of existing at a level of the stack that's so low as to be out of Swift's reach. I agree that Swift is going to be huge, but you're mistaken as to who its competitors are. :P

Rust provides dynamic memory management too, but you aren't forced to use it and most use it for a few variables only.

So far nothing I've seen about Swift tells me that it will be able to be used for things like Servo and other perf-critical applications. Yes, it might edge out Rust webdev, but not much more.

"You cam get a job in swift" is largely due to its iOS backing. I'm not so sure how that's going to apply to other OSs especially if Cocoa and co aren't made open source.

    let foo = Moves::new(); 
    if condition { mem::drop(foo) }
    // should foo be dropped here?

(And I like Swift and think their development team is really cool.)

By how much? Will extra language codebase justify the speed increase (if any)?

Say you're developing some mobile app, why wouldn't you want to use a single unified codebase for front & backends instead of splitting it across Rust and Swift?

Anyway, if 5% improvement is all that Rust will have over Swift, it's as dead as Lisp.

When Swift is finally open-sourced, there will be a huge exodus from Rust community and move to Swift. This is not survivable. Rust will quickly lose the little momentum that it has right now and it will be game over.

Personally I believe that any investment into codebases using Rust is a huge mistake and a waste of money at this point in time.

Swift also is annoyingly special-cased, with things like Options being special in the language, and if let only working on options (if i understand correctly). Rust took syntax like if let from swift, and then made it general.

Swift also has to deal with Obj-C interop which is not great. I imagine Swift being as popular as Objective-C in terms of non-mobile apps.

I was somewhat disappointed when Apple shipped Swift; I feel like Rust has considerably more potential as a general purpose language, and it would be nice to have less dilution of effort in fairly similar space.

However, I don't think that the existence of Swift is an existential threat to Rust.

> Swift will be able to do everything Rust can do and is also positioned as a systems programming language

Swift is an interesting language, with some good ideas, and in many ways easier to use for application programming than Rust; but I still, on balance, think that Rust is more interesting and versatile.

Swift is not really a systems programming language. You can't write a kernel in Swift, nor target embedded platforms, nor write a library that could be called from other languages like Ruby or Python (at least, without bringing in the whole runtime as well). It's closer to the space of Go, a more systems-y application language.

Furthermore, open source Swift does not mean you will be able to use the whole ecosystem on other platforms. I highly doubt that Apple will port Cocoa/Cocoa Touch to other platforms; so Swift on other platforms will likely only be viable for back-end code.

Objective-C has been open source for years, and until the introduction of Swift was the dominant language of choice for writing code on one of the most popular smartphone platforms, but Apple canned cross-platform OpenStep when they bought NeXT, and Objective-C has never made serious inroads on other platforms (I know exactly one person who writes production, server-side code in Objective-C on Linux).

So, I could see Swift becoming popular for writing backends for iPhone applications, but I can't imagine that it will make serious inroads in other spaces, unless Apple makes a dramatic change in strategy and starts shipping their UI libraries on other platforms as well.

They do feel like quite similar languages; I'd think of them as a complementary Systems/Applications pair.

Go has to contend with Swift. Rust does not.

(Also, there are concerns about Swift's usefulness on non-apple platforms if the libs aren't completely open source.)

During the WWDC 2015 opening keynote, Federighi explicitly stated that Swift's a "systems programming language" and they even say it in the documentation:

> It is the first industrial-quality systems programming language that is as expressive and enjoyable as a scripting language.

https://developer.apple.com/library/ios/documentation/Swift/...

Swift calls itself a systems language. Rust/C++ call themselves systems languages. The two sets use those words to mean different things.

A: Garbage collected vs. not garbage collected. B: Generics vs. no generics. C: Algebraic datatypes vs. no algebraic data types.

Even with these three dimensions, it's easy to separate major languages

Rust: A-B+C+, Swift: A+B+C+, Go A+B-C-, Java: A+B+C-, C++: A-B+C- (discounting union types)

tl;dr: Swift is not in the same space as Rust.

Well, honestly, that's just what I thought about C/C++ in comparison to some 'newer' programming languages like Go, Rust (and also Swift, maybe? I don't know enough about Swift yet).

Personally, I would only use Swift if there was an easy way to write cross-platform (mobile) software with it. It's as simple as that.

Because Swift can't do everything Rust can do. It's missing its biggest features.

Like what? Please do enlighten us.

It also means that, like other managed languages, Swift objects that have references taken to them (classes) must in general be allocated on the heap. This means that, unlike Rust but like many higher-level languages, controlling allocations can be difficult and heavily dependent on the whims of the optimizer. Some of Swift's implementation decisions (like copy on write arrays) also suffer. The inability to avoid allocations, combined with much less efficient allocations than are possible with tracing GC, are among the reasons that reference counting is uncommon in production languages (though the Immix collector does very well).

You can certainly write code in the unsafe dialect of Swift that is just as fast as Rust, C, or any other language. But like unsafe mode in Rust, this won't be the common mode of use in Swift.

Python and Ruby are pretty similar languages overall, but neither has "killed" the other. Why? Because despite their similiarities, they offer different things. I generally prefer to use Python over Ruby, no real reason for it, I just prefer the language. With Rust and Swift, there are some pretty major differences that can't be waved away as personal preference, Rust's borrow-checker isn't something Swift can integrate overnight (and wouldn't likely do) and Rust can't just grow some ARC equivalent (and almost certainly won't).

And hey, some of my favorite minor features for Rust are cribbed from Swift. Namely `if let` and `while let`. I'm not scared of a little competition, keeps us on our toes and makes sure we keep looking for ways to improve the language and ecosystem.

Rust also has the equivalent of ARC in the form of the Rc and Arc containers, Rc does reference counting without atomics, Arc with atomics (for when you need to do reference counting with thread safety).