News for hackers. Stuff that matters.
Re:Ask HN: Will Rust ever become a mainstream systems progra... by Rusky on Monday April 10, 2017 @08:40PM (#14083878)
> - Move semantics - we've had this since C++11.

C++11 move semantics and Rust move semantics are not equivalent. C++ requires every movable type to have a null state, and a (perhaps derived) move constructor that can potentially throw exceptions.

Rust avoids the null state problem by statically omitting the constructor call (or, in the dynamic case, inserting a flag into the stack frame rather than forcing the programmer to reuse the object itself). It gains some ability to optimize by forbidding unwinding during a move.

> I don't think you're gonna convince C++ (and C developers, of course) programmers who've been doing systems programming for a long time to stop everything and jump to Rust.

That's not the goal. The goal is to provide a tool for new projects like Servo, or incremental partial rewrites like Firefox, or new infrastructure like ripgrep.

Re:Ask HN: Will Rust ever become a mainstream systems progra... by soulbadguy on Tuesday April 11, 2017 @12:53PM (#14089932)
> C++11 move semantics and Rust move semantics are not equivalent. C++ requires every movable type to have a null state, and a (perhaps derived) move constructor that can potentially throw exceptions.

This doesn't sounds true to me. Can you clarify what you mean by moveable type have to have null state ?

> Rust avoids the null state problem by statically omitting the constructor call

You seems to be conflating move semantics and move optimization...

Re:Ask HN: Will Rust ever become a mainstream systems progra... by dbaupp on Tuesday April 11, 2017 @01:19PM (#14090214)
The parent correct: C++ runs destructors on all local variables, even if they have been "moved from", so it must be valid to do so. This translates into a null/"valid invalid"/sentinel state that the destructor can check to avoid truly destroying the underlying resource (which could result in double-freeing memory, or double-closing a file, or some other undefined behaviour). For instance, moving out of a unique_ptr will swap in NULL, and the destructor checks for that.

Static omission of destructors in Rust is more than just an optimisation: locals (and other values) never have their destructors run once they've been moved-from, and thus no values need null states, and moving a value doesn't have to run arbitrary code (it can be, and is, just a memcpy).

Re:Ask HN: Will Rust ever become a mainstream systems progra... by Rusky on Tuesday April 11, 2017 @01:45PM (#14090541)
> > omitting the constructor call

Oops, too late to edit but that was meant to say "destructor."