News for hackers. Stuff that matters.
Re:Rust 1.1 Stable, the Community Subteam, and RustCamp by kibwen on Thursday June 25, 2015 @07:13PM (#9781513)
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. :)

Re:Rust 1.1 Stable, the Community Subteam, and RustCamp by danieldk on Friday June 26, 2015 @03:02AM (#9782818)
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.

Re:Rust 1.1 Stable, the Community Subteam, and RustCamp by JeffKilborn on Thursday June 25, 2015 @07:52PM (#9781663)
>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.

Re:Rust 1.1 Stable, the Community Subteam, and RustCamp by kibwen on Thursday June 25, 2015 @08:51PM (#9781895)
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

Re:Rust 1.1 Stable, the Community Subteam, and RustCamp by Manishearth on Thursday June 25, 2015 @09:26PM (#9782001)
C++14 isn't a modern language? Aw, you killed a dream there :P
Re:Rust 1.1 Stable, the Community Subteam, and RustCamp by Manishearth on Thursday June 25, 2015 @08:03PM (#9781710)
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.

Re:Rust 1.1 Stable, the Community Subteam, and RustCamp by Gankro on Friday June 26, 2015 @02:49AM (#9782795)
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.
Re:Rust 1.1 Stable, the Community Subteam, and RustCamp by Manishearth on Friday June 26, 2015 @03:15AM (#9782845)
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.
Re:Rust 1.1 Stable, the Community Subteam, and RustCamp by pcwalton on Thursday June 25, 2015 @09:13PM (#9781969)
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.)