4 ms·

Don't get me wrong I respect Rust core team as theorists and think rust is an important research project. But in C++ if you have a const member function F() th

Don't get me wrong I respect Rust core team as theorists and think rust is an important research project. But in C++ if you have a const member function F() then F() can only change member variables that use the "mutable" key word. If you default to all methods are const you have much much safer C++. As safe as rust? not probably but combined with liftimes proposal and static analysis rules we have a language good engineers can sufficiently work with. struct Foo { mutable auto a = 4; auto increment() const -> void { this->++a; } }; If we train engineers to use const member functions, then the programmer is forced to think about state and mutation. As C++98 PTSD begins to fade and C++17 becomes the cultural mental image of the language, the argument for switching to rust will become less and less compelling. Eventually, the only "advantage" will be ML influenced syntax. The reason is there are only three languages that can easily call into C++ code. Objective-C (swift by proxy), D, and of course C++. Why rust didn't prioritize compatibility with C++ like C++ did with C boggles my mind. Why do you think C++ became so popular? Near perfect C compatibility (until recently) is literally the only reason. Instead of focusing on pragmatisim Rust focused on language purity. At what cost?

pcwalton 11y ago
> But in C++ if you have a const member function F() then F() can only change member variables that use the "mutable" key word. This is not nearly enough. See the examples I gave in my other post. Besides, all "const" means is "I won't mutate 'this'". It doesn't mean someone else who has a non-const reference to your object won't mutate your object. That makes it largely useless for reasoning at a local level. > If we train engineers to use const member functions, then the programmer is forced to think about state and mutation. The programmer may think about it, but the compiler doesn't enforce it at all. > As C++98 PTSD begins to fade and C++17 becomes the cultural mental image of the language, the argument for switching to rust will become less and less compelling. Only if you don't understand how Rust works. > Why rust didn't prioritize compatibility with C++ like C++ did with C boggles my mind. Because C++ compatibility is impossible without being a derivative of C++, and C++ is hopeless in the safety department. I believe it is impossible to make C++ memory safe without making it not C++ anymore. > Instead of focusing on pragmatisim Rust focused on language purity. No, Rust focused on what is possible.
- autoreleasepool 11y ago
  > Because C++ compatibility is impossible without being a derivative of C++, and C++ is hopeless in the safety department. I believe it is impossible to make C++ memory safe without making it not C++ anymore. Do you consider D to be a derivative of C++? I don't. They have a near perfect C++ interface. D can even catch C++ exceptions. It's pretty sweet. You can hear about the black magic Andrei used to get that to work here: http://cppcast.com/2015/10/andrei-alexandrescu/ http://cppcast.com/2015/10/andrei-alexandrescu/ Side note: I'm actually thinking the Rust and C++ comparison misses the mark. First of all, C++ cannot be obsoleted by rust, it's economically impossible. Secondly, I don't even think they compete in the same domain space. Rust is actually lower level than C++, in that it does lower level stuff in a more natural way. It's C, that Rust makes obsolete; which is something C++ totally failed to do (because of it's RTTI, exceptions, and other runtime features -- all things you and the rest of the Rust team intelligently scrapped). After trying embedded Rust, I'm completely done using C (and the C parts of C++). IMO the advantages C++ still has over Rust are: - libraries, libraries, libraries - C++ has so many great libraries - *writing* C++ libraries with SFINAE sugar is the bees knees. - much better support and tooling, but this is for sure a temporary advantage. - template meta-programming feels like a different language, it's dynamic, functional, and the difference is refreshing. I like the mental switch you have to do to go from writing a C++ template to writing a C++ model. - as much as header files suck, they let you skim an API much more easily than Rust or Swift. - performant, memory safe data structures: For example, it's trivial to write a low overhead pointer that can't dangle, throws an exception on nullptr deference, and that safely points to an object it doesn't own (even if that object is its owner). With this and a unique_ptr composed with similar safety mechanisms you now have the primitives needed to write any data structures or algorithm so that it is protected from undefined and unsafe behavior, yet remains performant. This solution has significantly less overhead than using reference counted pointers like shared_ptr derivatives or Rc. The performance tradeoff over using raw pointers is minuscule and totally dwarfed by the gain in safety guarantees. From what I've observed, you can't do this in Rust, if you try to write a doubly linked list you either have to use C-pointers that can dangle inside unsafe blocks, or eat the Rc overhead. EDIT: How could I forget to mention the glory that is constexpr? Advantages of Rust over C++ (again, IMO): - the correct defaults (aka opposite of C's insanity) - best C++11 features built in and defaulted (move semantics, unique_ptr is Box<T>, Rc is shared_ptr etc..) - Bad ass embedded capabilities. You don't nearly feel as crippled like you do in C++ without the STL. - the safety guarantees are real, and they're awesome - move semantics into closures looks so goddamn elegant. I love it - inline assembly doesn't feel like a hack - modules and cargo rock - secretly and surprisingly similar to ruby in a lot of places :) - it wants you to think functionally, and unlike Swift, it means it. This is a good thing.

