5 ms·

Out of curiosity I implemented the two examples in C++11. For the number add I used a unique_ptr (although returning by value would be better in every way). F

by blub 12y ago

Out of curiosity I implemented the two examples in C++11. For the number add I used a unique_ptr (although returning by value would be better in every way). For the shared state I used async with a lamba that calls transform and returns the modified vector through a future. This doesn't execute in parallel for each for loop though. I think something like Arc can be coded in C++ too - template wrapper that returns a RAII lock whick unlocks on scope end. I think the only big difference is that some errors in Rust are happening at compile time. In the first case the original buggy code was triggering only a warning in C++. Right now the extra compile-safety of Rust is IMO not worth giving up the other benefits of C++, especially now that C++11 with some extra static checking and good guidelines can go a long way.

steveklabnik 12y ago
Box<T> is roughly equivalent to unique_ptr, and you're correct, returning by value would be better. Rust idiom is to use stack allocation and borrowing wherever possible. > I think the only big difference is that some errors in Rust are happening at compile time. This is true in these examples, except maybe the enforcement of not using a pointer after you've sent it to a task. That said, there are other examples, like iterator invalidation, where Rust is completely memory safe, unlike C++. Furthermore, Rust has significantly less undefined behavior and odd edge cases. These are in C++ for good reason, but they're still there. > with some extra static checking and good guidelines can go a long way. They can go a long way, and that may be enough for you. Big applications continue to have security issues due to problems that Rust would prevent, though: in the last Pwn2Own, all of Firefox's bugs would not have been possible in Rust, for example.
- blub 12y ago
  Thanks for the details. In all honesty I am probably not a target for Rust anyway, I almost never use C++ for systems programming, but rather for (cross-platform) application development. It would seem that neither Rust nor Go serve this area and probably do not intend to do it either.
  - steveklabnik 12y ago
    Could you expand on why? I ask because the largest test case for Rust, Servo, is a cross-platform application, and I'm always looking to improve our marketing.
    - sanderjd 12y ago
      As someone who has researched using Rust for a cross-platform GUI application and looked at Servo for ideas of how to do so, I think the libraries for the GUI layer are still very immature. Servo is mostly a rendering engine that draws its final product directly to a canvas, which is great for the content area of a browser window, but different than what most GUI applications need. (Definitely interested in being corrected by the far more knowledgeable Servo developers here.) Having said that, immature libraries are to be expected at this point, and I do think Rust is very well positioned to have really good ones for this use case in the short to medium term.
      - steveklabnik 12y ago
        > the libraries for the GUI layer are still very immature. This is absolutely true, but that's a different concern than "It would seem that neither Rust nor Go serve this area and probably do not intend to do it either," which is what I'm curious about. One of the open questions with GUI toolkit stuff is that Rust does not have named parameters, but Qt, for example, uses them heavily.
        McP 12y ago
        I'm glad you mention Qt. Qt bindings are an absolute necessity before my company (which also makes cross-platform applications) could consider adopting Rust.
        steveklabnik 12y ago
        There are several people working on it. I'm not sure what the current state is, but I know that mapping was one of the big issues.
pcwalton 12y ago
> Right now the extra compile-safety of Rust is IMO not worth giving up the other benefits of C++ I can't speak to everyone's use case, but for ours memory safety is extremely important. C++ is not safe, and we still see tons of memory safety issues, many security-sensitive, in practice, despite using modern C++ for all new code. Even if safety isn't as important to you, there are other reasons you might be interested in Rust: a module system, pattern matching, a standard library which offers better performance than STL for many tasks, ADTs, concepts, a package manager, etc.
- Donwangugi 12y ago
  What kind of issues do you see still with modern C++11 code?
  - pcwalton 12y ago
    All kinds of memory safety issues. Heap use-after-free is very common. You can go to Bugzilla and search for sec-critical to get a list of the ones Mozilla has disclosed.
