Visualizing Rust's Vtables: How dyn Trait Works In Memory
torutofu
155 points
28 comments
September 05, 2026
Related Discussions
Found 5 related stories in 53.6ms across 5,634 title embeddings via pgvector HNSW
- Scaling Memory Safety: AI-Assisted Rewrites of C/C++ Dependencies to Rust afdbcreid · 15 pts · August 24, 2026 · 49% similar
- Functional State Machines in Rust: Typestate and Newtype Patterns matt_d · 72 pts · August 29, 2026 · 47% similar
- Rust Glancer surprisetalk · 30 pts · August 21, 2026 · 47% similar
- How Our Rust-to-Zig Rewrite Is Going jorangreef · 467 pts · July 16, 2026 · 46% similar
- Bun 1.4 Rust rewrite is not looking good? tipiirai · 136 pts · August 19, 2026 · 46% similar
Discussion Highlights (8 comments)
ketzu
> In Rust, that question is answered by the borrow-checker at compile time: (About zero sized objects being the same) But why does that mean the programmer never has to check? (or if they want that information from the borrow checker how would they get it?) It's not motivated as the intro above for c++ was just "In C++, we might do this to check if two pointers refer to the same object". So the borrow checker knows already, why does that stop the programmer from wanting to know or separate these cases?
returningfory2
Very nice. As a follow up would be interesting to also reverse engineer the structure of the vtable itself. I guess it’s a list of pointers to the method implementations?
tialaramex
This has a section on Object Safety, I checked and the article was written this week, but "Object Safety" is a confusing name for this idea, and so for a little while now Rust calls this idea "dyn compatibility" because the most important thing you're getting if a trait is "dyn compatible" is that you can use "dyn Trait" - https://doc.rust-lang.org/1.98.1/reference/items/traits.html... That link more comprehensively explains the rules too. [Edit: Realized the end of the article explains this, the author began writing it months ago, likely before they read about the improved "dyn compatibility" naming]
Waterluvian
I never did well in English and I usually don’t know it when I see it. But it was immediately evident that the writing style of this blog was sparking joy. Even the intro section was just so well structured that I had to read it again.
7e
The title includes the word “visualizing” but there is not a single diagram in this article. Is English not the first language of the author?
evmar
In my own journey of discovery I found https://cheats.rs/ very helpful, and in particular its "memory layout" section has visualizations. (No affiliation with the site, just a happy reader!)
Panzerschrek
I once faced a tricky bug involving fat pointers (containing virtual tables) in Rust. Two such pointers may be distinct, even if they reference to the same object, because (for some reason) the compiler may create two (or even more) copies of the virtual functions table and use them in different places.
Panzerschrek
> A trait must follow so-called object safety rules to be used as a trait object This seems for me to be a major design flaw of Rust. It tries to repurpose traits for dynamic polymorphism, even if this doesn't fit perfectly. C++ is more honest, it has two separate mechanisms for static polymorphism (templates) and dynamic polymorphism (inheritance).