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.
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.
foo->bar.baz
foo.bar.baz
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 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 :)
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.
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.
epage•1mo ago
Would love built in coverage support but investigation is needed on the design (https://github.com/rust-lang/cargo/issues/13040) and we likely need to redo how we handle doctests (https://blog.rust-lang.org/inside-rust/2025/10/01/this-devel...).
quadrophenia•1mo ago