- Scramblejams 12y ago
  I get the feeling most of these commenters who think the words "modern C++" indicate some kind of near insulation from writing security bugs are, in fact, writing security bugs. They probably think they aren't, but by definition, we are not smart enough to immediately understand the bugs we write. Otherwise we wouldn't write them. But hey, it's not like a programmer who overestimates his own skills is a new thing.
- Dewie 12y ago
  > concepts What are concepts in this context? It is hard to google.
  - steveklabnik 12y ago
    http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29 http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29

by blub 12y ago

steveklabnik 12y ago

Box<T> is roughly equivalent to unique_ptr, and you're correct, returning by value would be better. Rust idiom is to use stack allocation and borrowing wherever possible. > I think the only big difference is that some errors in Rust are happening at compile time. This is true in these examples, except maybe the enforcement of not using a pointer after you've sent it to a task. That said, there are other examples, like iterator invalidation, where Rust is completely memory safe, unlike C++. Furthermore, Rust has significantly less undefined behavior and odd edge cases. These are in C++ for good reason, but they're still there. > with some extra static checking and good guidelines can go a long way. They can go a long way, and that may be enough for you. Big applications continue to have security issues due to problems that Rust would prevent, though: in the last Pwn2Own, all of Firefox's bugs would not have been possible in Rust, for example.

blub 12y ago
Thanks for the details. In all honesty I am probably not a target for Rust anyway, I almost never use C++ for systems programming, but rather for (cross-platform) application development. It would seem that neither Rust nor Go serve this area and probably do not intend to do it either.
- steveklabnik 12y ago
  Could you expand on why? I ask because the largest test case for Rust, Servo, is a cross-platform application, and I'm always looking to improve our marketing.
  - sanderjd 12y ago
    As someone who has researched using Rust for a cross-platform GUI application and looked at Servo for ideas of how to do so, I think the libraries for the GUI layer are still very immature. Servo is mostly a rendering engine that draws its final product directly to a canvas, which is great for the content area of a browser window, but different than what most GUI applications need. (Definitely interested in being corrected by the far more knowledgeable Servo developers here.) Having said that, immature libraries are to be expected at this point, and I do think Rust is very well positioned to have really good ones for this use case in the short to medium term.
    - steveklabnik 12y ago
      > the libraries for the GUI layer are still very immature. This is absolutely true, but that's a different concern than "It would seem that neither Rust nor Go serve this area and probably do not intend to do it either," which is what I'm curious about. One of the open questions with GUI toolkit stuff is that Rust does not have named parameters, but Qt, for example, uses them heavily.
      - McP 12y ago
        I'm glad you mention Qt. Qt bindings are an absolute necessity before my company (which also makes cross-platform applications) could consider adopting Rust.
        steveklabnik 12y ago
        There are several people working on it. I'm not sure what the current state is, but I know that mapping was one of the big issues.

pcwalton 12y ago

> Right now the extra compile-safety of Rust is IMO not worth giving up the other benefits of C++ I can't speak to everyone's use case, but for ours memory safety is extremely important. C++ is not safe, and we still see tons of memory safety issues, many security-sensitive, in practice, despite using modern C++ for all new code. Even if safety isn't as important to you, there are other reasons you might be interested in Rust: a module system, pattern matching, a standard library which offers better performance than STL for many tasks, ADTs, concepts, a package manager, etc.

Donwangugi 12y ago
What kind of issues do you see still with modern C++11 code?
- pcwalton 12y ago
  All kinds of memory safety issues. Heap use-after-free is very common. You can go to Bugzilla and search for sec-critical to get a list of the ones Mozilla has disclosed.
Scramblejams 12y ago
I get the feeling most of these commenters who think the words "modern C++" indicate some kind of near insulation from writing security bugs are, in fact, writing security bugs. They probably think they aren't, but by definition, we are not smart enough to immediately understand the bugs we write. Otherwise we wouldn't write them. But hey, it's not like a programmer who overestimates his own skills is a new thing.
Dewie 12y ago
> concepts What are concepts in this context? It is hard to google.
- steveklabnik 12y ago
  http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29 http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29