> I sometimes feel C and C++ were very clear on where data lives (stack vs heap) and how it’s organized (struct alignment), while Rust seems a little more opaque . I’ve felt a similar way working in Go.<p>This is interesting to me. I fully agree about this with Go (and in the past I've sometimes seen this make optimizations difficult as in practice it's hard to keep track of heap allocations other than runtime inspection), but I feel like Rust is actually better at C++ than this. Alignment is certainly a different beast, as by default I don't think you can really assume anything about how Rust will lay out a struct (with the workarounds being various `repr` attributes), but in terms of heap allocations, I'd argue there isn't anything as ambiguous as a raw C++ pointer. If you're able to get away with smart pointers all of the time, I could see this being less of an issue, but from my somewhat limited experience with C++ there seem to often be cases where APIs still expect raw pointers from time to time, so I wouldn't expect to be able to look at some random function call in a call graph and know what type of memory it's dealing with in the absence of documentation or runtime inspection.<p>In Rust, it's a `Box<T>`, `Rc<T>`, `Arc<T>`, `Vec<T>`, or `String`, it's on the heap. If it's not, chances are it's on the stack. There are separate types for the non-owning versions of those types for references (`&T`), slices (`&[T]`), and string references (`&str)`, none of which require heap allocations to create (although they might indirectly refer to heap-allocated data in one of the other types mentioned before). There are probably other types that one might run into that are heap-allocated, but even when dealing with something like indirection from dynamic dispatch, any heap allocations needed to make things work will end up being explicit via something like `Box` or `Arc`. I might just be misunderstanding the point being made here; maybe the author was looking for documentation rather than relying on the types themselves, or maybe they had reason to be concerned about whether the type behind a reference or slice happened to be heap allocated or not, but in my experience, only needing to care about that in the context of when explicitly making a new allocation is a benefit, not a drawback.
In C++, in particular when restricting to a C like subset, I prefer looking at an expression like<p><pre><code> foo->bar.baz
</code></pre>
instead of (in Rust and other modern languages that decided to get rid of the distinction)<p><pre><code> foo.bar.baz
</code></pre>
For example, the former lets me easily see that I can copy <i>foo->bar</i> and I now have a copy of <i>baz</i> (and indeed <i>bar</i>). In a newer language, it's harder to see whether we are copying a value or a reference.
I see what you're saying but I'd argue that this is mostly an unnecessary thing to worry about because with the exception of types explicitly opted into being cheaply copyable, you're going to be moving it if you're not accessing it via a reference. The idea is that if you're worried about expensive copies, it shouldn't be possible to copy implicitly in the first place; you'd either explicitly `clone` or you wouldn't be copying it at all.
I'm not worried about expensive copies. I'm worried about being able to understand my systems code. The solution isn't adding more abstractions (like move semantics on top). I don't want to move anything. I want to be clear about taking a reference or making an actual copy, these are deeply, semantically, different. This difference is important for single threaded code but also for concurrency -- not only with mutable data types but also with immutable ones.<p>Performance is mostly a consequence of clear and direct code. You mostly don't achieve performance by saving individual copies, but by being in control of the code and architecture.
I don't think your run often into these things, because of Rust's ownership enforcement. But I might be misunderstanding you, because it's all pretty abstract and I might not have the whole context.
OP here - thank you for your explanations! My writing got a little messy in this section, but I think my intended focus here was on struct alignment. I've only had to care about alignment in some very niche cases dealing with C, so I don't think it's something that'll come up in my typical non-high performance software work. I agree that `repr` would likely be the way to go.<p>I do appreciate that the act of copying or allocating something nontrivial in Rust requires verbosity. Your list of typical heap containers is great and I'll do my best to internalize that. I'd just add that some primitives like sync::Mutex [1] in Rust's standard library (which to my knowledge don't exist in the same flavor in C++'s STL) require some additional gymnastics to wrap my head around. The wrapper is super useful though :)<p>[1] <a href="https://doc.rust-lang.org/std/sync/struct.Mutex.html" rel="nofollow">https://doc.rust-lang.org/std/sync/struct.Mutex.html</a>
Is the following accurate? “If a type has a generic bound T: ?Sized, then its data lives on the heap.” (Except for &T because it's the one type that doesn't take ownership of its T upon construction.)
There are no types whose fields "live on the heap", nor are there types whose fields "live on the stack"; these are simply not properties of types. Values always live exactly where you put them and you can put values anywhere you want, thanks to Rust's "all types are moveable" rule. Now something like a `Vec` or a `Box` _owns_ some data strictly on the heap, but that data is not _part of_ (i.e. a field of) the `Vec` or `Box` value.<p>As a counter-example to your idea, it's theoretically possible for a type to have a `?Sized` field (at the end), although this idea was never completely fleshed out in the language. A value of such a type could be constructed on the stack.<p>Now in practice, if you encounter a type with an unsized type parameter, it's probably a smart pointer. It may have an ownership relation to some data which lives on the heap. That may be what you're referring to. But such heuristics are going to be more confusing than helpful for anyone who doesn't understand the basic premise. The location of data in rust is actually quite simple, but sometimes beginners make it more complicated than it really is somehow.