> > - 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.
> 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++.
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.
But 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.
Surely "a + b" is nicer to the eye than "a.add(b)", but unless a and b are numbers, a method call with a meaningful name is more straightforward than any abuse of allowed operators.
> Take a look at Scala for an arguably worse implementation of operator overloading.
Indeed
> Though still, the IDE helps a lot there.
If I need an IDE to understand some code, and tend to stay away from that code/language.
What if a and b are numbers? What if they're matrices? What if they're quaternions -- or higher? What if they're finite fields? Additive groups? Points on an elliptic curve? Random variables?
Operators (+ - * / ^ & | ¬) come from mathematics. While I'm sure there are plenty of node jockeys who have little use for numbers outside of specifying ports, there are still plenty of us for whom operator overloading is a necessary good.
> 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.
Is 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.)
As 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.
> 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.