8 ms·

As someone coming from a web background with almost no systems programming experience, Rust is appealing to me in terms of it's language features and support fo

As someone coming from a web background with almost no systems programming experience, Rust is appealing to me in terms of it's language features and support for a functional style of programming, as well as the documentation and tooling (among other things). But from the little I've learned about modern C++ and RAII, I wonder how systems engineers will respond to Rust in the long-term. Memory safety seems to be the primary argument in favor of using Rust, but what would be easier - rewriting everything in Rust, or refactoring existing code to take advantage of RAII?

pjmlp 5y ago
RAII was already a thing in C++ compilers for MS-DOS.
CJefferson 5y ago
I've been using RAII in C++ since 2002 or so -- so it's not a new thing to do. Personally, I maintain quite a lot of open source C++ code -- I'm not rewriting that in Rust, but I'm writing new projects in Rust.
zwieback 5y ago
I used to be a 100% C++ programmer in the olden days but over the years C# and Python have pushed my C++ percentage down to maybe 10% super time critical code and some embedded. RAII is the one thing I really really miss from my C++ days. From what little I know about Rust it seems to promise a more "baked-in" version of RAII so I'm all for it. Haven't found the time to experiment but looking forward to eventually dipping my feet in.
- pjmlp 5y ago
  If you are using a relatively recent version of C#, you can get quite close to it, specially now that using can make use of structural typing. And with help of Roslyn, any type with a "destructor" (aka Dispose) that gets used without a using declaration can be turned into a compiler error.
- cogman10 5y ago
  I'd argue that RAII is pretty well baked into C++. For Rust, it's the "Drop" trait that you add onto things which ultimately causes RAII behavior. You don't need to do it as much with rust as a lot of the reasons for wanting RAII (memory management) are simply handled by the language. For Rust, it's sort of the "Pit of success" the easy thing to do is the right thing to do. Whereas in C++, it's pretty dang easy to new something up and fail to correctly delete it.
  - maccard 5y ago
    > Whereas in C++, it's pretty dang easy to new something up and fail to correctly delete it. This is true, but we shouldn't be encouraging people to reach for new/delete these days; auto Foo = std::make_unique<Foo>(args); does the right thing in a surprisngly large number of cases. It's not the only tool available, but it's a really damn good one.
    - de_keyboard 5y ago
      Can we agree that the new "best default" way of instantiating is... pretty damn weird? auto foo = std::make_unique<Foo>(args); Think about explaining this to a new C++ developer. This will feel much more natural to most developers: var foo = new Foo(args);
      - criddell 5y ago
        > Think about explaining this to a new C++ developer. How's this: The code allocates and initializes a new Foo instance with args. By using make_unique you guarantee that the destructor is called when foo goes out of scope for any reason.
      - not2b 5y ago
        The "best default" way of instantiating is Foo foo(args); Sometimes an object has to be on the heap as its own separate allocation (rather than on the stack or as a data member), but I notice that some new developers who come to C++ from some other language use the heap way too much.
cogman10 5y ago
> rewriting everything in Rust, or refactoring existing code to take advantage of RAII? Oh, refactoring existing C++ code is easier, hands down. You can, for the most part, keep your C++ algorithms exactly as is with little rewriting. Rewriting in rust may force you to totally rethink your approach (or use a lot of unsafe, or write really inefficient code).
leetcrew 5y ago
I'm not sure I fully understand the question. RAII is powerful, but it is just a tool to organize what is still manual resource management. it can help with memory/thread safety, but it doesn't guarantee those things by itself. ex: it's nice that std::vector's memory buffer will be freed when the object goes out of scope, but I can still do something stupid like hold onto to its .data() pointer and try to dereference later. to answer the more general question, I think most engineers would prefer to refactor a c++ project over rewriting the whole thing in rust, and rightly so. you usually don't want to fuck around with delicate things that currently work in these sorts of projects. perhaps over time you end up with an FFI layer over a thoroughly tested c++ core. then new features can be written in rust or whatever friendly language is popular at the time.
- rileymat2 5y ago
  One quibble one of the best uses for RAII is not memory management but any external resource like db connections or file handles or mutexes. The built in smart pointers take care of much of memory management. (Although they use RAII internally)
