On 22/06/14 07:24 PM, Andrew Poelstra wrote: > On Sun, Jun 22, 2014 at 05:26:47PM -0400, Daniel Micay wrote: >> >> Rust's design is based on the assumption that performance cannot be >> achieved simply by having highly optimized inner loops. It takes a whole >> program approach to performance by exposing references as first-class >> values and enforcing safety via type-checked lifetimes. >> >> You can write an efficient low-level loop in Haskell or Swift, but you >> can't build high level safe abstractions without paying a runtime cost. >> >> If someone isn't interested in this approach, then I have a hard time >> understanding why they would be using Rust. >> > > This is a bit of an aside, but the reason to use Rust if you don't care > about performance is that it not only tracks lifetimes, but tracks > ownership as well. As a side-effect, tracking lifetimes then becomes > much easier, as does eliminating manual memory management.
I don't understand what you mean here. Rust's lifetimes don't represent object lifetimes, they represent minimum reference lifetimes. Move semantics are a way of passing on the responsibility of calling the destructor. There is no tracking of ownership in the type system, as shown by the existence of types like `Rc<T>`. With `Rc<T>`, the programmer is responsible for ensuring that there are no ownership cycles because the compiler is unable to track this, it can only deal with destructors at a scope-based level. A managed language will not destroy an object until all references to the object are gone. There is no need to track reference lifetimes, because the references extend the object's lifetime as long as they exist (they *are* essentially the object). > This happens to also make sharing data across threads safer as well. (See > for example basically anything Niko has written on the subject.) Thread safety is provided via the Send trait, not anything to do with lifetimes. A garbage collected language could (many do) provide the same thread safety semantics as Rust. Value types, immutable reference types and synchronized reference types would be sendable. Rust only gains efficiency from the type system, not any form of thread safety that's not available to a garbage collected language. It's able to send `Box<T>` data structures without performing a deep copy. In the future, it will be possible to share disjoint `&mut T` between parallel jobs (but not normal tasks) but this is also just an efficiency improvement over other safe alternatives. > This, along with immutable-by-default and an aversion to magic implicit > behaviour (e.g. the Rc::clone() argument in the next thread), result in > a language which is extremely easy to analyze. It makes things harder to > write, but much easier to read. It has immutable variables by default, but the contents can still be mutable via internal (Cell, RefCell, RWLock, Mutex, atomics) or external (&mut, slice::MutItems) mutability at a type level. Removing the variable-level immutability was proposed, and it could still happen at this point: http://smallcultfollowing.com/babysteps/blog/2014/05/13/focusing-on-ownership/ It's true that there are no *user-defined* copy/move constructors, but `Gc<T>` *does* have magical implicit glue code running on assigning and parameter passing. The language just doesn't allow you to do the same thing in your own code. > Perhaps you can point out another language that does all this. You > definitely can't point out another language that does all this, -and- > has the massive community around it that Rust does. > > > So there is a strong reason to use Rust even if you don't care too much > about performance. > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
