Hacker News Reader

Comment by fauigerzigerk | Hacker News Reader

Not sure I necessarily agree with all your examples, but yes, this trade-off between safety and performance does exist in C++. It is particularily acute whenever you're forced to work with third party libraries that don't agree on a single approach to memory management.

Rust is essentially a bet on the impossibility of working around that trade-off in C++. And they are right, it is impossible to close that gap completely. C++ simply doesn't have the language features to enforce all necessary ownership rules without a performance penalty.

But I see trouble on the horizon for Rust, because that gap is quickly shrinking to its formally irreducible minimum as more C++ libraries are adopting a "modern" style. What's left of that gap may be too small to fit an entire new programming language built around fixing this single issue.

View on HN

Rust is more than just safety though. We had a huge community discussion last year: https://brson.github.io/fireflowers/

I know it's more than that. But what you can't do, in my opinion, is love Rust for its other modern features and merely tolerate the new approach to memory management.

Memory management in Rust is so dominant in terms of syntax and in terms of restrictions imposed on common idioms that it must be either embraced or rejected wholeheartedly.

This is just my personal opinion obviously, not any sort of truth or prediction.

Yeah, I totally hear you. I shared that opinion too, but, surprisingly enough, it seems to some degree that that's in the minority. Or at least, there's a pretty significant number of people who do "love Ruts for its other modern features and merely tolerate the new approach to memory management."

I feel that way myself now, but figured that I was just too close to have a mainstream opinion about it :)

That's good to know. Perhaps I just need more practice then.

Two main components of Rust's approach to memory management are i) the imposing/exploiting of scope lifetimes on objects and references, and ii) the restriction that a mutable reference may not co-exist with any other references (to the same object).

I suggest that with C++ there is kind of the option of embracing the former, without so much of the latter, to achieve a performance-safety combination that is closer to Rust's than current "modern C++" practices. That's sort of the premise of the SaferCPlusPlus library [1]. If you're a C++ programmer, the barrier to adoption is low. Though without a "borrow checker" or something equivalent, you wouldn't be able to match Rust's performance-safety combination in all cases.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

edit: edited the link

Reply on news.ycombinator.com