8 ms·

I think to get good at a given systems language these days the effort is the same. For instance, concurrency still requires the same underlying ideas to be unde

I think to get good at a given systems language these days the effort is the same. For instance, concurrency still requires the same underlying ideas to be understood whether C++ or Rust. After all the machine underneath is the same. Rust has some nice-to-haves of course, but C++ has been able to grow up and evolve because of the rich feature-set the template meta-programming language has provided it. One can simply stick to C++11 or 14 and work with those features alone to make strides in development. Hell, people have used C++98 for decades. Personally, I think what C++ offers is the same as Rust. Both need a robust testing and code-coverage tools for correctness, but the end result requires simply good development practices and love for the work being done.

quietbritishjim 7y ago
> Personally, I think what C++ offers is the same as Rust. I think this dismisses incidental complexity that can certainly exist in general, and certainly does exist in C++. Just look at how complex move semantics are in C++: * you have & and && references, * there are all sorts of categories (e.g. glvalues), * in a template && means something different (but not always), * std::move by itself doesn't actually do anything (yes I know it's a cast but this is still confusing at least upfront), * even if you do pass the result of std::move (or otherwisie know you have an rvalue reference) to a constructor then it's still possible that the object will actually be copied with no error or even warning. In Rust, the difference is enormous: * When you move from a value, it's guaranteed that the old object's destructor will not be called, so you don't need a move constructor that hackily sets up an empty value so is destructor won't do anything; * Move is always a bitwise copy so it's easier for the caller to understand and free for the implementor to implement (this is enabled by the previous point) * Move is the default instead of copy which makes a million times more sense because you can just implement copy as a regular method that happens to return (move!) its result (whereas you could never implement move as something that returns its result by copying) and if you actually want to copy a value to a function you can just call the copy method and move that value to it. This final one is key is really, it's not possible because of C++'s history and backwards-compatibility requirements and that's why it had to come up with the crazy system it now has. Rust has many nice features but really the move vs copy stuff by itself is a huge saving in complexity, and the fact that Rust manages it at all proves that it is not intrinsic to the problem. (Disclaimer: I have worked with C++ on and off full time for more than 15 years, whereas I have only tinkered with Rust.)
- pjmlp 7y ago
  You forgot about SFINAE, CTAD, decltype vs auto, perfectly forwarding references, guaranteed RVO (but only in certain ISO versions), initialization semantics, ...
  - WesternStar 7y ago
    He didn't forget perfectly forwarding references.
    - quietbritishjim 7y ago
      But that does show how confusing the notation is!
      - WesternStar 7y ago
        I guess I watched the back to basics c++ series on move semantics and its not really all that bad. I did struggle with it beforehand though. I've never worked in C++ tbh. I does take the 2 hours but you have it when you're done. https://youtu.be/St0MNEU5b0o https://youtu.be/St0MNEU5b0o
        quietbritishjim 7y ago
        Really? You can tell off the top of your head what the difference between an xvalue and a glvalue is? Which function has higher precedence in the overload list out of foo(string&) and foo(string&&)? (Note that's not a const string&!) That these are so obvious to you that there's no chance you would make a mistake about them when you're in a hurry trying to solve an actual problem that has its own complexities rather than playing games with C++'s unnecessary complexity? The one where foo(std::move(x)) doesn't necessarily move x is a particular killer (although at least it only causes a performance problem rather than noticable change in behaviour). I have worked with C++ for a hell of a lot more than 2 hours since C++11 came out (the first version with move semantics) and worked with many others that have too, and I can tell you that "once you have it you're done" is just not true. I fully understand all the concepts but I can still make mistakes.
rapsey 7y ago
> I think to get good at a given systems language these days the effort is the same Someone who has been proficient at something for a long time has a very difficult time getting into a mindset of a beginner. This is why I think you are completely wrong about this point. > Rust has some nice-to-haves of course, but C++ has been able to grow up and evolve because of the rich feature-set the template meta-programming language has provided it. C++ has not and can not hide all the hidden gotchas and complexities that it has accrued over the years.
gameswithgo 7y ago
>concurrency still requires the same underlying ideas to be understood whether C++ or Rust But Rust will catch data race mistakes at compile time, which is very nice. That is a common mistake, and a mistake that can keep happening without you being aware for a long time.
- pjmlp 7y ago
  That is a common misconception. It only applies to threaded code, as soon as IPC, or other kind of external resources enter into the picture there is very little that Rust's type system can do to help with.
  - burntsushi 7y ago
    There is zero misconception in the GP. Catching data races in threaded code is extremely valuable, regardless of whether it applies to IPC or not. Why? Because non-IPC multithreaded code is a thing. Libraries like rayon even make this sort of parallelism quite easy. With the help of the Rust compiler, it's all safe too. Just because this doesn't extend to IPC (of course not) doesn't mean there is some kind of misconception here.
    - pjmlp 7y ago
      Misconception is that IPC and external resources is always left out of the message, so anyone without experience in distributed computing assumes guarantees that Rust actually does not provide.
      - burntsushi 7y ago
        That's not a misconception. It's a totally different problem space. > so anyone without experience in distributed computing assumes guarantees that Rust actually does not provide. [citation needed]
  - hechang1997 7y ago
    I don't think you can have shared IPC memory in rust. You have to use message passing. Of course you are on your own completely, and there will be weird logic bugs when you mess it up. However, there won't be any memory corruptions.
zamalek 7y ago
> Personally, I think what C++ offers is the same as Rust. I see this pretty often and don't understand where this idea originates from. We have huge amounts of evidence to the contrary[1], that is generated by developers who likely have more experience with parallelism and memory than anyone in this comments section ("likely"). If the ultimate pedigree don't get it right, keeping in mind that they never have (apart from NASA who disallow threading and allocation), how is there this belief that it is at all possible. It's the software equivalent of flat-earthing or climate change denial. We have abundant hard evidence supporting the inability for humans to reason about memory allocation, and absolutely zero evidence to the contrary. Safe Rust eliminates entire categories of bugs. It doesn't eliminate all bugs (including vulnerabilities), so you do need testing, but it does a huge amount more than nothing (C++). [1]: https://cve.mitre.org/ https://cve.mitre.org/

quietbritishjim 7y ago

> Personally, I think what C++ offers is the same as Rust. I think this dismisses incidental complexity that can certainly exist in general, and certainly does exist in C++. Just look at how complex move semantics are in C++: * you have & and && references, * there are all sorts of categories (e.g. glvalues), * in a template && means something different (but not always), * std::move by itself doesn't actually do anything (yes I know it's a cast but this is still confusing at least upfront), * even if you do pass the result of std::move (or otherwisie know you have an rvalue reference) to a constructor then it's still possible that the object will actually be copied with no error or even warning. In Rust, the difference is enormous: * When you move from a value, it's guaranteed that the old object's destructor will not be called, so you don't need a move constructor that hackily sets up an empty value so is destructor won't do anything; * Move is always a bitwise copy so it's easier for the caller to understand and free for the implementor to implement (this is enabled by the previous point) * Move is the default instead of copy which makes a million times more sense because you can just implement copy as a regular method that happens to return (move!) its result (whereas you could never implement move as something that returns its result by copying) and if you actually want to copy a value to a function you can just call the copy method and move that value to it. This final one is key is really, it's not possible because of C++'s history and backwards-compatibility requirements and that's why it had to come up with the crazy system it now has. Rust has many nice features but really the move vs copy stuff by itself is a huge saving in complexity, and the fact that Rust manages it at all proves that it is not intrinsic to the problem. (Disclaimer: I have worked with C++ on and off full time for more than 15 years, whereas I have only tinkered with Rust.)