pcwalton 11y ago

> But in C++ if you have a const member function F() then F() can only change member variables that use the "mutable" key word. This is not nearly enough. See the examples I gave in my other post. Besides, all "const" means is "I won't mutate 'this'". It doesn't mean someone else who has a non-const reference to your object won't mutate your object. That makes it largely useless for reasoning at a local level. > If we train engineers to use const member functions, then the programmer is forced to think about state and mutation. The programmer may think about it, but the compiler doesn't enforce it at all. > As C++98 PTSD begins to fade and C++17 becomes the cultural mental image of the language, the argument for switching to rust will become less and less compelling. Only if you don't understand how Rust works. > Why rust didn't prioritize compatibility with C++ like C++ did with C boggles my mind. Because C++ compatibility is impossible without being a derivative of C++, and C++ is hopeless in the safety department. I believe it is impossible to make C++ memory safe without making it not C++ anymore. > Instead of focusing on pragmatisim Rust focused on language purity. No, Rust focused on what is possible.

autoreleasepool 11y ago
> Because C++ compatibility is impossible without being a derivative of C++, and C++ is hopeless in the safety department. I believe it is impossible to make C++ memory safe without making it not C++ anymore. Do you consider D to be a derivative of C++? I don't. They have a near perfect C++ interface. D can even catch C++ exceptions. It's pretty sweet. You can hear about the black magic Andrei used to get that to work here: http://cppcast.com/2015/10/andrei-alexandrescu/ http://cppcast.com/2015/10/andrei-alexandrescu/ Side note: I'm actually thinking the Rust and C++ comparison misses the mark. First of all, C++ cannot be obsoleted by rust, it's economically impossible. Secondly, I don't even think they compete in the same domain space. Rust is actually lower level than C++, in that it does lower level stuff in a more natural way. It's C, that Rust makes obsolete; which is something C++ totally failed to do (because of it's RTTI, exceptions, and other runtime features -- all things you and the rest of the Rust team intelligently scrapped). After trying embedded Rust, I'm completely done using C (and the C parts of C++). IMO the advantages C++ still has over Rust are: - libraries, libraries, libraries - C++ has so many great libraries - *writing* C++ libraries with SFINAE sugar is the bees knees. - much better support and tooling, but this is for sure a temporary advantage. - template meta-programming feels like a different language, it's dynamic, functional, and the difference is refreshing. I like the mental switch you have to do to go from writing a C++ template to writing a C++ model. - as much as header files suck, they let you skim an API much more easily than Rust or Swift. - performant, memory safe data structures: For example, it's trivial to write a low overhead pointer that can't dangle, throws an exception on nullptr deference, and that safely points to an object it doesn't own (even if that object is its owner). With this and a unique_ptr composed with similar safety mechanisms you now have the primitives needed to write any data structures or algorithm so that it is protected from undefined and unsafe behavior, yet remains performant. This solution has significantly less overhead than using reference counted pointers like shared_ptr derivatives or Rc. The performance tradeoff over using raw pointers is minuscule and totally dwarfed by the gain in safety guarantees. From what I've observed, you can't do this in Rust, if you try to write a doubly linked list you either have to use C-pointers that can dangle inside unsafe blocks, or eat the Rc overhead. EDIT: How could I forget to mention the glory that is constexpr? Advantages of Rust over C++ (again, IMO): - the correct defaults (aka opposite of C's insanity) - best C++11 features built in and defaulted (move semantics, unique_ptr is Box<T>, Rc is shared_ptr etc..) - Bad ass embedded capabilities. You don't nearly feel as crippled like you do in C++ without the STL. - the safety guarantees are real, and they're awesome - move semantics into closures looks so goddamn elegant. I love it - inline assembly doesn't feel like a hack - modules and cargo rock - secretly and surprisingly similar to ruby in a lot of places :) - it wants you to think functionally, and unlike Swift, it means it. This is a good thing.