[dannymi]

To expand:

There's a prioritized list of requirements in engineering. Use the right tool for the job.

Rust has: (see https://hackmd.io/@rust-ctcft/r1plN4You#/5 )

1. Safety

If you don't need that at the first slot, then the biggest strength of Rust doesn't apply to your problem (and you would waste time having to track lifetime parameters more than necessary to solve your problem).

[estebank]

There's also another item in that list, and that is performance. As soon as you slightly relax that one, Rust does become massively easier. A well placed .clone() or Arc makes the rest of the code performant enough and easier to understand, which makes the equation of choosing Rust over other alternatives in spaces that aren't necessarily systems programming less problematic.

[ncmncm]

Arc is equivalent to std::shared_ptr, and so ought to be code smell in Rust.

The .clone() would have been [=] in C++, which would have safely quieted the warning.

[pdimitar]

Big problem in these discussions is what should be prioritized.

To me, with the 20 years of experience I have in 8 programming languages, I'll always include safety. Especially having in mind that it's nearly zero-cost in terms of runtime performance.

So to me not choosing safety is a strong sign that I don't want to work with the people who practice that.

[ncmncm]

The point missed everywhere is that Rust lacks key language features needed to capture essential semantics in libraries, that C++ provides. To code libraries I want to code, I cannot use Rust. Rust cannot express them.

So, safety, good, fast enough, good, but insufficiently expressive? No, thank you.

[pdimitar]

It's probably missed everywhere because I at least have not seen anyone giving concrete info about which are these missing key language features.

Want to elaborate on that? Quite curious.

[rmadriz]

can you elaborate on those key missing language features ? You have commented multiple times about that, but haven't seen you giving any concrete example. I'm Genuinely curious.

[ncmncm]

Where to begin? Operator overloading. Programmed move semantics. Generics argument concepts. Look at the whole list of features C++ got since C++11, and subtract out the few of those Rust had or got.

[dannymi]

I've done a toy matrix library with operator overloading in Rust a while ago. Could you be confusing it with Java?

  #[derive(Debug, PartialEq, Eq)]
  pub struct ColumnVector<F, const DIM: usize>([F; DIM]);

  impl<F: Field, const DIM: usize> Add<Self> for ColumnVector<F, DIM> {
      type Output = ColumnVector<F, DIM>;
      fn add(self, rhs: Self) -> Self::Output {
          Self::new(self.0.zip(rhs.0).map(|(a,b)| a + b))
      }
  }

Usage:

  let v = ColumnVector::new([1.0,
                             3.0,
                             4.0]);
  let w = ColumnVector::new([1.0,
                             0.0,
                             4.0]);
  assert_eq!(v + w, ColumnVector::new([2.0,
                                       3.0,
                                       8.0]));

[pdimitar]

> Where to begin?

I propose you start with genuinely concerning problems. Operator overloading is a first-world problem and I've made a good career never depending on it (outside of my active C/C++ years at the start of it).

"Generics argument concepts" says exactly nothing, to me at least. Elaborate?

"Programmed move semantics" is, if I understand you correctly, a flavor / taste thing but I can agree it can be made better and more explicit -- say by not using the `=` operator for it. That I could stand behind. Still, it's only catching you off-guard while you're learning. 50/50 though. It's a concern but IMO not a major one.

And your final sentence betrays bias to C++. Well fine, use that, nobody is forcing you to work with Rust, right?

But if you're willing to bash Rust, please do so with concrete arguments. If you know something negative about it that I don't, I believe I and many others will benefit from informed objective criticism.

Do you have that? Already asked you in another comment and I'm still willing to listen to it.