The struggle with Rust

Re:The struggle with Rust by humanrebar on Tuesday January 24, 2017 @02:40PM (#13474745)

Rust has opt-out safety with 'unsafe' blocks. C++ doesn't even have opt-in safety. You can get fairly close with smart pointers and some other techniques, but 'fairly close' doesn't cut it when you're talking about memory corruption issues.

[ Parent | on HN ]

Re:The struggle with Rust by AstralStorm on Tuesday January 24, 2017 @03:24PM (#13475111)

You can enforce safety by using the strict type system combined with polymorphic memory allocators in C++17, and get quite close to that with C++11.

The only thing you cannot exactly prevent is "cast_dammit_cast".

[ Parent | on HN ]

Re:The struggle with Rust by dbaupp on Tuesday January 24, 2017 @03:39PM (#13475249)

Could you be specific about how the type system and polymorphic memory allocators defend against things like dangling references, iterator invalidation and use-after-free/move? I can't imagine an allocator affecting these unless it's one that just has a no-op free (which only use-after-free, anyway), nor is the type system strong enough by itself.

[ Parent | on HN ]

Re:The struggle with Rust by AstralStorm on Wednesday January 25, 2017 @02:45AM (#13479543)

1) If you cannot get a plain reference you cannot get dangling references. 2) Use data structures that keep iterators valid and modern reference counted internals. (so that when you have an iterator, you have the object) Alternatively copy on write semantics. 3) Use after move is relatively tricky if you want more. However, your allocator or data structure can catch it with specific implementation of move operators. Use after free can be reduced to use after move or caught with right delete/new operators. 4) Instead, you may have an API where you have your own high level reference-like type. There is a cost to it, same as in Rust. 5) What you cannot do is enforce people to use it always.

[ Parent | on HN ]

Re:The struggle with Rust by dbaupp on Wednesday January 25, 2017 @02:22PM (#13484976)

> There is a cost to it, same as in Rust

All of these things have a larger cost than Rust: you're forced to use pervasive reference counting and very defensive data structures. Rust allows you to get away with pointers deep into other things, as well as aggressive data structures, all in safe code.

Rust also has reliable use-after-move defense for arbitrary resources (not just vague dynamic protections for only the memory resource), and defends against data races. That is, Rust has true safety in a way that can give higher performance than approximate safety in C++.

[ Parent | on HN ]

Re:The struggle with Rust by pjmlp on Tuesday January 24, 2017 @11:31PM (#13478538)

Kind of, you cannot enforce your team mates, consultants and third party libraries that are part of the whole product to use them.

Static analysers and code reviews are not always possible, depending on the target OS and compiler being used, or how the whole project across teams is organized.

[ Parent | on HN ]