4 ms·
> > - Explicit allocations (stack vs heap) and ownership management. > This is a great feature. If you're writing another web app, then sure, you don't care ab
by fooyc 12y ago
> > - Explicit allocations (stack vs heap) and ownership management.
> This is a great feature. If you're writing another web app, then sure, you don't care about stack vs heap. If you're writing performance oriented code, then you do. Both D and C# allow for a similar mechanism
Some languages do that for you. Allocating on the stack by default and falling back to the heap when it wouldn't be safe to allocate on the stack. e.g. if the object can outlive the current function call, it shouldn't be allocated on the stack.
If the Rust compiled doesn't known how to spot unsafe stack allocations, then you don't have memory safety.
> > Copy traits feel a lot like C++ copy constructor (a.k.a. I never known what simple things like assignments or passing an object around will actually do)
> The assignment operator is not overridable.
That's not what I said. Operator overloading is yet an other feature that's ruining everything else, though.
> > Yet they added some bug-provoking things like "The final expression in the function will be used as return value".
> Yet you provide no examples on how this is bug provoking. There have been exactly 0 bugs due to this feature.
I may be wrong on this one, since type checking would spot most problem at compile time.
- burntsushi 12y ago> Some languages do that for you. Allocating on the stack by default and falling back to the heap when it wouldn't be safe to allocate on the stack. e.g. if the object can outlive the current function call, it shouldn't be allocated on the stack. > If the Rust compiled doesn't known how to spot unsafe stack allocations, then you don't have memory safety. This seems like a weird thing to say given that the Rust compiler does fairly sophisticated analysis on the lifetime of data. (And yes, Rust has memory safety.) As a low level language, the programmer decides explicitly what is allocated on the stack and what is on the heap.
- fooyc 12y agoIs there many cases where it's safe to allocate an object on the stack, but you would want to allocate it on the heap instead ? (Appart from the the object being too big.)
- burntsushi 12y agoAs I said, it's about making costs explicit. Otherwise, you're relying on the compiler's escape analysis to choose whether to allocate something on the heap or the stack. A programmer might not realize that something escapes, and thus, there is a heap allocation that the programmer thought was a stack allocation. It's worth something to be able to say, "put this on the stack dammit" and if it can't go on the stack safely, require that the compiler yell at you.
- pcwalton 12y ago> Some languages do that for you. Allocating on the stack by default and falling back to the heap when it wouldn't be safe to allocate on the stack. e.g. if the object can outlive the current function call, it shouldn't be allocated on the stack. There are several problems with this approach for systems programming. 1. Escape analysis is conservative. Whenever you have an indirect function call or a call in another module, you have to assume that it will cause a value to escape. By making the lifetime part of the type, Rust can keep values on the stack even when indirect or cross-module functions are involved. 2. When you put a value on the heap, how do you know when to destroy it? All industry languages with escape analysis require a garbage collector, which reduces application throughput in the mark phase. But in Rust, with unique ownership, you can make that information known at compile time in most cases. 3. Not all heaps are created equal. There are many kinds of allocators—thread-local allocators, bump allocators, global allocators, etc. 4. Garbage collectors don't work very well with external libraries that don't use the same memory management scheme. By not requiring a garbage collector or a standard heap, Rust can interoperate better with other languages. For example, you can write libraries in Rust that plug into Ruby with no extra runtime support. > That's not what I said. Operator overloading is yet an other feature that's ruining everything else, though. Operator overloading is really important for things like bignums and custom containers like vectors. I think the Rust way of using traits for this (meaning that the operators always have consistent types, and have to be defined in one place) makes it much less confusing than the ad-hoc approach of C++.
- fooyc 12y agoThanks for this insightful answer. About operator overloading, some languages have seemless bignums without allowing users to overload operators in their own classes. For containers, this could have been restricted to the index operator.
- azth 12y agoBut it's not just about indexes or certain containers. Sure, C++ makes things unwieldy, but the solution is not to drop operator overloading in its entirety. Rust wants to take on C++ head to head. For graphics programming and certain applications, operator overloading makes life a lot easier, and is a very welcome addition. Take a look at Scala for an arguably worse implementation of operator overloading. Though still, the IDE helps a lot there.