Hacker News Reader

Comment by JeffKilborn | Hacker News Reader

While I find Rust interesting, how exactly will Rust deal with a 900lb gorilla that's about to get released from a cage?

Opensource Swift is only few months away and it already has a much bigger user base and is backed by the biggest company in tech. Rust & Swift share many common traits and kinda look alike as well.

Why should anyone pick Rust over Swift when Swift will be able to do everything Rust can do and is also positioned as a systems programming language? And Swift will also be a full-stack programming language and you will be able to program apps and backends with it.

I feel like Rust is about to get killed. And killed quickly.

View on HN

Swift is an applications programming language where the runtime is non-optional (at least AFAICT) and memory is managed dynamically. It will be competing with .Net and Java, not with C and C++ (though, as ever, there are surely plenty of C++ projects that don't actually need C++'s level of control and could benefit from a rewrite in Swift).

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. :)

>Swift is an applications programming language where the runtime is non-optional (at least AFAICT) and memory is managed dynamically.

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.

ARC is dynamic memory management. Is the decision to run destructors in an if block at run time? If so, that's dynamic.

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.

All destructors in Rust are also decided at runtime, fwiw. Even without any allocation or anything:

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

In practice many destructors can probably be scheduled statically at compile time.

Dynamic drop is something that will go away for all but the strange deferred-let case (It's not a language restriction). So that's okay.

We'll need to see how useful Swift is without Cocoa (still waiting for details on what's actually being open-sourced), but GCD is a runtime component as well. And as Manish has said, ARC is dynamic memory management, just like shared_ptr in C++ and Rc in Rust, though pervasive and implicit. If you'd like to convince me that Swift is suitable as a systems programming language, then you'll first have to show me an example of Swift code that can be compiled into a standalone binary that can be called from C, and then describe how many features of the language and standard library this disables. After that you can demonstrate how to run Swift code on a memory-constrained platform that doesn't allow dynamic memory allocation whatsoever.

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

C++14 isn't a modern language? Aw, you killed a dream there :P

Swift is fully garbage-collected. Reference counting is a form of garbage collection. It's in a different space.

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

It will be competing with .Net and Java, not with C and C++

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.

Rust will deal with it by being swifter than Swift. Significantly so: Rust's unique feature is safety without requiring reference counting or GC for all pointers, which makes it a viable replacement for C and C++ in many situations where other languages would be considered unacceptable, and close enough to viable in others that future versions of Rust have a decent chance of making up the difference. Plenty of applications don't need that, and I look forward to competition between Rust and Swift in those arenas. But the enduring popularity of C++ in the face of the many newer, safer languages out there is testament that Rust's performance advantage is likely to be attractive to a lot of people.

>Rust will deal with it by being swifter than Swift.

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?

Straw man. Not all applications are mobile apps on platforms on which Swift is king. On most platforms you can just as easily write it as a single unified Rust codebase. Perhaps even easier.

You might be interested in http://benchmarksgame.alioth.debian.org/u64/performance.php?... and http://benchmarksgame.alioth.debian.org/u64q/performance.php...

Have you seen the new Swift 2.0 benchmarks that they discussed at WWDC 15? It's now getting extremely fast. It won't be long before it surpasses Rust.

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.

Well, I certainly wish Swift well, and think they're doing cool stuff.

I personally disagree, there is little chance that Swift will be as fast as Rust and its runtime precludes it from a whole class of use that Rust has.

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 think that this is a good question, but poorly phrased; you assume in the phrasing that it's possible for the existence of one language to "kill" another.

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.

Swift is still (and will always be) automatically reference counted. Rust lets you closer to the metal. Rust also has much stronger safety guarantees – it's pretty easy to write Swift crashers that would just never compile in Rust. That's a big deal for the kind of software Rust is pitching itself at.

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

"systems programming" is a vague term which means different things for different people. Swift isn't systems by the definition used for Rust and C++.

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.)

>Go has to contend with Swift. Rust does not.

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/...

You missed my point, systems is a vague term. Go was also initially labelled as a systems language.

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

Right. People should just drop the term 'systems language' and project languages along useful dimensions:

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.

> Why should anyone pick Rust over Swift when Swift will be able to do everything Rust can do and is also positioned as a systems programming language?

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.

> Why should anyone pick Rust over Swift when Swift will be able to do everything Rust can do

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

>It's missing its biggest features.

Like what? Please do enlighten us.

Zero cost abstractions. Memory safety without overhead. Etc etc.

Safe lightweight references. Arc is garbage collection, and Swift is totally garbage collected. Rust is not. It's a rather important distinction. Because allocations must be thread safe, Swift references are also all atomic. If you do choose to use reference counting in Rust (it is nearly always avoidable), bumping a reference count with Rc is very cheap.

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.

Eh, at the end of the day, they're different languages and are following different paths. Sure they're superficially similar, but that's not all to it.

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.

While I generally agree with the sentiment it's worth mentioning that Rust preceded Swift and any similarities are the result of the Swift designers being influenced by Rust, not the other way around.

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).

The feature in question (`if let`) was added pretty recently. The RFC even mentions Swift! ;-) https://github.com/rust-lang/rfcs/blob/master/text/0160-if-l...

Yup, we hard stole if-let from Swift ;). We even made it better!

Reply on news.ycombinator.com