Hacker News Reader

Comment by bogomipz | Hacker News Reader

>"I don't think there's much incentive post C++11 to really consider porting anything (even small things) over"

I am curious why specifically C++ 11? Could you elaborate?

Let's look at Rust's homepage: - Zero-cost abstractions - C++, in my opinion, is the founding father of zero-cost abstractions. - Move semantics - we've had this since C++11. - Threads without data races - C++11 introduced a threading library as part of the language. We can avoid a lot of data races, deadlocks, etc. if you actually look deeper into how to implement the modern threading library well. - Efficient C bindings - this had to be listed because we all know the world relies too much on C at the moment for this not to be a feature. C++ is almost a perfect superset of C, fantastic.

Modern C++ has made great strides in the direction of making writing good code a lot simpler. 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. It's just not viable.

For an experienced C++ dev it might not seem sensible. I can appreciate your viewpoint here.

But it can become a hot place for higher-level people to do lower-level things and rapidly learn a lot, as it has for me and some other Rubyists.

> - Threads without data races - C++11 introduced a threading library as part of the language. We can avoid a lot of data races, deadlocks, etc. if you actually look deeper into how to implement the modern threading library well.

So - we can implement threads without data races if we implement threads without data races? The reason people cite memory safety as a feature of Rust over C++ is because you get it for free, without having to do any additional work to achieve it.

> The reason people cite memory safety as a feature of Rust over C++ is because you get it for free

Nothing is free, language design is an exercise in compromise. OP might need to calm down a bit with the aggressive language, but underneath all that there is real message from people using (trying to ?) use modern C++ : The added safety you mentioned can 1) be really well approximated using modern C++ technics, 2) addressed by really well engrained coding standard and practice learned and known for a long time and doesn't apply for the in the unsafe part of rust that some of the libraries have to use. But i doesnt come at the cost of reduce expressiveness in the safe part of language, slower compiler time and high learning curve.

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

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

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

> > omitting the constructor call

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

Thanks for the detailed explanation. I appreciate it.

Reply on news.ycombinator.com