TokioConf talk explores cyclic pointers, safe GC, and Rust VM design

Rust is being asked to do something that once looked off-limits

A TokioConf talk is turning heads by pushing safe Rust into territory most people still associate with garbage-collected languages and VM runtimes. The pitch is not theoretical flair for its own sake: it centers on cyclic pointers, safe garbage collection, and a design for Rust virtual machines that can power real production systems without abandoning Rust’s safety model.

That is exactly why the talk stands out at the first-ever TokioConf, the single-track conference in Portland, Oregon, built for developers shipping asynchronous network applications in Rust. Tokio has made clear this gathering is aimed at people using Tokio in production, which gives the whole event a practical edge: this is not a purity contest, it is a forum for the hard problems that appear once Rust is already in service.

Why TokioConf matters to the production Rust crowd

TokioConf was scheduled for April 20-22, 2026 at the Hyatt Regency Portland, and the program was designed around the realities of production async Rust. The organizers emphasized topics such as debugging async code, instrumenting live systems, performance patterns, architectural decisions, and cancellation semantics. Lightning talks, a Monday workshop, and social events were all part of the plan, reinforcing that the conference was meant to be hands-on and relationship-driven as much as technical.

The event also drew strong demand early. When the program announcement went out on January 12, 2026, Tokio said fewer than 200 tickets remained. That kind of response matters because it signals a shared pressure point in the ecosystem: the Rust community is no longer only asking how to write async services, but how to operate them well and evolve them safely.

The talk’s real hook: bringing GC ideas into safe Rust

The April 22 blog post tied to the talk describes a speaker who had spent the previous few months working with Kong, one of TokioConf’s sponsors, on small, isolated, safe Rust VMs for Kong’s networking rules engine. That detail is the key to understanding why the talk is so unusual. It is not a generic exploration of language theory; it is grounded in a concrete runtime problem where isolation, safety, and performance all have to coexist.

The talk frames its ambition in unusually bold terms: two especially aggressive goals are “totally zero-cost pointers” and usability from completely safe Rust. Those goals point toward a deeper challenge in systems design. If Rust can host runtime machinery that feels as cheap as ordinary pointers while still staying within safe code, then the language becomes a much more plausible home for interpreters, rule engines, and managed runtime components that were once assumed to require a garbage collector in the traditional sense.

Cyclic pointers are the crack in Rust’s usual story

The speaker’s framing is blunt: Rust is strong at Vec-based patterns but comparatively weak at safe circular references. That tension is familiar to anyone building nontrivial object graphs, interpreters, or graph-like runtime structures. Flat data and linear ownership are where Rust shines; cyclic structures are where developers often start reaching for reference counting, interior mutability, or unsafe escape hatches.

This is why cyclic pointers are such an important part of the story. Once a runtime needs self-referential graphs, back edges, or objects that outlive the stack of the code creating them, the ordinary ownership model gets strained. The talk’s value lies in showing that Rust can still remain safe in that territory, provided the runtime machinery is designed carefully enough.

What “safe GC” and “zero-cost GC pointers” could change

The talk also dives into integrating tracing garbage collection into safe Rust, which is a radical idea for many Rust users because GC is often treated as the opposite of explicit ownership. But the point here is not to recreate a conventional managed language runtime in disguise. The point is to ask whether tracing, reachability, and lifetime reasoning can be made to work in a way that preserves Rust’s guarantees while reducing the cost of moving between safe Rust code and managed runtime structures.

That is where the phrases “zero-cost pointers” and safe Rust become so provocative. If a GC pointer can behave like an ordinary pointer from the caller’s point of view, then the boundary between native Rust code and runtime-managed objects becomes far thinner. For interpreters, scripting engines, and rules systems, that means less friction, fewer wrapper layers, and potentially better performance without giving up safety.

The technical ingredients: generativity, reachability, and raw-pointer GC

The talk is not just making a slogan-level claim. It is set to cover generativity and for<'a>, reachability and tracing, and a sketch of a real raw-pointer-based GC. Those topics point to the actual machinery needed to make the idea viable.

Generativity and higher-ranked lifetimes are part of how Rust can express constrained borrowing patterns that are hard to fake with ordinary types. Reachability and tracing are the foundations of garbage collection itself, because any safe GC model still has to know what is live and what can be reclaimed. The raw-pointer-based sketch is especially interesting because it suggests the runtime may still need a low-level core, but one that is carefully hidden behind safe interfaces for the rest of the system.

Why Kong’s rules engine makes this more than a language stunt

Kong’s networking rules engine gives the talk a real-world edge. Rules engines sit in a strange but important corner of infrastructure: they need configurability, fast evaluation, and isolation, and they often become the place where language runtime choices show their teeth. A safe Rust VM for that kind of workload suggests a future where Rust is not just the language around the runtime, but the language inside the runtime.

That has implications for tooling too. If these patterns mature, Rust developers could see better building blocks for embedded scripting, policy engines, interpreter cores, and other runtime-heavy systems that need both strong safety guarantees and high throughput. It also suggests a path for more maintainable infrastructure, where production lessons can move from one team to another without relying on GitHub issues and scattered tribal knowledge.

The bigger TokioConf message: production lessons belong in the room

TokioConf’s organizers have stressed that the event exists partly to bring users and maintainers together in the same room so they can exchange hard-won production lessons and build relationships beyond issue trackers. That philosophy fits this talk perfectly. The audience is not being asked to marvel at an abstract research prototype; it is being shown how far safe Rust can be pushed when the problem is real and the runtime constraints are unforgiving.

That is the frontier story here. Rust is no longer only proving itself in the parts of systems programming that are easy to picture. At TokioConf, it is being pressed into the parts people used to assume belonged to garbage collectors, VM runtimes, and special-purpose language platforms. If safe Rust can grow cyclic pointers, tracing GC, and zero-cost managed references without losing its core guarantees, the next wave of interpreters and high-performance runtimes may look far more Rust-native than anyone expected.