- ducharmdev 5y ago
  I appreciate the clarification, my understanding of this stuff is pretty superficial. Putting it that way, I can see why someone would appreciate that Rust guarantees safety by default, instead requiring you to opt-out explicitly when needed (with `unsafe`), versus the opt-in nature of RAII - for greenfield projects, anyway.

pjmlp 5y ago

RAII was already a thing in C++ compilers for MS-DOS.

CJefferson 5y ago

I've been using RAII in C++ since 2002 or so -- so it's not a new thing to do. Personally, I maintain quite a lot of open source C++ code -- I'm not rewriting that in Rust, but I'm writing new projects in Rust.

zwieback 5y ago

I used to be a 100% C++ programmer in the olden days but over the years C# and Python have pushed my C++ percentage down to maybe 10% super time critical code and some embedded. RAII is the one thing I really really miss from my C++ days. From what little I know about Rust it seems to promise a more "baked-in" version of RAII so I'm all for it. Haven't found the time to experiment but looking forward to eventually dipping my feet in.

pjmlp 5y ago
If you are using a relatively recent version of C#, you can get quite close to it, specially now that using can make use of structural typing. And with help of Roslyn, any type with a "destructor" (aka Dispose) that gets used without a using declaration can be turned into a compiler error.
cogman10 5y ago
I'd argue that RAII is pretty well baked into C++. For Rust, it's the "Drop" trait that you add onto things which ultimately causes RAII behavior. You don't need to do it as much with rust as a lot of the reasons for wanting RAII (memory management) are simply handled by the language. For Rust, it's sort of the "Pit of success" the easy thing to do is the right thing to do. Whereas in C++, it's pretty dang easy to new something up and fail to correctly delete it.
- maccard 5y ago
  > Whereas in C++, it's pretty dang easy to new something up and fail to correctly delete it. This is true, but we shouldn't be encouraging people to reach for new/delete these days; auto Foo = std::make_unique<Foo>(args); does the right thing in a surprisngly large number of cases. It's not the only tool available, but it's a really damn good one.
  - de_keyboard 5y ago
    Can we agree that the new "best default" way of instantiating is... pretty damn weird? auto foo = std::make_unique<Foo>(args); Think about explaining this to a new C++ developer. This will feel much more natural to most developers: var foo = new Foo(args);
    - criddell 5y ago
      > Think about explaining this to a new C++ developer. How's this: The code allocates and initializes a new Foo instance with args. By using make_unique you guarantee that the destructor is called when foo goes out of scope for any reason.
    - not2b 5y ago
      The "best default" way of instantiating is Foo foo(args); Sometimes an object has to be on the heap as its own separate allocation (rather than on the stack or as a data member), but I notice that some new developers who come to C++ from some other language use the heap way too much.

cogman10 5y ago

> rewriting everything in Rust, or refactoring existing code to take advantage of RAII? Oh, refactoring existing C++ code is easier, hands down. You can, for the most part, keep your C++ algorithms exactly as is with little rewriting. Rewriting in rust may force you to totally rethink your approach (or use a lot of unsafe, or write really inefficient code).

leetcrew 5y ago

I'm not sure I fully understand the question. RAII is powerful, but it is just a tool to organize what is still manual resource management. it can help with memory/thread safety, but it doesn't guarantee those things by itself. ex: it's nice that std::vector's memory buffer will be freed when the object goes out of scope, but I can still do something stupid like hold onto to its .data() pointer and try to dereference later. to answer the more general question, I think most engineers would prefer to refactor a c++ project over rewriting the whole thing in rust, and rightly so. you usually don't want to fuck around with delicate things that currently work in these sorts of projects. perhaps over time you end up with an FFI layer over a thoroughly tested c++ core. then new features can be written in rust or whatever friendly language is popular at the time.

rileymat2 5y ago
One quibble one of the best uses for RAII is not memory management but any external resource like db connections or file handles or mutexes. The built in smart pointers take care of much of memory management. (Although they use RAII internally)
ducharmdev 5y ago
I appreciate the clarification, my understanding of this stuff is pretty superficial. Putting it that way, I can see why someone would appreciate that Rust guarantees safety by default, instead requiring you to opt-out explicitly when needed (with `unsafe`), versus the opt-in nature of RAII - for greenfield projects, anyway.