RustChinaConf 2026: I Didn't Expect to Have This Much Fun

On October 16 and 17, I went to Shenzhen for RustChinaConf 2026 & GOSIM Shenzhen 2026.

Before going, I thought it would simply be two days of technical talks. Instead, I've spent the days since getting back looking through photos, reading everyone's posts, and thinking about the conversations we had.

So, while it's all still fresh, here's what happened.

1It Started with My Last Day of Annual Leave

I first heard about the conference from a friend with more experience in the industry. I looked through the schedule: Rust, AI, programming languages, developer tools… There was plenty that interested me, so I decided to go in person.

The catch was that the first day fell on a Friday. So I used my last remaining day of annual leave for the year.

In the days beforehand, I tried to get as much work done in advance as possible. I normally finish at 6:30 p.m., but that week I often worked until ten, sometimes even past midnight. When Friday morning finally arrived, I set off from Pinghu and spent about two hours on the metro getting to Shekou.

It was almost ten by the time I arrived, and the opening session was already underway.

2Day One: Stepping into RustChinaConf

The first talk I caught that morning was Jack Huey's Symposium. It addresses a familiar problem with AI coding: models don't necessarily know your dependencies, internal conventions, or newly introduced APIs, and you can't keep asking them to guess. That struck me as very practical. When I use AI for development, one of my biggest worries is seeing it confidently make changes that make no sense.

Next came a talk on vivo's BlueOS. The team was using Rust for embedded systems and paying close attention to memory use and performance. The speaker also mentioned optimizations involving reference counting and memory layout. Unfortunately, I didn't take notes in time. Looking back now, I'm already hazy on exactly how those optimizations worked.

Then Feihu Tang from Moonshot AI presented an analysis of AI-generated Rust projects, covering benchmarks and the problems AI encounters in real projects. She had an elegant presence and spoke with an easy fluency. I hadn't known of her before, so I looked her up during the talk and discovered that she had worked at Google, won a gold medal at an ACM/ICPC Asia Regional Contest, and taken first place in Microsoft's Beauty of Programming Challenge.¹

I ran into her again outside the conference room. I wanted to say hello, but kept hesitating because I didn't want to take up her time. Only after seeing other people approach her and exchange WeChat contacts did I go over and introduce myself as a game developer. We chatted briefly and added each other on WeChat too.

The lunch buffet was another pleasant surprise. I'd assumed there might not be food, so I'd brought two bread rolls. Instead, there were hot dishes, salads, fruit, and desserts—six kinds of little cakes alone. So much for the bread.

I was more concerned about where to sit, though. I spotted a developer I'd met that morning and joined him to keep talking. He worked on an AI gateway, a very different field from my usual work in game development.

There were three parallel tracks in the afternoon, so I wandered between rooms.

First, I heard a Huawei engineer introduce RustBot, which uses specifications, tests, and reviews to keep AI-generated code quality in check.

Then came Xiaohongshu's QUIC gateway, covering C–Rust interoperability, unsafe code, memory allocation, and seamless hot restarts. I don't know much about network backends, and I couldn't follow many of the implementation details on the spot.

At one point I slipped next door for part of a talk on using AI agents to review Unsafe Rust. Later, I heard about GitMono's Libra, which aims to make version control record an agent's execution process and decisions alongside its code changes.

The talk that really made me want to ask questions, though, was RustScript.

I'd previously built a voxel game with Rust and Bevy, and slow compilation and iteration were my biggest headaches. An embeddable scripting language like RustScript, which can execute at runtime, was appealing: it could potentially speed up iteration and provide a way to support mods.

I'd actually prepared what I wanted to ask: briefly explain my game development background, then ask two questions. Why design a custom bytecode format and virtual machine instead of using WASM? And how far does its hot-reloading support go?

When I raised my hand and started speaking, I was still a little nervous. I got both questions out, but less smoothly than I'd hoped. I also found myself staring at the floor instead of looking at the speaker. After the answer, there were still parts I hadn't fully understood, but I worried that following up would take too much time, so I left it there.

