[rust-dev] Integer overflow, round -2147483648

Daniel Micay danielmicay at gmail.com
Sun Jun 22 21:10:16 PDT 2014


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140623/af1927b1/attachment.sig>


More information about the Rust-dev mailing list