4 ms·

In theory you can achieve a lot in C++. But C++ is like a large buffet where you can pick from a lot of different abstractions. Rust on the other hand is not

In theory you can achieve a lot in C++. But C++ is like a large buffet where you can pick from a lot of different abstractions. Rust on the other hand is not as flexible. But it rather tries to focus in safer abstractions, and provide convenience and coherence around them.

akiselev 10y ago
> Rust on the other hand is not as flexible. How so? If you want the same flexibility as C++ memory safety wise, you just use the unsafe keyword when you need to. A lot of Rust programmers are scared of unsafe blocks for some reason but writing unsafe code in Rust is no less safe than writing regular C/C++ except you can choose to reenable safety whenever you want to. You have to look out for subtle bugs that come up when safe code makes assumptions about unsafe code that you don't properly implement but these are logic bugs, same as you'd find in any other language when a module breaks a contract. Just don't use unsafe willy nilly in a library crate that you expect other people to use. As far as the rest of the language, I find Rust's traits to be far more flexible than C++ OOP, it just takes a little while to adapt to thinking in trait based composition. Once trait specialization and "impl Trait" hit stable and the Rust team figures out how to make the ambiguity rules less conservative, we'll have the best of both worlds: interfaces (both dynamic and static), trait based composition, and inheritance (you can already do regular OOP inheritance with a little bit of boilerplate like how Servo uses Upcast<T>/Downcast<T> traits for HTML object hierarchies). Both are currently in nightly (impl Trait might be beta already).
- partycoder 10y ago
  "unsafe" is expressing that you are opting-in for less safe code. Same in C#. Many unsafe abstractions are not opt-in in C++. You can go ahead and writing them. No warning or cost. "mut" and "unsafe" are keywords that you need to write down each time. They're keywords you can spot easily during a code review and say "how do you justify this?". Rust's language design choice of having everything being immutable and safe by default is a great idea.
  - Manishearth 10y ago
    > "unsafe" is expressing that you are opting-in for less safe code. Same in C#. Yes, but that is scoped. You can write unsafe code when designing an abstraction, and seal off the unsafety with a safe-to-use API. You then verify the abstraction, and are free to use it however you want. This is what's usually done, and this is what unsafe is for. "mut" isn't really a red-flag keyword. Sure, you don't want unnecessary mutation and everything is immutable by default, but nobody really has issues with making things mutable. Rust is not a language where purity is important. "unsafe" is, but for designing abstractions that's what unsafe is for, and while you still should justify it, "I need an abstraction like this and it can't be implemented in safe Rust because <reasons>" should be enough. Of course, you should be able to explain why it is safe to use, preferably in the docs/comments.
    - partycoder 10y ago
      No but "mut" comes with a maintenance cost. Where it is harder to make assumptions over its value.
Manishearth 10y ago
Rust is about safe-to-use abstractions, not necessarily safe-to-implement abstractions. While we like for abstractions to be implemented safely, it is totally okay to write an abstraction using unsafe code provided you can give it a safe API. So these abstractions may be implemented unsafely, but once implemented you don't need unsafe to use them. The only abstractions that C++ has that Rust doesn't are those involving intrusive datastructures (and you can make them work in some cases).

akiselev 10y ago

> Rust on the other hand is not as flexible. How so? If you want the same flexibility as C++ memory safety wise, you just use the unsafe keyword when you need to. A lot of Rust programmers are scared of unsafe blocks for some reason but writing unsafe code in Rust is no less safe than writing regular C/C++ except you can choose to reenable safety whenever you want to. You have to look out for subtle bugs that come up when safe code makes assumptions about unsafe code that you don't properly implement but these are logic bugs, same as you'd find in any other language when a module breaks a contract. Just don't use unsafe willy nilly in a library crate that you expect other people to use. As far as the rest of the language, I find Rust's traits to be far more flexible than C++ OOP, it just takes a little while to adapt to thinking in trait based composition. Once trait specialization and "impl Trait" hit stable and the Rust team figures out how to make the ambiguity rules less conservative, we'll have the best of both worlds: interfaces (both dynamic and static), trait based composition, and inheritance (you can already do regular OOP inheritance with a little bit of boilerplate like how Servo uses Upcast<T>/Downcast<T> traits for HTML object hierarchies). Both are currently in nightly (impl Trait might be beta already).

partycoder 10y ago
"unsafe" is expressing that you are opting-in for less safe code. Same in C#. Many unsafe abstractions are not opt-in in C++. You can go ahead and writing them. No warning or cost. "mut" and "unsafe" are keywords that you need to write down each time. They're keywords you can spot easily during a code review and say "how do you justify this?". Rust's language design choice of having everything being immutable and safe by default is a great idea.
- Manishearth 10y ago
  > "unsafe" is expressing that you are opting-in for less safe code. Same in C#. Yes, but that is scoped. You can write unsafe code when designing an abstraction, and seal off the unsafety with a safe-to-use API. You then verify the abstraction, and are free to use it however you want. This is what's usually done, and this is what unsafe is for. "mut" isn't really a red-flag keyword. Sure, you don't want unnecessary mutation and everything is immutable by default, but nobody really has issues with making things mutable. Rust is not a language where purity is important. "unsafe" is, but for designing abstractions that's what unsafe is for, and while you still should justify it, "I need an abstraction like this and it can't be implemented in safe Rust because <reasons>" should be enough. Of course, you should be able to explain why it is safe to use, preferably in the docs/comments.
  - partycoder 10y ago
    No but "mut" comes with a maintenance cost. Where it is harder to make assumptions over its value.

Manishearth 10y ago

Rust is about safe-to-use abstractions, not necessarily safe-to-implement abstractions. While we like for abstractions to be implemented safely, it is totally okay to write an abstraction using unsafe code provided you can give it a safe API. So these abstractions may be implemented unsafely, but once implemented you don't need unsafe to use them. The only abstractions that C++ has that Rust doesn't are those involving intrusive datastructures (and you can make them work in some cases).