Fortunately, I found the author, Wangchong Zhou (fffonion), afterward and continued the conversation. He mentioned that one advantage of custom bytecode was a smaller footprint. I still wasn't quite clear on why that advantage justified building a separate runtime, though.

At least I expressed myself more clearly that time, and we exchanged WeChat contacts. Next time I ask a question in public, I need to relax a little.

3I Was So Happy That Evening

For the last session of the afternoon, I went to Pipe's talk, “Vue Without JavaScript: Exploring Embedded UI with Rust.” It became one of my favorite talks of the first day.

The talk explored another direction for PocketJS. You can write interfaces in Vue and TypeScript; the usual approach runs them on older devices using a lightweight JavaScript runtime alongside a Rust UI core. But the team is also experimenting with compiling supported UI and logic ahead of time into Rust, so applications can run without carrying a JavaScript engine.²³

Hardware is so powerful now, yet so much software keeps getting bigger and heavier. Here was a team going in the opposite direction, squeezing every last bit of memory and performance out of devices more than twenty years old. Such a niche pursuit, approached with such care.

The numbers make it more tangible. The original PSP has just 32 MB of main memory, with a CPU running at up to 333 MHz. The PocketJS demo kept its application memory budget within 8 MB, including QuickJS, the Rust UI core, textures, and other overhead, while still delivering smooth animation at 60 FPS. That 8 MB is the application's memory budget, not the total memory in the PSP.³

Even more surprising was support for the original Game Boy: a machine with 8 KB of working RAM and 8 KB of video RAM, a CPU clocked at roughly 4.19 MHz, and a screen resolution of just 160 × 144.⁴ The PocketJS team's Pocket Vapor has already compiled a Vue to-do app into a 32 KB Game Boy ROM, with support for adding and deleting tasks, switching filters, and editing text. It uses ahead-of-time compilation, turning components into C and then building a cartridge ROM, without squeezing a JavaScript engine onto the machine.⁵ Making an interactive interface for hardware like that with familiar frontend code is just delightful.

It reminded me of a team lead from an internship I did in Guangzhou. He developed game engines and loved old hardware. His desk had a Subor console and a 3DS, and he'd even written games in BASIC on some truly ancient machines. There was something almost post-apocalyptic about it, as though he were making games with whatever hardware had survived.

Back then, I didn't quite understand why someone would put so much effort into this kind of thing. Only after playing his games myself did I begin to catch his enthusiasm. Listening to Pipe talk about PocketJS brought back that feeling. These were devices most people had long since stopped using, yet the team was still thinking carefully about how to make them run better. I couldn't help admiring them.

After the talk, I saw Pipe talking with a few others, so I stood nearby and listened. When there was an opening, I introduced myself and mentioned the open-source voxel sandbox game I'd built with Rust and Bevy.

To my surprise, she and the others were interested. We even started discussing whether a voxel game could be ported to those older devices. Actually doing it would certainly be difficult, but the thought alone was exciting.

That was how I met PocketJS founder Xuebi, also known as Evan (Yifeng) Wang, along with Pipe and Jimmy.

Later, I asked whether they had any plans for the evening and whether I could join them.

And we really did end up going out for hot pot together!

We talked about so many things that night. A few of the questions are still on my mind.

The first was whether to build my own game engine. I normally develop with Unity, and I'd also built a voxel game in Rust and Bevy. Someone at the table suggested that if the game I wanted to make was unusual enough, while existing engines were designed primarily for general-purpose use, building my own engine might be worth serious consideration instead of continually working around Unity. The idea really struck a chord, but I had doubts too: wouldn't writing an engine from scratch make development much more expensive? We discussed the reasoning and the costs in greater depth that evening, but I'd only gone to bed at three the night before, and I can no longer remember his full argument. For now, I want to keep the suggestion on record.

