Huh. I expected two main advantages on Rust's side: usable multithreading (as mentioned) and stack allocation. For the latter, the ownership model makes it possible to stack-allocate things that you wouldn't dare put on the stack in either C or C++, thus saving malloc and free time as well as second-order effects from avoiding fragmentation.

Does Rust not do this for subtle reasons that I'm missing, or does it just not matter as much as I'd expect it to?

▲

steveklabnik 11 hours ago | parent [-]

Both of those things are important, sure. I wanted this post to be talking about the higher level conceptual question, and then using interesting examples to tease out various aspects of that discussion, more than "here's what I think are the biggest differences between the two."

I think these two things are also things people would argue about a lot. It's hard to talk about them in a concrete sense of things, rather than just "I feel like code usually does X".

▲

sfink 11 hours ago | parent [-]

Right, sorry, I didn't mean to imply that you should have covered stack allocation in your post. I think your post covers the right material to make its point.

This is more of a side comment about a different question, perhaps "ok fine, but then what are the language differences that could be performance-relevant for one language or the other, even if (as you say) they don't lead to a yes/no answer for your original question?"

	▲	steveklabnik 10 hours ago \| parent [-]
		The ones I think, personally: 1. crates.io makes it easy to use complex data structures. Basically this argument https://bcantrill.dtrace.org/2018/09/28/the-relative-perform... 2. Rust's safety guarantees making it easier to maintain more dangerous things over time. 3. On the C side, there's a lot more cultural understanding overall of how to use the language to get good performance results 4. It might be easier to find people who are experienced in heavily optimizing C code as opposed to Rust code.