pjmlp 7y ago
You forgot about SFINAE, CTAD, decltype vs auto, perfectly forwarding references, guaranteed RVO (but only in certain ISO versions), initialization semantics, ...
- WesternStar 7y ago
  He didn't forget perfectly forwarding references.
  - quietbritishjim 7y ago
    But that does show how confusing the notation is!
    - WesternStar 7y ago
      I guess I watched the back to basics c++ series on move semantics and its not really all that bad. I did struggle with it beforehand though. I've never worked in C++ tbh. I does take the 2 hours but you have it when you're done. https://youtu.be/St0MNEU5b0o https://youtu.be/St0MNEU5b0o
      - quietbritishjim 7y ago
        Really? You can tell off the top of your head what the difference between an xvalue and a glvalue is? Which function has higher precedence in the overload list out of foo(string&) and foo(string&&)? (Note that's not a const string&!) That these are so obvious to you that there's no chance you would make a mistake about them when you're in a hurry trying to solve an actual problem that has its own complexities rather than playing games with C++'s unnecessary complexity? The one where foo(std::move(x)) doesn't necessarily move x is a particular killer (although at least it only causes a performance problem rather than noticable change in behaviour). I have worked with C++ for a hell of a lot more than 2 hours since C++11 came out (the first version with move semantics) and worked with many others that have too, and I can tell you that "once you have it you're done" is just not true. I fully understand all the concepts but I can still make mistakes.

rapsey 7y ago

> I think to get good at a given systems language these days the effort is the same Someone who has been proficient at something for a long time has a very difficult time getting into a mindset of a beginner. This is why I think you are completely wrong about this point. > Rust has some nice-to-haves of course, but C++ has been able to grow up and evolve because of the rich feature-set the template meta-programming language has provided it. C++ has not and can not hide all the hidden gotchas and complexities that it has accrued over the years.

gameswithgo 7y ago

>concurrency still requires the same underlying ideas to be understood whether C++ or Rust But Rust will catch data race mistakes at compile time, which is very nice. That is a common mistake, and a mistake that can keep happening without you being aware for a long time.

pjmlp 7y ago
That is a common misconception. It only applies to threaded code, as soon as IPC, or other kind of external resources enter into the picture there is very little that Rust's type system can do to help with.
- burntsushi 7y ago
  There is zero misconception in the GP. Catching data races in threaded code is extremely valuable, regardless of whether it applies to IPC or not. Why? Because non-IPC multithreaded code is a thing. Libraries like rayon even make this sort of parallelism quite easy. With the help of the Rust compiler, it's all safe too. Just because this doesn't extend to IPC (of course not) doesn't mean there is some kind of misconception here.
  - pjmlp 7y ago
    Misconception is that IPC and external resources is always left out of the message, so anyone without experience in distributed computing assumes guarantees that Rust actually does not provide.
    - burntsushi 7y ago
      That's not a misconception. It's a totally different problem space. > so anyone without experience in distributed computing assumes guarantees that Rust actually does not provide. [citation needed]
- hechang1997 7y ago
  I don't think you can have shared IPC memory in rust. You have to use message passing. Of course you are on your own completely, and there will be weird logic bugs when you mess it up. However, there won't be any memory corruptions.

zamalek 7y ago

> Personally, I think what C++ offers is the same as Rust. I see this pretty often and don't understand where this idea originates from. We have huge amounts of evidence to the contrary[1], that is generated by developers who likely have more experience with parallelism and memory than anyone in this comments section ("likely"). If the ultimate pedigree don't get it right, keeping in mind that they never have (apart from NASA who disallow threading and allocation), how is there this belief that it is at all possible. It's the software equivalent of flat-earthing or climate change denial. We have abundant hard evidence supporting the inability for humans to reason about memory allocation, and absolutely zero evidence to the contrary. Safe Rust eliminates entire categories of bugs. It doesn't eliminate all bugs (including vulnerabilities), so you do need testing, but it does a huge amount more than nothing (C++). [1]: https://cve.mitre.org/ https://cve.mitre.org/