The second was Three.js, which the same friend also strongly recommended. I'd always associated “running in a browser” with limited performance and assumed it couldn't handle anything too complex. Afterward, I made a point of looking at some Three.js projects and realized I'd underestimated it. Much of the rendering work is done by the GPU; even physics can use Rapier, written in Rust and running in the browser through WebAssembly. Of course, browsers still have CPU, memory, and draw-call bottlenecks, but being browser-based alone isn't a reason to rule something out.

Another idea concerned working with AI: could developers on a team share the conversation histories from their AI sessions? When taking over someone else's work, you'd see more than the final code. You could understand what they'd discussed with the AI, why they'd chosen an approach, and what else they'd tried. I'd mostly treated AI conversations as temporary notes for my own work; I hadn't really considered them as part of a team handoff. Of course, sharing them would also mean handling privacy and sensitive information properly.

We also talked about our projects, programming languages, and past experiences. After dinner, we went to Sea World in Shekou, walked along the waterfront, and took a group photo.

Looking back, what made me happiest wasn't really the food, or even the number of technical topics we covered. It was getting to hear them talk in such an informal setting. They were deeply engaged when discussing their projects and relaxed the rest of the time. I found that ease and grace especially appealing. I loved the atmosphere around them. Just sitting there listening made me happy.

I couldn't help asking quite a few questions myself. Sometimes afterward, I wondered whether I should have spoken less and given them more room to talk about whatever they wanted to discuss with each other. They work together regularly, after all, and a chance to meet in person is rare. But that's only me second-guessing things after the fact.

I'd only planned to attend a talk. I hadn't imagined I'd spend the evening eating with them, walking around, and looking out at the sea. What I find myself missing is simply how it felt to be there with them that night.

I was so happy that evening.

I wrote a separate post, “Why Make Vue Run on a PSP? An Evening with the PocketJS Team”, about PocketJS's technology and some of the stories from that night, so I won't go into them again here.

4Day Two: More to Explore

During the morning panel, “The Next Decade of Rust,” Rust Foundation CEO Rebecca Rumbul repeatedly emphasized that developers and open-source maintainers remain essential even in the age of AI. The panel also mentioned Li Gen (rami3l), who had spoken about rustup the previous day and received funding this year to become a full-time maintainer. Afterward, Guoli Lü from NonConvex Tech presented low-latency techniques used in the Rust asynchronous logging library ftlog.

4.1From Music and Law to Rust

My favorite talk that morning was Hunter Bown's “Rust as an Ecosystem-Builder.”

He's the CEO of Shannon Labs and the creator of the open-source project CodeWhale, but what interested me most was his background. He used to be an orchestra conductor, and he spoke about studying for an MBA and a law degree, a JD. He described himself as a programmer without a traditional computer science background, yet he now develops large Rust projects. That range of experience alone was fascinating.²

He didn't start with Rust. He started with musical notation.

He showed neumes from St. Gall dating to around 920. The symbols could remind singers of a melody's general shape, but they didn't specify the exact pitch of each note. If you didn't already know the tune, it was difficult to sing it from the notation alone. Over time, notation gained lines and spaces to indicate pitch. A Roman manuscript from 1071 on his slides had a red F line and a yellow C line, making pitch placement much clearer than in earlier notation. He also discussed the solmization syllables Ut, Re, Mi, Fa, Sol, La.⁶

Then, somehow, he moved from music into law and accounting.

In medieval England, transferring land once involved handing over a piece of turf in front of witnesses. Later, significant land transactions increasingly required signed written deeds. Accounting developed double-entry bookkeeping so that debits and credits could be checked against one another. These seemingly unrelated practices were addressing similar problems: who may do what, how the different parts stay consistent, and who checks that commitments have been honored.

He put music, law, accounting, and Rust side by side in a table. An orchestra relies on rehearsals and a conductor to correct mistakes; legal disputes wait for courts to intervene; accounts need auditing. Some Rust constraints, meanwhile, can be checked at compile time. He compared &self and &mut self to nonexclusive permission to use an asset and an exclusive right to use it, respectively, while taking ownership resembled transferring title. The analogy isn't exact, of course, but it helped something click for me: Rust's ownership rules are more than syntax that's hard to remember. They are explicit agreements about who has the right to use and modify data.

