[pclmulqdq]

Yes. Most of the production use cases for Rust are aimed at C, C++, and Go users. In my past experience, even poorly-written Go tends to outperform poorly-written Rust for many tasks, not to mention C or C++.

You're not exactly the target market if you're writing python.

[fbdab103]

But that is kind of my point. There are plenty of reasons to use Rust that have nothing to do with performance. My brief toe-dip into the Rust world loves the static types, good dependency management, and single executable deployment. That it is faster than my standard language is just the cherry on top.

[mplanchard]

Yeah, Rust is a really fun language to write in my opinion. If your use-cases are tolerant of non-hyper-optimized Rust, there’s no reason to make it too hard on yourself while you’re learning. As you use it, I think you’ll naturally gravitate towards writing more optimized code, because the language guides you in that direction.

[pclmulqdq]

The unfortunate reality for many Rust fans is that a lot of people would prefer to use a less complicated language when performance doesn't matter.

That Rust program you spent a day golfing to make beautiful use of iterators? Your friend wrote it in go in 15 minutes.

They also get static types, good dependency management, and singe executable deployment. Cython + mypy basically gives you that with Python.

[mplanchard]

I don’t know why this would be an unfortunate reality. People should use whatever language they want.

Rust gives you a lot of ways to express yourself, but now that I am quite familiar with it, I can write Rust just as quickly as I can write Python or Go.

You can spend all day code golfing in any language.

[mplanchard]

This conversation was about learning Rust, not about writing maximally optimized Rust. Clones and Arcs can make learning a lot easier, since they let you get stuff done without needing to figure out every obscure lifetime error.

For production contexts, we take more care to optimize for performance.

[pclmulqdq]

You and I have very different definitions of "maximally optimized." I think of eliminating all possible wasted CPU cycles when I hear those words. In comparison, being able to remove spurious copies and atomic accesses is table stakes for claiming that you know a systems programming language. Most use cases of C and C++ today are in that state.

[kaba0]

Well, clones can sometimes make it faster (e.g. when you use multiple threads that can work independently, synchronization will have a much higher overhead than a literally insanely fast, predictable memory-to-memory copy). And then the compiler may very well be able to elide the copy, it only needs it for semantics.

[mplanchard]

You’re right, I was exaggerating for effect. But the point is that we’re talking about learning the language. You don’t have to get it perfect on your first try or do everything the best way when you’re just getting started.