5 ms·

I am not going to be surprised to be downvoted, but you don't need shared_ptr in C++, that is itself overkill The point of C++ is performance. If you don't ne

I am not going to be surprised to be downvoted, but you don't need shared_ptr in C++, that is itself overkill The point of C++ is performance. If you don't need performance, why not just use Java or Python, why use Rust?

saghm 3y ago
> The point of C++ is performance. If you don't need performance, why not just use Java or Python, why use Rust? As a counterpoint, I also don't need to use `Rc` or `Arc` in Rust, and I can get by without reference counting. Why use C++?
shikon7 3y ago
You use Rust if you want performance (especially because there is no garbage collection), and strong safety guarantees. If you don’t care about safety guarantees and abstractions like shared_ptr, you might just as well use C instead of C++.
nickysielicki 3y ago
The point of a program is first and foremost to be correct, performance is never more important than that. /dev/null is not in fact webscale.
brigadier132 3y ago
You don't need performance until you do. Writing slow rust in my experience is just as easy as writing python. If not easier because the libraries are better designed.
bluGill 3y ago
The point of rust is you get the performance of C++ with additional safety.
- Const-me 3y ago
  For example, safe rust forbids code which writes to different elements of the same vector from different CPU cores. C++ compiler has no objections, and doing that is often the best way to parallelize computations.
  - glandium 3y ago
    > safe rust forbids code which writes to different elements of the same vector from different CPU cores. It doesn't (see e.g. slice::split_at_mut). It however doesn't allow you to do that and mutate the vector at the same time.
    - Const-me 3y ago
      Different elements of the output vector may take very different time to compute. If you do parallelization with split_at_mut API, you won’t be able to saturate all cores because the thread who does the splitting can’t possibly know how much time each slice going to take.
      - estebank 3y ago
        https://github.com/rayon-rs/rayon https://github.com/rayon-rs/rayon
        Const-me 3y ago
        Sometimes you don’t want libraries, instead you want to implement similar stuff in your own code. And Rayon uses unsafe to workround the compiler limitation of the safe rust I was talking about. Also, it seems Rayon is substantially slower than C++ OpenMP https://www.reddit.com/r/rust/comments/brre8o/a_scaling_comparison_of_rust_rayon_and_c_and/ https://www.reddit.com/r/rust/comments/brre8o/a_scaling_comp...
        tialaramex 3y ago
        This is probably a better link: https://www.reddit.com/r/rust/comments/bto10h/update_a_scaling_comparison_between_rustrayon_and/ https://www.reddit.com/r/rust/comments/bto10h/update_a_scali... The poster has figured out a significant performance leak, their Y-axis is no longer nonsense, and they've got a peak indication so that we know the theoretical best possible numbers (no practical software will get there but indeed OpenMP is closer than Rayon)
dureuill 3y ago
"performance" is about profiling and avoiding bottlenecks. That I'm using reference counting on the error path of my parser (so there's something wrong with the input and the task is not going to complete) is very unlikely to become a bottleneck. You may have a point in that I navigated codebases that were plagued with shared ptrs everywhere in the past, and that general style of programming is not going to yield good performance. But you shouldn't deal in absolutes.

saghm 3y ago

> The point of C++ is performance. If you don't need performance, why not just use Java or Python, why use Rust? As a counterpoint, I also don't need to use `Rc` or `Arc` in Rust, and I can get by without reference counting. Why use C++?

shikon7 3y ago

You use Rust if you want performance (especially because there is no garbage collection), and strong safety guarantees. If you don’t care about safety guarantees and abstractions like shared_ptr, you might just as well use C instead of C++.

nickysielicki 3y ago

The point of a program is first and foremost to be correct, performance is never more important than that. /dev/null is not in fact webscale.

brigadier132 3y ago

You don't need performance until you do. Writing slow rust in my experience is just as easy as writing python. If not easier because the libraries are better designed.

bluGill 3y ago

The point of rust is you get the performance of C++ with additional safety.

Const-me 3y ago
For example, safe rust forbids code which writes to different elements of the same vector from different CPU cores. C++ compiler has no objections, and doing that is often the best way to parallelize computations.
- glandium 3y ago
  > safe rust forbids code which writes to different elements of the same vector from different CPU cores. It doesn't (see e.g. slice::split_at_mut). It however doesn't allow you to do that and mutate the vector at the same time.
  - Const-me 3y ago
    Different elements of the output vector may take very different time to compute. If you do parallelization with split_at_mut API, you won’t be able to saturate all cores because the thread who does the splitting can’t possibly know how much time each slice going to take.
    - estebank 3y ago
      https://github.com/rayon-rs/rayon https://github.com/rayon-rs/rayon
      - Const-me 3y ago
        Sometimes you don’t want libraries, instead you want to implement similar stuff in your own code. And Rayon uses unsafe to workround the compiler limitation of the safe rust I was talking about. Also, it seems Rayon is substantially slower than C++ OpenMP https://www.reddit.com/r/rust/comments/brre8o/a_scaling_comparison_of_rust_rayon_and_c_and/ https://www.reddit.com/r/rust/comments/brre8o/a_scaling_comp...
        tialaramex 3y ago
        This is probably a better link: https://www.reddit.com/r/rust/comments/bto10h/update_a_scaling_comparison_between_rustrayon_and/ https://www.reddit.com/r/rust/comments/bto10h/update_a_scali... The poster has figured out a significant performance leak, their Y-axis is no longer nonsense, and they've got a peak indication so that we know the theoretical best possible numbers (no practical software will get there but indeed OpenMP is closer than Rayon)

dureuill 3y ago

"performance" is about profiling and avoiding bottlenecks. That I'm using reference counting on the error path of my parser (so there's something wrong with the input and the task is not going to complete) is very unlikely to become a bottleneck. You may have a point in that I navigated codebases that were plagued with shared ptrs everywhere in the past, and that general style of programming is not going to yield good performance. But you shouldn't deal in absolutes.