He also showed a concrete example from CodeWhale. After adding GeminiNative to the WireFormat enum, any match that failed to handle the new variant would produce a non-exhaustive patterns compiler error. AI can write the initial code, the compiler can point out omissions, and the developer can review the result. Let the machine draft; let Rust judge. That example was more convincing than simply saying “Rust is safe.”

But he didn't frame every difficulty in Rust as a virtue. His slides explicitly distinguished productive rigor from accidental complexity. Who owns the data, which states are possible, and what can fail are questions the program has to answer anyway. Slow compilation, friction around some lifetime designs, and rough edges in async development are burdens introduced by the tools, and deserve improvement. He also compared what Rust, Swift, C++, Go, and other languages can check and guarantee, without simply dismissing the others.

His closing point was that AI is making implementation easier, which makes expressing intent precisely and enabling people to keep building on one another's work all the more important. Of course, compiling successfully doesn't mean a program is entirely correct. Tests and code reviews are still necessary.

One other thing surprised me: Hunter gave the entire talk in English, but almost all his slides were in Chinese. Preparing and translating those examples across music, law, and accounting must have taken considerable care. Having studied music myself before moving into game development, I found it especially interesting to hear him connect all of this to Rust.

Later, I saw a post he'd written in Chinese on X and found him rather endearing. He called himself “the American guy who makes DeepSeek-TUI,” asked for help getting his WeChat account verified, and joked that the Chinese transliteration of his name, “亨特宝” (Hengtebao), made him sound like a little baby. That made me laugh.

4.2Flying Around a Codebase

Next was Rik Arends, co-founder of Makepad and Cloud9 IDE, with “Visualizing Large Codebases and AI Agent Activity with Makepad.” He demonstrated Makepad Scope, which turns an enormous codebase into a dense field of colored blocks. From a distance, you can distinguish modules; zoom in and you can drill down into files, text, and even pixel-level detail. Alongside the 2D block map, there's a 3D view and a timeline for seeing which modules agents have been working in and what changes they've made.²

What astonished me most was the zooming. The view moved closer and farther away with almost no perceptible transition between levels. At one point, it even seemed to reach the end of one scale and pick up again at another. I kept wondering how it could render so smoothly. It uses Makepad, the GPU-accelerated Rust UI framework Rik developed himself. My first reaction was that an ordinary web interface would struggle to do this, though browsers can also use WebGPU for sophisticated GPU rendering. What really stood out was the visualization and interaction design itself.

Scope is also doing more than making code look cool. AI agents can change many files at once, and Scope tries to make that activity visible: navigate from the whole project down to a file and a particular diff, and see what the agent has actually been doing.

I wanted to download it immediately, only to discover that it was still in beta and not fully available. I'd hoped to ask Rik after the talk whether I could join the test, but the conference group photo came next and I couldn't find him. I never got another opportunity, which was a little disappointing.

Scope is just one of the applications he's built with Makepad. He also showed his own presentation tool, where pages, animations, and effects can be described directly in code, making them easy to modify with AI assistance. There were other applications too, including a calendar. Seeing that range made me more curious about Makepad itself than a single spectacular demo would have.

In the afternoon, I went to Shenghao Ding (Delton)'s talk, “The Art of Interaction with Rust: Reshaping Multimedia Design Workflows with the Rust Stack.”

He demonstrated Godot CEF and an audio DAW project called Heron. Embedding a browser in a game engine sounds as though it might just involve connecting a few APIs, but in practice it brings all sorts of strange compatibility problems. Even graphics cards and driver versions can become sources of trouble.²

Both Godot CEF's compatibility issues and DAW tools like Heron are things I care about in my own work. After the session, I added Delton on QQ and started following the projects.

The final talk I attended that day was Jolestar's introduction to Holon. It's an event-driven AI agent runtime where agents with different roles can work, wait for events, receive feedback through webhooks, and continue collaborating. I'm interested in agent systems that go beyond a simple question-and-answer exchange.

Over those two days, I also met a very kind, more experienced developer whom I call Jiang-ge, or John.

When I entered a conference room on the first afternoon and went to take a seat, he pulled the chair out for me. We later chatted and exchanged WeChat contacts. During the conference group photo on the second day, I happened to stand beside him, and we took a separate photo together too.

After the conference, I found our photo in the official live photo album and sent it to him. He replied with a message saying how much he appreciated my initiative in talking with other developers and making connections. He encouraged me to become an outstanding developer and said we could all keep growing together.

I was deeply moved. We'd only known each other for two days, yet he offered such heartfelt encouragement. I saved his words in my private journal.

5I Actually Met DHH!

Going back to the second morning, there was another completely unexpected moment.

Upstairs, in the Omarchy session, I actually saw David Heinemeier Hansson (DHH)!

I'd only seen him in videos and articles before. I knew he'd created Ruby on Rails and, more recently, Omarchy. This time he was presenting Omarchy at GOSIM's keynote venue. Even though I'd known the talk was scheduled, seeing him in person was still exciting.⁷

I stood at the back listening and recorded a little video from a distance as a keepsake.

After the session, a crowd gathered around him for photos. I wanted one too, but worried about bothering him, so I held back. Later, as I was getting ready to leave, he happened to walk past, with fewer people around him.

This was my chance.

I quickly got my phone ready, walked over, and asked for a photo.

I got it!

Afterward, I couldn't stop smiling. Someone I'd only ever seen in videos and articles was now standing beside me in a photograph.

Later, I posted it on X to remember the moment.

Not long after, another notification appeared: DHH had liked our photo.

That set me off all over again, and I couldn't resist posting:

This could keep me happy for a whole year!

Other developers left congratulatory replies too.

I later wrote a separate post, “DHH: A Remarkable Life Beyond Programming”, exploring his experiences with Rails, entrepreneurship, racing, and Omarchy. As for this conference, that one photo alone will keep me happy for a long time.

6After the Conference

I used to barely use X.

I'd posted a few times before, but hardly anyone saw them, so I stopped bothering. When I built a new feature, I was more likely to share it in developer group chats, where it would quickly disappear in the stream of messages.

After meeting so many new friends, I started posting our photos, pictures from the conference, updates to my personal website, and my game projects on X.

To my surprise, people actually looked, and there were quite a few likes and conversations. Encouraged, I even posted several times in a single day. After years of barely posting at all, I now find myself wanting to share things whenever something interesting comes to mind.

To help the people I'd met at the conference get to know me, I also reorganized my personal website, elytra.dev, adding project introductions, videos, an article graph, and a photo gallery. After I shared it on X, the official GOSIM Foundation account unexpectedly reposted it and left an encouraging reply, saying they were happy to see people meeting like-minded peers in person and finding new inspiration. I'd only meant to put together a better introduction to myself. Receiving a response like that meant a great deal to me.

Xuebi later wrote a post introducing me and my game, and mentioning the hot pot dinner we'd shared after the conference. Seeing him say how much he'd enjoyed our conversation made me happy. More developers then came to look at my work and follow me.

I'd always felt that whatever I shared in a developer group chat would soon disappear from view. This time, I discovered that developers in entirely different fields could be interested too.

When we talked on the first evening about porting my open-source voxel game, Ethertum, to older handhelds, I assumed that actually doing it would mean spending a lot of time learning the tools and gradually adapting the game myself.

On October 23, PocketJS released Pocket Ethertum, an Ethertum port for the PS Vita. Rather than moving the original Bevy engine over directly, it uses Pocket3D and PocketJS to reimplement terrain generation, rendering, interaction, and other parts of the game. You can now try it online on the official site, download the PS Vita version, and explore the open-source code.

When I saw the release post, I was thrilled. Xuebi had actually built it already!

7Notes to Myself for Next Time

There are a few things I'd like to do better next time.

First, taking notes. I didn't bring a laptop on the first day. My main machine is heavy, has short battery life, and had some projects on it that I hadn't backed up, which made me uneasy about carrying it around. I brought it on the second day anyway. A gaming laptop with an RTX 4070 certainly has enough power, but its battery lasted only about three hours. It wasn't convenient for a full day of talks.

I'm planning to buy a MacBook Air M3, mainly for looking things up, taking notes while out, and connecting remotely to my own computer. Its advertised battery life is well over ten hours, though I'll have to use it myself to see how long it actually lasts.⁸ Next time, where recording is permitted, I'd also like to try transcription followed by AI-assisted organization. There were talks this time that I could no longer properly recall by that same evening.

Then there's photography. I took photos with quite a few people. Looking back at other people's vivo shots alongside the results from my Xiaomi 14 Pro, I did wish I'd changed phones sooner. I'm also planning to buy a vivo X300 Pro. These two days made me realize that what matters most to me isn't everyday snapshots—it's getting a good photo of people and moments I rarely have the chance to see.

I'd also like to get better at asking questions and talking to people. Next time, I don't need to be so nervous, or shorten a question so much in the interest of saving time that I can barely express it myself. After adding someone on WeChat, I can send a brief introduction that very day. I don't have to wait until my personal website is perfect.

And I want to attend more events like this.

I still haven't fully understood why RustScript needs its own virtual machine. Whether building my own engine is worthwhile, and how far Three.js can go, are questions I'd also like to explore firsthand.

Most of all, I hope that the next time I see these friends, we can pick up those conversations where we left off.

Looking back at that two-hour metro ride on Friday, the extra hours I worked beforehand, and my last day of annual leave for the year—

Every bit of it was worth it.

---

注释

1. 2026 Singularity Intelligent Technology Summit, Feihu Tang's speaker profile. The organizer's biography lists her work at Google, a gold medal at an ACM/ICPC Asia Regional Contest, and first place in Microsoft's Beauty of Programming Challenge. A regional gold medal is distinct from winning the ACM/ICPC World Finals. ↩

2. RustChinaConf 2026, Full three-day schedule. The official schedule was used to check talk titles, speakers, and project descriptions. Conversations and personal impressions are drawn from my own experience at the event. Talk titles in this English version are translations of those cited in the original post. ↩ ↩² ↩³ ↩⁴

3. PocketJS, Introducing PocketJS, Architecture, and TypeScript and native code. These official materials explain the standard JavaScript execution path, the Rust UI core, and the optional ahead-of-time compilation path to Rust. The PSP demo's 8 MB figure is an application memory budget, including QuickJS, the Rust core, textures, and other overhead, rather than the device's total memory. ↩ ↩²

4. GBDev, Game Boy Technical Data, historical Pan Docs. Lists the original Game Boy's 8 KB of working RAM, 8 KB of video RAM, approximately 4.19 MHz clock speed, and 160 × 144 resolution. ↩

5. Yifeng "Evan" Wang, July 23, 2026, Pocket Vapor: Vue, Compiled All the Way Down. This firsthand technical article from the team demonstrates compiling the same Vue to-do component for the Game Boy, GBA, and NES. The Game Boy version is a 32 KB ROM built through generated C code, with no JavaScript engine required. The team's Game Boy device page also includes screenshots and sample code. ↩

6. University of Basel, Lines and staff. Describes early neumes, the development of staff notation in the eleventh century, and a Roman manuscript from 1071 with a red F line and a yellow C line. The account of the talk itself is based on the slides shown at the venue and my notes. ↩

7. GOSIM Shenzhen 2026, DHH's Omarchy talk. The event's official session page supports the details about the concurrent event and speaker. ↩

8. Apple, MacBook Air (13-inch, M3, 2024) technical specifications. Apple lists up to 15 hours of wireless web use and 18 hours of video playback; actual battery life depends on software, network conditions, and workload. ↩