DEV Community: Alex

Is Unsafe the Original Sin? A Deep Dive into the First CVE After Rust Entered the Linux Kernel

Alex — Thu, 18 Dec 2025 14:10:00 +0000

Prelude: A Predictable Controversy

On December 16, 2025, a peculiar entry appeared in the Linux kernel CVE announcement list: CVE-2025-68260.

This was no ordinary kernel vulnerability. It came from rust_binder, the Rust implementation of the Android Binder driver in the Linux kernel. This marks the first CVE officially assigned to Rust code since Rust entered the Linux kernel mainline.

The news set social media ablaze.

Rust critics felt they had finally found the "smoking gun" they'd been waiting for:

"Since unsafe is unavoidable in the kernel, and unsafe code has hidden dangers, maybe you shouldn't have been bragging everywhere that 'if it compiles, it works.' So now we need to add another condition that unsafe code doesn't count as compiled code?"

Rust supporters quickly fired back:

"Before you start trending on the first reported CVE linked to rust code on the linux kernel, note that: on the same day, 159 kernel CVEs were issued for the C portion of the codebase."

One C developer even stepped up to defend Rust:

"It's funny how as a C dev I gotta defend Rust, but there are over a hundred of these daily caused by C code. A single non-critical CVE in 5 years doesn't seem that big with this information."

The debate ultimately centered on a frequently misunderstood feature of the Rust language: Unsafe.

So today, let's use this CVE as an opportunity to thoroughly understand: What exactly is Unsafe Rust? Is it a "loophole" in Rust's safety promises, or a "necessary evil" of systems programming?

Part One: What Exactly Happened with This CVE?

Before diving into unsafe, let's first understand the vulnerability itself.

Background: Safe Abstraction in Unsafe Rust

To understand this vulnerability, we first need to understand one of Rust's core design principles: Safe Abstraction.

Rust divides code into two worlds:

Safe Rust: The compiler automatically proves memory safety at compile time through mechanisms like ownership and the borrow checker. You don't need to do anything extra—if it compiles, it means there are no data races, dangling pointers, buffer overflows, etc.
Unsafe Rust: Certain low-level operations (like dereferencing raw pointers or calling FFI functions) exceed the compiler's static analysis capabilities. In these cases, developers must mark code blocks with the unsafe keyword, personally promising the compiler: I have manually verified that this code is safe.

The key point is: code inside an unsafe block still receives the same memory safety checks as Safe Rust (Unsafe is a superset of Safe), but for certain specific operations—like manipulating raw pointers—the compiler simply cannot help, so developers must guarantee safety themselves.

This raises a question: How do you prove your promise is trustworthy?

The answer is SAFETY comments: a community-established documentation convention. Above every unsafe block, developers must clearly state:

Why is unsafe needed here? (What operation can't the compiler verify?)
What preconditions does safety depend on? (i.e., "invariants")
Why do these preconditions hold? (Provide the reasoning)

This isn't optional "nice-to-have" documentation—it's a mandatory convention in the Rust community. Unsafe code without SAFETY comments will be rejected outright in code review.

Why? Because the correctness of unsafe code depends entirely on whether these invariants hold. If invariants are wrong, incomplete, or become invalid as code evolves, bugs will emerge.

Now, let's look at the problematic code in this CVE.

The Problematic Code

The vulnerability appeared in the drivers/android/binder/node.rs file. To understand this bug, we need some background.

What is Binder?

Binder is the core Inter-Process Communication (IPC) mechanism in Android. When one app wants to call another app or system service, it goes through Binder. It's one of the cornerstones that makes Android work.

What is death_list?

In Binder, there's an important concept called "Death Notification." When a service process crashes unexpectedly, all clients depending on it need to be notified. The NodeDeath struct represents such death notifications, and death_list is a linked list storing all death notifications registered to a particular Binder node.

What is this code doing?

When cleaning up a NodeDeath, the code needs to remove it from its associated death_list linked list. The problem lies in this removal operation:

// SAFETY: A `NodeDeath` is never inserted into the death_list
// of any node other than its owner, so it is either in this
// death list or in no death list.
unsafe { node_inner.death_list.remove(self) };

The SAFETY comment claims: A NodeDeath node is only ever inserted into the death_list of its owning node, so it's either in this list or in no list at all.

Based on this assumption, the developer believed this unsafe operation was safe.

But the problem is: this assumption doesn't hold in concurrent scenarios.

Formation of the Race Condition

Let's look at the logic of the Node::release function:

Thread A (Node::release):
  1. Acquire lock
  2. Move all items from death_list to a temporary list on the stack
  3. Release lock  ← Problem is here
  4. Iterate through the temporary list, processing each node

Thread B (NodeDeath cleanup):
  At some point calls unsafe { death_list.remove(self) }

See the problem?

After Thread A releases the lock in step 3 but before completing step 4, Thread B might simultaneously call remove on the original list. At this point:

Thread A is traversing via the temporary list, accessing nodes' prev/next pointers
Thread B is removing via the original list, also modifying nodes' prev/next pointers
Two threads modifying the same memory simultaneously, with no synchronization mechanism

https://pbs.twimg.com/media/G8YfVRnW4AEALhU?format=jpg&name=4096x4096
(Diagram from x.com/forefy)

This is a classic Data Race, corrupting the linked list pointers. The end result is a kernel crash:

Unable to handle kernel paging request at virtual address 000bb9841bcac70e
...
Internal error: Oops: 0000000096000044 [#1] PREEMPT SMP

The Fix

The fix is actually simple: instead of moving items to a temporary list, pop and process items directly from the original list while holding the lock. This eliminates the window where "other threads can access the list after the lock is released."

Key Insight

What's the essence of this bug?

It's not that unsafe itself is problematic, but that the invariant assumption in the SAFETY comment was wrong.

The developer assumed "the node is either in this list or in no list," but in reality, the Node::release implementation could move nodes to a temporary list that wasn't protected by the lock. This broke the original assumption.

In the words of Ralf Jung (Rust language team member): The most important comment in unsafe code is the one about its invariants. And this comment was precisely wrong.

Part Two: What Exactly Is Unsafe Rust?

Coincidentally, shortly before this CVE was published, Ralf Jung—an authoritative researcher on Rust's memory model—gave a talk about unsafe Rust at Scala Days 2025. This talk perfectly answers the question "What exactly is Unsafe?"

unsafe ≠ Unsafety

First, let's clarify a common misconception: unsafe doesn't mean "unsafe code," but rather "code whose safety the compiler cannot automatically verify."

In Safe Rust, the compiler can prove at compile time—through the ownership system, borrow checker, and other mechanisms—that code won't exhibit:

Null pointer dereferences
Dangling pointers
Data races
Buffer overflows
Double frees

But some operations cannot be statically proven safe by the compiler, such as:

Dereferencing raw pointers
Calling FFI functions
Accessing mutable static variables
Implementing certain special traits

These operations require the unsafe keyword. Unsafe doesn't mean "you're allowed to write dangerous code," but rather "you're promising the compiler: I have manually verified this code's safety."

Ralf Jung's original words:

"Rust doesn't make unsafe 'free'; it makes it explicit and accountable."

The Five Operations unsafe Allows

Inside an unsafe block, you can perform these five types of operations:

Operation	Description
Dereference raw pointers	`const T` and `mut T`
Call unsafe functions or methods	Including FFI functions
Access or modify mutable static variables	`static mut`
Implement unsafe traits	Such as `Send`, `Sync`
Access union fields	Because the compiler can't know which variant is currently stored

Key point: unsafe is "permission," not "correctness." The compiler allows you to do these things, but you must ensure you don't trigger undefined behavior.

Invariants: The Soul of unsafe

Every piece of unsafe code should have clearly documented invariants. Invariants answer three questions:

Why is unsafe needed? What is this code doing that the compiler can't verify?
What assumptions must be maintained? What conditions does correct execution depend on?
What could break it? What inputs or concurrent accesses might violate these assumptions?

Looking back at CVE-2025-68260's problematic code:

// SAFETY: A `NodeDeath` is never inserted into the death_list
// of any node other than its owner, so it is either in this
// death list or in no death list.
unsafe { node_inner.death_list.remove(self) };

The comment does state "why it's safe," but the assumption itself is incomplete—it didn't consider that Node::release would move nodes to a temporary list. If the invariants are wrong, the unsafe code cannot possibly be safe.

Part Three: Why Must the Kernel Use unsafe?

"If unsafe has risks, why not avoid it entirely?"

The answer is: In systems programming, unsafe is unavoidable.

Three Hard Requirements of Systems Programming

Ralf Jung listed three fundamental reasons why unsafe exists:

1. Interacting with the Low-Level World

Operating system kernels must interact with hardware, C code, and device drivers. These interactions require:

Raw pointer operations
Specific memory layout control
FFI calls

Rust's safe abstractions are built on top of these low-level operations, and these operations themselves cannot be covered by safe abstractions.

2. Performance and Predictability

Certain high-performance data structures (like lock-free queues, memory allocators, intrusive linked lists) require fine-grained control over memory layout and access patterns. The compiler's automatic checks sometimes prevent safe but efficient implementations.

3. Expressing Cross-Layer Invariants

Some safety guarantees span multiple abstraction layers that the compiler cannot statically capture. For example:

"This pointer points to valid memory because we guarantee it at a higher logical level"
"This trait implementation definitely satisfies certain semantic constraints"

Ralf Jung's summary:

"Unsafe is where Rust meets the world."

The Linux Kernel's Special Challenges

As a complex piece of systems software, the Linux kernel has numerous scenarios requiring unsafe:

Memory management: Direct manipulation of physical memory and page tables
Interrupt handling: Executing code in special contexts
Concurrency primitives: Implementing locks, atomic operations, RCU
Device drivers: Interacting with hardware registers
C code interoperation: The vast majority of the kernel is still C

This isn't Rust's problem—it's the nature of systems programming. C's approach is unsafe by default—all code might have problems, with no compile-time checks. Rust's approach is safe by default + explicit unsafe (unsafe block & keyword)—concentrating risk at a few controlled boundaries.

Part Four: How to Use unsafe Correctly

Since unsafe is unavoidable, how do we minimize risk?

Ralf Jung offered three core principles: Minimize, Document, Encapsulate.

Principle One: Minimize

Use unsafe only where unavoidable, keeping it to the smallest possible scope.

Don't write this:

unsafe {
    // A whole bunch of code
    // Only one line actually needs unsafe
    // But the entire block is marked unsafe
}

Write this instead:

// Safe preparation work
let ptr = get_pointer();
let len = calculate_length();

// Use unsafe only where necessary
let value = unsafe { *ptr };

// Safe follow-up processing
process(value);

Principle Two: Document

Write clear invariants above every unsafe block.

A good comment template:

// SAFETY: 
// - `ptr` is valid because it came from `Box::into_raw` and hasn't been freed yet
// - `ptr` points to properly aligned memory because Box guarantees this
// - We have exclusive access because no other references exist
unsafe { Box::from_raw(ptr) }

Bad comments (or no comments at all) lead to:

Future maintainers not knowing what assumptions the code depends on
Refactoring potentially breaking assumptions inadvertently
Inability to verify correctness during code review

Principle Three: Encapsulate

Wrap unsafe implementations with safe APIs.

This is the most important principle. Unsafe code should be encapsulated inside modules, exposing completely safe interfaces externally. Users don't need to know there's unsafe inside and cannot misuse it.

The classic example is the standard library's Vec<T>:

// Internal implementation uses unsafe for memory management
// But the external interface is 100% safe
let mut v = Vec::new();
v.push(1);  // Safe call, no unsafe needed
v.push(2);
let first = v[0];  // Safe call

The Vec implementer bears the responsibility of unsafe; users don't need to worry about memory safety at all.

Architecture Diagram: Proper Layering of unsafe

┌─────────────────────────────────────────────────────────────┐
│                   Application Layer Code                     │
│                     (100% Safe Rust)                         │
├─────────────────────────────────────────────────────────────┤
│                      Safe API Layer                          │
│            (Safe interface, encapsulating unsafe)            │
├─────────────────────────────────────────────────────────────┤
│                     unsafe Core Layer                        │
│      (Minimized unsafe code, detailed invariant docs)        │
├─────────────────────────────────────────────────────────────┤
│                  Low-level / FFI / Hardware                  │
└─────────────────────────────────────────────────────────────┘

Key insight: The smaller the unsafe surface area, the lower the audit cost, and the easier bugs are to find.

Part Five: Tools and Methods for Making unsafe Verifiable

The Rust community hasn't stopped at "relying on human effort to ensure unsafe correctness." A series of tools and formal methods are shifting unsafe risk management from "experience-driven" to "evidence-driven."

Miri: The Gatekeeper of unsafe

Miri is a Rust interpreter that can detect various undefined behaviors at runtime:

Invalid memory accesses
Aliasing rule violations (Stacked Borrows / Tree Borrows)
Uninitialized memory reads
Memory leaks

When developing unsafe code, running tests with Miri can catch many hidden bugs.

Loom: The Concurrency Revealer

Loom is a concurrency testing framework that discovers race conditions by exhaustively (or intelligently sampling) thread schedules.

The bug in CVE-2025-68260 would likely have been found before release if tested with Loom.

Sanitizers: Sentinels at FFI Boundaries

AddressSanitizer (ASan) and ThreadSanitizer (TSan) can detect memory errors and data races, particularly useful for Rust-C interaction boundaries.

RustBelt: Formal Verification

RustBelt is an academic project providing formal semantic foundations for Rust's type system and unsafe encapsulation. It mathematically proves: If unsafe code satisfies specific invariants, then its safe encapsulation is safe in any usage scenario.

Ralf Jung's original words:

"Tooling makes unsafe less mystical; formal methods make it trustworthy."

Part Six: A Rational View of This CVE

Now, let's return to the original debate.

Let the Data Speak

On the same day CVE-2025-68260 was published, the C portion of the Linux kernel had 159 CVEs issued.

Let's make a simple comparison:

Metric	Rust Code	C Code
Time in kernel	~3 years	~33 years
Code proportion	< 1%	> 99%
Cumulative CVE count	1	Tens of thousands
CVEs issued this time	1	159

This data isn't meant to prove "Rust is perfect," but to show: Rust significantly reduces the occurrence rate of memory safety vulnerabilities.

What Does This Bug Tell Us?

Unsafe code needs more careful review: Safety assumptions in comments must cover all scenarios, including concurrent scenarios.
Rust hasn't eliminated bugs, but changed their distribution: Safe Rust eliminates entire classes of memory safety bugs; remaining bugs concentrate at unsafe boundaries and logical errors.
Explicit unsafe makes problems easier to locate: Once this bug was found, developers immediately knew to check the unsafe block's invariants. With C code, locating the problem would be much harder.

Rust's Promise Was Never "Zero Bugs"

Rust's safety promise is:

If your code is 100% safe Rust (no unsafe), it won't have memory safety issues.

For code containing unsafe, the promise becomes:

The correctness of unsafe code depends on whether your maintained invariants are correct. If invariants are correct, the encapsulated safe API is safe.

This CVE precisely proves: When invariants are wrong, unsafe code will have problems. This isn't a Rust defect—it's Rust's design working as intended—concentrating risk in auditable, accountable places.

Comparison with C

What would it look like if the same code were implemented in C?

No unsafe markers: All code is "unsafe," making it impossible to quickly locate high-risk areas
No mandatory SAFETY comments: Invariants might not be documented at all
More prone to other memory safety issues: use-after-free, buffer overflow, null pointer, etc.
Harder to trace problem sources: No ownership system to assist analysis

Part Seven: Responding to Rust Haters

Let's directly address the criticism from the beginning of this article:

"Since unsafe is unavoidable in the kernel, and unsafe code has hidden dangers, maybe you shouldn't have been bragging everywhere that 'if it compiles, it works'..."

This criticism is based on a false premise.

The Rust community has never said "if it compiles, it works." The accurate statement is:

Safe Rust code: Compilation passing = no memory safety issues (this has formal proof support)
Unsafe Rust code: Compilation passing ≠ no problems; human verification of invariants is required
Mixed code: Overall safety depends on the correctness of the unsafe portions

Rust's value lies in:

Narrowing the scope requiring human review: Only unsafe blocks need special attention
Clarifying review focus: Invariant documentation tells you what to verify
Eliminating entire classes of bugs: In safe Rust, data races, use-after-free, etc. simply cannot occur

Reducing "100% of code needs memory safety concerns" to "only 1% of code needs concerns"—this itself is enormous progress.

Conclusion: Safety Isn't About Avoiding Low-Level Work, But Doing It the Right Way

CVE-2025-68260 is the first CVE since Rust entered the Linux kernel, but it won't be the last. As long as there's unsafe code, there's potential for mistakes.

But this precisely illustrates Rust's design philosophy:

Acknowledge the necessity of low-level operations, but use explicit markers, invariant documentation, tooling detection, and community conventions to control risk to the minimum scope.

Ralf Jung's summary at the end of his talk is worth remembering for every systems programmer:

unsafe is a necessary interface layer, not wanton escape
Document and encapsulate with invariants at the core, keeping danger in a small room
Treat UB as a red line, guarding it with tools and tests
Use community conventions and formal methods to upgrade experience into verifiable engineering

Safety isn't about avoiding low-level work, but doing it the right way.

This CVE isn't Rust's failure—it's the unsafe mechanism working as designed—exposing problems at controlled boundaries, allowing us to quickly locate, fix, and learn from them.

159 versus 1. This numerical comparison is the story truly worth discussing today.

Appendix: CVE-2025-68260 Technical Details

Vulnerability Type: Race Condition

Affected Versions: Linux 6.18 (introduced)

Fixed Versions: Linux 6.18.1, 6.19-rc1

Problem File: drivers/android/binder/node.rs

Root Cause: Node::release iterates over a temporary list after releasing the lock, creating a data race with other threads' unsafe remove operations

Fix: Pop elements directly from the original list while holding the lock, avoiding the race window after lock release

Reference Links:

If you found this article helpful, feel free to like, share, and subscribe.

What are your thoughts on Rust and systems programming? Feel free to discuss in the comments.

Forging the Future: My Ten-Year Journey Growing with Rust

Alex — Mon, 19 May 2025 20:42:00 +0000

Hello everyone, I am Zhang Handong(AlexZhang), an independent consultant and technical writer. I have been in the Rust community for ten years, and on the occasion of Rust's tenth anniversary, I want to write down my story. It may not be that extraordinary, but these ten years are where I come from today.

Looking back on this journey, I see not just the evolution of a programming language, but the growth of a passionate community from nothing to something, from small to large. During these ten years, I experienced the transformation from a learner to an evangelist, and witnessed the entire process of Rust in China evolving from a niche language to gradual adoption by mainstream enterprises. This is a story about learning, sharing, challenges, and growth, and also a microcosm of Chinese developers participating in the global open source community.

In fact, I've experienced many people and events related to Rust over these ten years that cannot be contained in this short article. Perhaps you will see some content worth writing about in my new book.

Let me start from 2015.

First Encounter with Rust: The Turning Point of 2015

In 2015, I began to explore the Rust programming language, which had just released version 1.0.

Actually, before 2015, I had been using dynamic languages for application development, coinciding with the previous "startup wave." But by 2015, I felt personally exhausted with application development because applications changed too quickly, so I wanted to explore lower-level systems. I had this idea for a long time, but because I didn't particularly like C/C++, I never took action. After Rust released version 1.0 in 2015, I began learning Rust.

As an engineer with many years of software development experience, I was attracted to Rust's design philosophy: memory safety without garbage collection, concurrency without data races, and zero-cost abstractions. My experience working in e-commerce, social gaming, advertising, and crowdfunding made me deeply aware of the limitations of traditional languages in large-scale system development, while Rust's future-oriented design appealed to me. At that time, I believed that Rust would be the last programming language I would need to learn in my lifetime.

However, the learning process for Rust was full of challenges. I once considered giving up, but my character of enjoying challenges pushed me to persist. And it was precisely these seemingly difficult learning curves that solidified my knowledge foundation in lower-level systems.

I have always believed that it was Rust that reignited my passion for programming.

The Evangelism Path: From Daily Reports to Writing Books

In January 2018, I created "Rust Daily," compiling the latest developments in the Rust ecosystem every day. At that time, resources about Rust in Chinese were extremely limited. I hoped that through daily reports, I could lower the barrier for Chinese developers to access information about Rust. To my surprise, this small initiative received an enthusiastic response from the community and continues to this day.

The Birth and Impact of "The Way of Rust Programming"

In January 2019, my book "The Way of Rust Programming" was officially published. Reflecting on the original intention of writing, it actually stemmed from my understanding of learning itself. Rust is known for its steep learning curve, but in my view, this is precisely a valuable growth opportunity, not an obstacle. I didn't see it as a bad thing; I am the type of person who likes to challenge difficulties. A high learning curve indicated gaps in my knowledge system, and challenging the Rust language was an excellent opportunity for me to supplement my foundational knowledge of computer systems.

Rust learning materials on the market were very limited at that time. The official "The Rust Programming Language," while comprehensively introducing the syntax, failed to help readers clarify Rust's knowledge system. I had to resort to C++ and Haskell materials to assist my learning (because Rust borrowed many features from these two languages). As my understanding of Rust deepened, the idea of writing a systematic Rust guide gradually took shape.

On one hand, I firmly believe that "writing is the best way of thinking," and through writing, I could systematically organize my understanding of Rust; on the other hand, I observed that the community indeed needed a book for advanced readers, providing those who had completed basic knowledge with a more systematic cognitive perspective.

After "The Way of Rust Programming" was published, my influence in the Rust community significantly increased, and that same year I participated in RustAsiaCon to share and exchange ideas. However, as no one is perfect, errors in the book were gradually discovered by readers. In my GitHub errata repository, readers submitted more than 200 issues, and some even mocked: "How can you read a book with more than 200 issues of errata?"

These criticisms once troubled me greatly, but later I realized that a book is essentially a form of communication. For me, writing a book is not about educating others, but about sharing my understanding while accepting feedback to promote my own growth. Through readers' errata, I corrected some misconceptions about Rust, which is exactly the best feedback I hoped to see from writing the book.

With fame came more attention and evaluation. For a period, I was overly concerned with others' evaluations. When someone sarcastically called me the "Father of Rust in China," I once fell into depression, almost falling into the "self-verification trap." After reflection, I finally understood: regardless of how others evaluate me, I only need to focus on doing my best.

Community Building: Connecting China with the World

In 2020, despite the challenges of the global pandemic, my teammates and I organized the first RustChinaConf in Shenzhen. As one of the initiators of the conference, seeing hundreds of Rust enthusiasts gather together to passionately discuss technical topics made me incredibly proud. That same year, I released "Zhang Handong's Rust Practical Course" on GeekTime, hoping to help more developers systematically learn Rust through online education.

The Founding and Reflection of "Rust Magazine"

In 2021, the successful hosting of RustChinaConf showed me the vibrant vitality of the Chinese Rust community and gave me more confidence to promote community development. I decided to found "Rust Magazine," hoping that through a systematic publication, Chinese companies adopting Rust could better present their practical experiences to the public while providing a continuous learning platform for the community.

That year, I also established the "Rust Chinese Community" on Feishu and regularly organized online salon activities. These platforms not only provided learning resources for developers but also facilitated connections between many Rust startups and talents. I was also fortunate to participate in Alibaba DAMO Academy's Feitian School to share Rust concepts, bringing Rust philosophy into large technology companies.

Unfortunately, "Rust Magazine" ceased publication after persisting for a year. Reflecting on this experience, I believe it may have been because Rust's industrial adoption in China had not yet reached a critical point, and the pressure of content creation and maintenance was substantial. Nevertheless, I still believe this was a valuable attempt, and perhaps by 2026, with the further popularization of Rust in China, we can restart this project.

In 2022, due to the pandemic, RustChinaConf was held online. That same year, I open-sourced the "Rust Coding Guidelines" project, hoping to provide a coding standard blueprint for Chinese companies adopting Rust.

Industrial Adoption: From Theory to Practice

Reflecting on my experiences in community evangelism, RustChinaConf conferences, and providing Rust consulting services to different enterprises, I found a clear pattern: Rust adoption in China shows distinct phases.

I have successfully provided Rust consulting and internal training for these enterprises: Huawei / ZTE / Ping An Technology / Zhongtai Securities / Li Auto / Pengcheng Laboratory.

2015-2018 was the exploration period, when everyone was full of hope for the Rust language but also had many concerns. However, domestic New SQL database pioneer PingCAP and ByteDance's Feishu team were among the earliest "early adopters."

2019-2022 was the expansion period, with telecommunications giants like Huawei/ZTE beginning to prepare for large-scale adoption of Rust. Huawei piloted Rust adoption in multiple areas, even making it one of the important development languages for the HarmonyOS operating system. During this phase, Rust was mainly applied in system programming, device drivers, and network services. And in 2021, Huawei joined the Rust Foundation as a founding board member. Tsinghua University's Rust OS Training Camp also began to launch.

2022 to the present is the explosive period. ByteDance also began to gradually expand Rust internally, not just in Feishu but also in infrastructure, and by 2024, TikTok was also using Rust. By 2024, Huawei had designated Rust as the company's seventh main language. Ant Group also began using Rust to write a trusted OS, with the goal of replacing Linux. Many infrastructure startup teams, from embedded systems to databases, from physics engines to GUI to apps, have companies and teams using Rust.

Open Source Contributions: Connecting Technology and Community

In recent years, I have gradually shifted my focus to open source project development and contributions. Participating in the development of the Robius framework (a pure Rust App development framework targeting Flutter), Moxin (a large model client based on Rust), and other projects has given me the opportunity to apply Rust to cutting-edge technology fields.

In 2023 and 2024, I participated in hosting the GOSIM Rust Workshop and GOSIM China Rust Track. GOSIM invited Rust officials and experts from well-known open source projects abroad to come to China to share. These international exchange activities not only enhanced China's influence in the global Rust community but also provided Chinese developers with opportunities for face-to-face exchanges with top international Rust experts.

This September, in Hangzhou, GOSIM will join with RustChinaConf 2025 and RustGlobal (the Rust Foundation's conference brand) to build a Rust exchange platform for domestic and international Rust developers.

In 2025, I collaborated with Tsinghua OS Training Camp to launch the "Rust Open Training Camp," which received event sponsorship from the Rust Foundation. This project aims to cultivate Rust talents with system programming capabilities, filling the talent gap in this field in China. The first training camp was successfully held, with registrations reaching 2,000 people.

Future Outlook: Continuing to Expand the Scale of Domestic Rust Developers

Looking back on this ten-year journey with Rust, I feel deeply honored to have witnessed and participated in the development of Rust in China. From an initially niche language to its gradual application in cutting-edge fields such as systems programming, cloud native, AI, and blockchain, Rust's growth trajectory is exciting.

As a Rust evangelist, my greatest sense of achievement comes not from personal technical progress, but from seeing more and more Chinese developers join the Rust community, more and more Chinese enterprises adopt the Rust technology stack, and more and more Chinese faces appear in the global Rust community.

In the future, I will continue to contribute to Rust technology promotion, community building, and talent cultivation, helping the continued development of Rust in China, and also looking forward to Chinese developers playing a greater role in the global Rust ecosystem.

Ten years to forge a sword, the path of Rust is long. But I firmly believe that the best times are still ahead.

AgentKit: A Technical Vision for Building Universal AI Automation for Human-Computer Interaction Based on Rust

Alex — Fri, 18 Apr 2025 04:59:00 +0000

Introduction

This week I came across a project called Droidrun, which allows you to control your Android phone through natural language commands.

When I first saw this project, I didn't think much of it. Today, after seeing the news about the project being open-sourced, I became curious about how it works, so I looked at the code to understand the principles behind it.

What I found was truly fascinating.

Just this Monday, I had come across Accesskit.dev, a cross-platform, cross-language Rust abstraction layer that encapsulates the native accessibility service APIs of different operating systems (like Windows, macOS, Linux/Unix, Android), such as UIA, NSAccessibility, AT-SPI, and the Android Accessibility Framework. At that time, I was thinking that if large language models were to act as humans, they would essentially be like people with disabilities (no derogatory meaning intended). This API set would be perfect for building AI Agents.

And today, I discovered that the core mechanism of the Droidrun project is built using Android's accessibility service API. This is what made me feel that the world is truly amazing: while I was still at the idea stage, someone else had already implemented it.

Unfortunately, it's not a cross-platform app, and its limitation is that it only supports Android phones. Coincidentally, I am a number one fan of the Rust language, and I know that Rust is particularly well-suited for cross-platform development.

I started thinking, could we take the approach from the Droidrun project, combine it with the Rust language, and implement a universal AI automation kit that not only supports Android phones but also iOS, desktop platforms, and even any smart terminal? This article was born from this idea, and AgentKit is the name I've given to this universal AI automation kit.

Therefore, this article will start with the Android platform's AI automation practice, Droidrun.ai, deeply analyze its implementation mechanism and limitations. We will then explore the key role of cross-platform accessibility infrastructure AccessKit. Finally, I will propose a detailed vision for the universal AI control framework AgentKit, including its architecture design, collaborative relationship with existing protocols, potential application scenarios, and development roadmap, aiming to outline a future automation infrastructure driven by AI that transcends digital boundaries.

The Future of Applications in the AI Era
Analysis: Droidrun AI's Pioneering Exploration of Android Automation
Foundation of the AgentKit Vision: Cross-Platform Capabilities of AccessKit
AgentKit: Universal AI Automation Framework Concept
Complementary Collaboration Between AgentKit and Claude MCP / Google A2A Protocols
Conclusion

The Future of Applications in the AI Era

Before thinking about this universal AI automation kit, the first question that came to my mind was: Do we still need apps in the AI era? After all, if we don't need apps anymore, we wouldn't need any AI automation kit either.

Fortunately, I understand an objective principle of this world: castles in the air don't exist.

So, let's think about this question starting from the evolution history of computer interfaces. Human-computer interaction has undergone several major paradigm shifts:

Command Line Interface: Humans needed precise syntax and memory capabilities, not something an average person could operate (I've heard that the father of Genshin Impact could open game programs in DOS at the age of five).
Graphical User Interface (GUI): Introduced visual metaphors and direct manipulation concepts (which saved ordinary people like me).
Mobile Touch Interface: Brought computing power into our palms, based on gesture interaction (iPhone is great in every way, just a bit expensive).
Voice Assistants: Started moving toward natural language interaction (AI is quite clever).

And now we are entering an era of the so-called "AI Intermediary Interface", where large language models act as intermediaries between human intent and computing resources. This transition is indeed revolutionizing the way we interact with technology, but it doesn't mean apps will completely disappear.

Despite AI's improving language understanding capabilities, I believe applications will transform rather than disappear, for several reasons:

In terms of cognitive and perceptual efficiency, AI cannot replace humans. Humans process visual information with extreme efficiency. Our brains can instantly understand complex spatial relationships, hierarchical structures, and patterns, while describing these using language (text or speech) might require lengthy passages. Imagine editing a photo: describing the precise adjustments you want ("increase brightness by 15% in the upper right quadrant while reducing saturation in the blue channel") is much more complex and cognitively demanding than simply dragging sliders or using visual tools. Language, though powerful, is not the optimal choice for all interaction scenarios. Just as we use both verbal and non-verbal communication (gestures, expressions) in real life, human-computer interaction will maintain a state where multiple modes coexist.
Some professional domains have special requirements. Many fields need specialized interfaces that match their conceptual models, such as:

Creative applications: Music production, video editing, and 3D modeling involve spatial and temporal relationships that are naturally expressed through visual interfaces
Data visualization: Understanding complex data often requires interactive exploration, which is difficult to navigate through language alone
Games: Interactive entertainment relies on immediate feedback and spatial awareness
Professional tools: Fields like medical imaging and architectural design require highly visual and precise control

For these two fundamental reasons, I believe applications won't disappear but will deeply integrate AI while retaining visual elements:

AI-enhanced interfaces: Traditional visual elements enhanced by AI capabilities, like Photoshop's generative fill feature
Multimodal interaction: Combining voice, touch, eye movement, and gestures to form a richer interactive experience
Adaptive interfaces: User interfaces that automatically reconfigure based on user behavior and AI understanding (this idea might be somewhat ahead of its time)

From a cognitive science perspective, human thinking processes both linguistic and non-linguistic information simultaneously, and our technological interfaces will reflect this duality. Language models provide a natural instruction layer, while visual interfaces provide the interaction modes required for spatial and visual thinking.

Therefore, universal AI automation kits like AgentKit may become even more important in this evolving process:

Need for bridging technology. As interface paradigms diversify, we need systems that can work across different interaction models and device platforms. AgentKit's vision of providing a unified layer for AI to interact with various interfaces becomes more valuable, not less. This bridging role is similar to the relationship between operating systems and hardware. When hardware becomes more diverse, the operating system's abstraction layer doesn't become less important; rather, it becomes more critical as it needs to coordinate more types of devices.
Managing complexity through abstraction. Even if frontend interfaces change significantly, the basic need to interact with complex systems remains. AgentKit provides an abstraction layer that allows users and AI to avoid focusing too much on implementation details, which is very important. We can draw an analogy to the evolution of programming languages: although high-level languages continue to evolve, the complexity of underlying systems still exists; we just manage this complexity through better abstractions. Similarly, the evolution of AI interfaces won't eliminate the complexity of underlying systems but will create better abstractions to manage it.
Supporting the transition period. The shift to AI-first computing will be gradual and uneven. Systems like AgentKit that can connect traditional and emerging paradigms are crucial during this long transition period. History shows that technological transitions usually take longer than we expect. For example, command-line interfaces still exist today, decades after graphical interfaces became popular, and maintain their advantages in certain domains. Similarly, traditional application design will coexist with the AI era for a long time.

I believe we will see layered user experiences: at the high level, users can express their intent through natural language ("edit my photo from yesterday to make it look warmer"), while AI is responsible for translating this intent into specific operations, or opening appropriate visual interfaces when needed for fine-tuning or intuitive feedback.

A characteristic of technological evolution is that new paradigms rarely completely replace their predecessors. As I mentioned earlier, castles in the air don't exist in this world, and AI is no exception. Instead, they usually create new ecological niches, while old methods continue to exist in their areas of expertise.

Therefore, the future is unlikely to be a binary choice between traditional applications and pure AI interfaces, but rather a rich continuum where different interaction styles coexist, complement, and co-evolve.

Analysis: Droidrun AI's Pioneering Exploration of Android Automation

Droidrun.AI has opened a window into this new human-computer interaction paradigm. I believe it is an important attempt in the field of Android automation, demonstrating how to achieve intelligent device control based on natural language using AI and system-level APIs.

Droidrun Overall Architecture and Working Principles

The Droidrun App consists of two independent projects: droidrun (Python agent) and droidrun-portal (Android application). The overall workflow of the application is shown in the diagram:

Flow Chart Explanation:

User Startup: The user enters a natural language task through the Droidrun CLI.
Environment Setup: The CLI parses parameters, obtains the device serial number, and sets the environment variable DROIDRUN_DEVICE_SERIAL.
Agent Startup: The ReActAgent is initialized.
ReAct Loop:
- Thinking: The Agent sends the current goal and history steps to the LLM Reasoner.
- Decision: The LLM returns the thinking process (thought), the action to be executed (action), and parameters.
- Action: The Agent calls the corresponding function in tools.actions to execute the action.
  - Get UI State (Key Interaction): If the action is get_clickables or get_all_elements:
    - The Python tool sends a broadcast command to the Portal Service on the device via ADB.
    - The Portal Service uses the accessibility API to scan the UI, build a hierarchy, assign indices, write the results to a JSON file, and print the file path via Logcat.
    - The Python tool polls Logcat to get the file path, then pulls the JSON file via ADB, parses it, and returns it as an observation result to the Agent.
  - Execute Device Operations: If the action is tap, swipe, input_text, etc.:
    - The Python tool looks up the element in the cache (if it's tap(index=...)), calculates coordinates, or constructs a command.
    - It sends the corresponding input or am shell command directly to the device via ADB.
    - It returns a message of operation success or failure as the observation result.
  - Complete Task: If the action is complete, the task is marked as completed.
- Observation: The Agent receives the result of the action execution (UI data or operation status).
- Loop/End: If the task is not completed and the maximum number of steps has not been reached, return to the "thinking" stage with the new observation result; otherwise, end the loop.
Result Output: The CLI displays the execution process or final result to the user.

Next, let's look at the code for these two parts to understand their working mechanisms.

Droidrun (Python Agent)

This Python package is the core control end (analogous to the brain and hands) of the Droidrun system, responsible for:

Agent Logic Implementation: Contains intelligent decision-making and task execution processes.
Device Interaction Tools: Provides tools for communicating with and controlling Android devices, mainly relying on ADB and the Droidrun Portal application.
Command Line Interface: Provides an entry point for user interaction with the Agent.

Key Points of Core Components:

adb Package:

- Provides **asynchronous** encapsulation and execution of standard `adb` commands (such as `shell`, `pull`, `install`).
- The `Device` class represents a device, encapsulating specific operations such as `tap`, `swipe`, `input_text`, `take_screenshot`, etc., which are ultimately completed by executing the corresponding `adb shell` commands.
- `DeviceManager` is used to manage multiple device connections.

tools Package:

- **Key Interface:** This is the **main bridge** between the Python Agent and the Android Portal application.
- **UI Perception (`get_clickables`/`get_all_elements`):**
    - **Triggers** the Portal application to scan the UI via `adb shell am broadcast`.
    - **Core Interaction Mechanism:** Polls `adb shell logcat -d` to **listen** for logs printed by Portal containing the JSON file path.
    - After obtaining the path, uses `adb pull` to **pull** the JSON file from the device.
    - Parses the JSON (processes the nested structure to **flatten** it), and **caches** the results (`CLICKABLE_ELEMENTS_CACHE`).
- **UI Operations (`tap`, etc.):**
    - `tap` (based on index) looks up elements in the cache, calculates coordinates, and ultimately executes `adb shell input tap`.
    - Other actions (`swipe`, `input_text`, etc.) are wrappers around `adb.Device` methods, with added error handling and specific logic (such as escaping and chunking for `input_text`).
- **`complete` Tool:** Used by the Agent to indicate to the ReAct loop that the task has been completed.
- Depends on the `DROIDRUN_DEVICE_SERIAL` environment variable to specify the target device.

agent Package:

- **Core Logic:** Implements the **ReAct (Reasoning + Acting)** agent pattern.
- `LLMReasoner`: Encapsulates interaction with LLMs (OpenAI, Anthropic, Gemini), responsible for building detailed **system prompts** (with tool signatures) and user prompts (with history), handling API calls (supporting **visual input**), parsing JSON returned by LLMs (`thought`, `action`, `parameters`), and tracking token limits.
- `ReActAgent`: **Orchestrates the ReAct loop**, maintains execution step history (`ReActStep`). Its `run` method drives the entire process: call `LLMReasoner` to think -> record thought/action -> call `execute_tool` to execute action -> record observation result -> check if completed. `execute_tool` maps the action name returned by the LLM to a function in `tools.actions` and executes it.

cli Package:

- Uses the `click` library to provide a command-line interface.
- The `run` command is the main entry point, responsible for parsing parameters, setting the **device serial number environment variable**, and launching the `ReActAgent`.
- Provides auxiliary commands for device management (`devices`, `connect`) and Portal application installation/setup (`setup`).

ReAct Mechanism

ReAct (Reasoning + Acting) is a core working mode used by DroidRun to control Android devices. It allows AI to complete complex automation tasks by combining thinking and action, similar to how humans work.

Core Idea: ReAct mimics the human problem-solving cycle.

Reasoning: AI (LLM) analyzes the task goal (like "open settings and enable dark mode"), combines it with the current screen state, and thinks about what needs to be done.

Acting: AI chooses a specific action (like "click the 'Display' button") and executes it on the Android device through tools.

Observing: AI sees the result after executing the action (like the screen jumping to the display settings page).

Think again...Act again...: AI continues to think about what to do next based on the observed results, until the task is completed.

The ReAct Loop in DroidRun:

Set Goal: The user provides a natural language task.

Reason: The LLM analyzes the task and current screen to decide on steps.

Choose Action: The Agent selects an available action (such as click, input, swipe, analyze UI elements).

Execute: Execute the action on the Android device.

Observe: The Agent obtains the execution result (such as new screen content).

Reason Again: The Agent evaluates progress and decides on the next step.

Repeat until the task is completed or the maximum step limit is reached.

Key Features (in DroidRun):

Available Actions: Include UI interaction (click, input), application management (launch, install), UI analysis (get elements), and task management (complete).

Visual Capabilities (Optional): When vision=True is enabled, the Agent can analyze screenshots to better understand complex or non-standard UIs.

Token Tracking: Records Token consumption in LLM interactions for cost management and performance optimization.

Step Recording: The Agent records the type of each step (thinking, action, observation, etc.) for easy tracking and debugging.

It's worth mentioning some details about the Agent package in the DroidRun Python library:

Multi-LLM Support: The LLMReasoner class encapsulates OpenAI, Anthropic, and Gemini API calls.

Prompt Engineering: Carefully designed system prompts guide the LLM to analyze UI, think step by step, select tools, and return strict JSON.

Multimodal Capabilities (Optional): Supports the take_screenshot tool and passes image data to vision models (like GPT-4o, Claude 3). Screenshots serve as supplementary information for handling scenarios that the accessibility API cannot cover (games, custom drawing, WebView internal details, disambiguation).

History Recording and Truncation: Maintains ReAct step history and implements simple token budget truncation.

Tool Abstraction: The LLM only needs to output tool names and parameters, and ReActAgent is responsible for calling the specific implementations in tools.actions.

Simply put, ReAct allows the AI agent to complete tasks on Android devices step by step, like a person with a brain who can act, observe, and reflect.

Droidrun Portal (Android Application)

This Android application is the perception layer (analogous to eyes and ears) of the Droidrun system, with the main functions:

Core Mechanism: Runs as an Accessibility Service, using system APIs to read screen UI structure without screenshots or root access.
UI Scanning: Periodically (not responding in real-time to each event) scans the UI elements of the current active window (AccessibilityNodeInfo tree).
Element Processing:
- Extracts information of visible elements (boundaries, text, class name, ID).
- Builds parent-child hierarchy based on spatial containment relationships.
- Assigns sequential indices (clickableIndex) to interactive/text elements for reference by the Python Agent.
Data Provision:
- When receiving commands (such as GET_ELEMENTS) sent by the Python Agent via ADB broadcast:
  - Serializes the processed UI element list (including hierarchy) into nested JSON.
  - Writes the JSON to a file on the device.
  - Key Point: Prints (Logs) the path of the JSON file through Android Logcat, informing the Python Agent where to get the data.
Visualization (Optional): Provides visual feedback through OverlayManager by drawing rectangles with indices and heat map colors (based on detection time) as overlay layers on the screen.
Data Model (ElementNode.kt): Defines the structure for storing UI element information.
Configuration: Declares services and required permissions/capabilities through AndroidManifest.xml and the accessibility service configuration file.

Simply put, Droidrun Portal is an "assistant" running on an Android device that uses the accessibility service to "see" the content on the screen, organizes it into structured JSON data, and then tells the Python Agent where the data is hidden through an "agreement" (file path in Logcat). It can also optionally draw frames on the screen to show what it sees.

Foundation of the AgentKit Vision: Cross-Platform Capabilities of AccessKit

Droidrun appears (I haven't run it locally) to run smoothly on Android phones, but from a universality perspective, it has obvious limitations. It is precisely these limitations that inspired me to continue thinking about AgentKit, a universal cross-platform, cross-device AI automation kit.

One of the huge challenges in implementing cross-platform AI automation is the vastly different accessibility APIs, UI frameworks, and development languages across platforms.

Fortunately, in the Rust ecosystem, there is AccessKit, a cross-platform accessibility infrastructure library based on Rust, designed to solve the above challenges and provide an ideal foundation for AgentKit.

Its design inspiration partly comes from Chromium's multi-process accessibility architecture, adopting a push model: UI toolkits actively push complete accessibility tree information and subsequent incremental updates to AccessKit's platform adapters, rather than waiting for adapters to pull on demand. This model is particularly suitable for toolkits that render UI elements themselves (including immediate mode GUI). Some of AgentKit's code (especially design concepts and data structures) also comes from Chromium.

As a bridge between UI toolkits and native platform APIs, AccessKit's core abstractions are as follows:

Data Model: Defines a set of data structures (nodes, roles, attributes, states, etc.) to describe the UI element hierarchy tree (Accessibility Tree). This model is platform-independent.
- common (accesskit crate): Defines platform-independent UI tree data models (Node, Role, Action, TreeUpdate) and geometric types.
- consumer (accesskit_consumer crate): Maintains complete tree states, handles updates, provides high-level APIs (traversal, query).
Push Model: UI toolkits actively push complete initial tree states and subsequent incremental TreeUpdate to adapters. Adapters maintain internal states, directly responding to AT queries without frequent callbacks to applications. This is in contrast to the "pull model" of traditional AT APIs.
- Advantages: Decoupling, good performance (especially for immediate mode GUI), asynchronous-friendly (default support for async-io and providing tokio optional features to adapt to different asynchronous runtimes).
Platform Adapters (platforms/* crates): Bridge the AccessKit model to native APIs (Windows UIA, macOS NSAccessibility, Unix AT-SPI, Android Accessibility Framework).
Cross-Language Support: The core library is implemented in Rust, bringing memory safety, high performance, zero-cost abstraction, concurrency safety, excellent FFI, and cross-platform compilation capabilities. It also provides bindings for languages like C and Python to facilitate integration with non-Rust toolkits.

Pull Model vs Push Model

Pull Model: This is a traditional or more direct approach. Imagine a screen reader (or other assistive technology, AT) wants to know the name of a button. It sends a request to your application through the platform's accessibility API: "Please tell me the name of the button with ID X." Your application (or UI toolkit) receives this request, looks up the corresponding information, and returns the name to the platform API, which eventually passes it to the screen reader. In this model, the information flow is actively pulled by the AT or platform API.

Push Model: AccessKit adopts this approach. Your application (or UI toolkit) doesn't wait for passive queries but actively pushes the entire or partial state of the accessibility tree to AccessKit's platform adapter. When the UI changes, your application calculates the differences and pushes these changes to the adapter again. The platform adapter is responsible for maintaining a complete, up-to-date internal representation of the accessibility tree. When a screen reader queries information through the platform API (e.g., "What is the name of the node with ID Y?"), the platform adapter can look up and return the information directly from its own maintained tree state, usually without needing to go back and ask your application.

AccessKit's core goal is to enable UI toolkits to provide necessary information to the operating system's accessibility APIs so that various assistive technologies (ATs) can understand and manipulate the UI. These assistive technologies include but are not limited to:

Screen Readers: Such as NVDA, JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android, and Orca on Linux. They read aloud the text and UI element information on the screen, or output it to braille displays.
Screen Magnifiers: Such as Windows Magnifier, macOS Zoom. They magnify parts of the screen and may need to track focus or mouse position.
Voice Control Software: Such as Dragon NaturallySpeaking, Windows Voice Access, macOS Voice Control. Users interact with the UI through voice commands.
Switch Devices: Used for users with severe mobility impairments, scanning and selecting UI elements through one or more switches.
Tools for Reading and Writing Difficulties: May need to highlight text, change fonts or colors, etc.

AccessKit's platform adapters are responsible for effectively conveying this information to each platform's native APIs and assistive technologies, thereby simplifying the implementation of cross-platform accessibility.

So, compared to Droidrun Portal, both can provide structured UI perception capabilities, but AccessKit is cross-platform and provides a more general abstraction model, while Droidrun Portal is limited to Android.

Therefore, it's clear that AccessKit's key to implementing universal AI automation control is:

Structured and Semantic UI Understanding: Provides deeper interface understanding (roles, states, attributes, relationships) than screenshots.
Standardized Interaction Interface: Defines a unified Action enumeration, providing a stable programming interface for simulating interactions.
Cross-Platform Consistency: Core models and action definitions are consistent across platforms, facilitating the reuse of control logic.

For applications that have integrated AccessKit, it provides an extremely ideal foundation for perception and control. AI Agents can:

Precise Perception: Understand UI structure, element roles, states, and attributes by querying the AccessKit tree.
Reliable Execution: Execute interactions by requesting standard AccessKit Actions.
Cross-Platform Operation: Reuse most control logic.

Of course, there is a prerequisite here: the target application must integrate AccessKit. For applications that haven't integrated it, AI Agents still need to rely on other technologies (native APIs, visual automation, etc.).

For applications built using AccessKit, AccessKit provides an extremely powerful and ideal infrastructure for AI Agents to perceive and control. It provides a structured, semantic, cross-platform, and relatively stable way to understand UI states and execute interactive actions, which has clear advantages over many existing automation technologies (especially visual automation).

However, its biggest limitation is the adoption rate of applications. Currently, AccessKit is still a relatively new project, and there aren't many UI toolkits and applications that have adopted it. Therefore, a universal AI Agent aimed at controlling arbitrary desktop or mobile applications cannot widely rely on AccessKit yet and must have the capability to use other automation strategies. But as the AccessKit ecosystem develops, it has the potential to become a very valuable tool in the AI control field.

AgentKit: Universal AI Automation Framework Concept

Based on the powerful foundation provided by AccessKit, we can envision a grander, more universal AI control framework—AgentKit. AgentKit's goal is to become a modular, extensible AI automation solution for all platforms.

AgentKit Architecture Macro Overview

AgentKit's design philosophy is layered, modular, and framework-agnostic:

┌─────────────────────────────────────────────┐
│                  AI Agent                   │
│  (LLM/Model, Task Planning, Decision Logic - Pluggable)  │
└──────────────────────┬──────────────────────┘
                       │ (Unified Instructions/States)
┌──────────────────────▼──────────────────────┐
│                 AgentKit Core               │
│ (State Management, Coordinator, Unified Action Model, Security Management)  │
└───┬───────────┬────────────────┬────────────┘
    │           │                │
┌───▼───┐   ┌───▼───┐      ┌────▼────┐
│AccessKit│  │ WebKit│      │Device  │
│ Bridge │  │ Bridge│      │ Bridge  │
└───┬───┘   └───┬───┘      └────┬────┘
    │           │                │
┌───▼───┐   ┌───▼───┐      ┌────▼────┐
│AccessKit│  │Browser/│      │ Platform │
│Adapters│  │WebView │      │Specific  │
└───┬───┘   └───┬───┘      └────┬────┘
    │           │                │
┌───▼───────────▼────────────────▼───┐
│        Applications & UIs          │
└───────────────────────────────────┘

Key Architecture Notes:

Three-Bridge Parallel Strategy:
- AccessKit Bridge: Used with priority, obtaining structured information and executing standard actions.
- WebKit Bridge: Handling Web content (browser/WebView), can execute JS. Solves WebView interaction challenges: WebView exposes internal Web accessibility trees to the system (visible to AccessKit), but JS operations are more powerful and direct. This bridge provides JS execution capability.
- Device Bridge: Handling other non-phone smart terminal devices (Raspberry Pi, Jetson, Orange Pi, and other embedded Linux platforms).
Coordinator Pattern: The Core layer dynamically selects the most appropriate bridging method and handles mixed scenarios.
Logical/Physical Separation: Prioritizes semantics-based logical actions (ClickElement), falling back to physical actions (ClickPosition) when necessary.
Efficient Data Exchange: Drawing on Droidrun experience, but using shared memory/zero-copy memory/memory-mapped files + notification mechanism to replace the file system + Logcat, improving efficiency.

A core advantage of AgentKit's design will be supporting all UI frameworks that have implemented AccessKit, including but not limited to:

Rust Native UI Frameworks:
- Makepad: Hardware-accelerated cross-platform UI framework
- Druid: Data-driven Rust UI toolkit
- Iced: Simple cross-platform GUI library
- Vizia: Declarative Rust GUI library, focusing on audio applications
- Slint: Lightweight UI toolkit, suitable for embedded systems
- Bevy UI: Game UI system based on the Bevy engine
Cross-Language UI Frameworks:
- Flutter: Can integrate AccessKit through Rust bindings
- GTK: Supported through AccessKit adapters
- Qt: Can provide support through AccessKit bridging
- wxWidgets: Can integrate AccessKit to provide cross-platform accessibility support
Experimental or Potentially Supported Frameworks in the Future:
- Xilem: Experimental Rust GUI framework
- Egui: Immediate mode GUI library
- Custom rendering engines: Custom rendering systems used by games and professional applications

For framework support, AgentKit adopts a plugin architecture, implementing flexible integration through adapter interfaces, fully leveraging the advantages of Rust language engineering capabilities.

Using `dora-rs` to Implement Automated Control of Non-Phone Smart Terminals

Enabling AgentKit to control Raspberry Pi, Jetson, and other smart devices is completely feasible and extremely valuable extension direction, which can expand AgentKit from GUI automation to a more universal AI control platform that interacts with the physical world. This corresponds to the Device Bridge part in the architecture above.

Core Mechanism:

Device-Side Nodes: Run dora-rs nodes on target smart devices, acting as device drivers/proxies, encapsulating interaction logic with specific hardware (GPIO, sensors, serial ports, etc.) or software (SDKs, APIs).
Central Brain: AgentKit Core (running on PC/server) is responsible for decision-making.
Network Bridge: AgentKit Core communicates with device-side dora-rs nodes through the network.
Standardized Data Flow: Use dora-rs message passing to standardize instructions (such as SetPinHigh, ReadTemperature), states/data (such as PinState, TemperatureReading), and capability descriptions.

Main Advantages:

Abstract Decoupling: AgentKit Core doesn't need to care about device details, only interacting with standardized interfaces.
Leveraging dora-rs Advantages: Fully utilizing its high performance, low latency, and data flow processing capabilities on embedded Linux.
Easy to Extend: Adding new devices only requires developing corresponding dora-rs nodes.
Distributed Intelligence: Can implement some local processing and control logic on the device side.
Unified Framework: Use one set of AgentKit to orchestrate complex workflows involving GUI, Web, and physical devices.

An application example can be envisioned (Raspberry Pi temperature control LED):

Raspberry Pi runs sensor_node (temperature and humidity reading node) and led_node (LED control node).
AgentKit Core (PC) instructs sensor_node to read the temperature.
sensor_node reads and sends back TemperatureReading(32.5) to Core.
Core determines the temperature is over the limit (>30) and instructs led_node to turn on the LED.
led_node executes and returns LedStatus(on).

In this way, by running dora-rs nodes on smart devices, AgentKit can reliably and efficiently extend its automation capabilities to the physical world, becoming a more powerful universal AI automation platform.

AgentKit's design has significant advantages over platform-specific solutions (like Droidrun.ai):

Truly Cross-Platform: Develop AI Agent logic once, and it can control applications on Windows, macOS, Linux, Android, iOS (through frameworks like Flutter), Web, and more.
Framework Independence: As long as the UI framework implements AccessKit (for native) or provides Web access interfaces, it can be controlled by AgentKit, allowing developers to freely choose their technology stack.
Code Reuse and Maintenance: Core AI logic and control models only need to be maintained as one set, significantly reducing maintenance costs.
Unified User Experience: Users can get consistent AI assistance or automation experiences across different devices and applications.
Leveraging Native Capabilities: Through AccessKit and Web APIs, AgentKit deeply leverages native platform capabilities, achieving precise, efficient perception and control, avoiding fragile image recognition.
Modularity and Extensibility: Can easily add support for new frameworks, new platforms, or new AI models, ensuring the system can evolve with technological developments.
Performance Optimization: Rust-based implementation provides excellent performance and memory safety guarantees, particularly suitable for real-time UI control scenarios.

AgentKit Dedicated AI Gateway Service (Optional Enhancement)

To better support cross-platform deployment, centralized management, and cloud inference capabilities, AgentKit can introduce a dedicated AI Gateway service as a bridge between clients and AI providers. This architecture is not necessary but can bring significant advantages.

Abstraction and Unification: Provides clients with a single, stable API interface, shielding differences and changes in underlying AI providers (OpenAI, Anthropic, Gemini, etc.). Clients don't need to adapt to multiple API formats and authentication methods.
Intelligent Routing and Load Balancing: Automatically selects the most appropriate AI provider or model for inference based on request type (such as requiring visual capabilities), real-time load, cost, provider health status, and other factors.
Security Enhancement: Centrally manages API keys for all AI providers, eliminating the need for clients to directly store these sensitive credentials, reducing the risk of leakage. The Gateway is responsible for authenticating client identity.
Request Optimization and Transformation:
- Compression: Intelligently compresses large data such as UI snapshots and history records, reducing network transmission volume.
- Format Conversion: Converts AgentKit's internal request format to the format required by specific AI providers.
- Context Management: May intelligently truncate or summarize too-long history records.
Response Caching: Caches deterministic or high-frequency requests (e.g., requests with low temperature settings) to avoid repeated calls to expensive AI APIs, reducing costs and latency.
Monitoring, Analysis, and Billing: Centrally collects metrics such as API call count, Token consumption, latency, error rate, facilitating analysis of performance, cost, user behavior patterns, and enabling unified billing.
Rate Limiting and Quota Management: Implements unified rate limiting and quota management for clients to prevent abuse.

The AI Gateway system architecture design is roughly as follows:

┌───────────────────────┐
│   AgentKit Client     │
│  (Windows, macOS,     │
│   Linux, Mobile)      │
└───────────┬───────────┘
            │
            │ HTTPS / WebSockets (Encrypted Communication)
            │ (AgentKit Client <-> Gateway)
            ▼
┌───────────────────────────────────────────┐
│             AgentKit AI Gateway           │
│                                           │
│  ┌─────────────┐      ┌─────────────────┐ │
│  │ Authentication  │◀────▶│ Request Routing &  │ │
│  │ & Authorization │      │ Load Balancing  │ │
│  │ (Client Auth)│      └───────┬─────────┘ │
│  └──────┬──────┘              │           │
│         │                      │           │
│         ▼                      ▼           │
│  ┌─────────────┐      ┌─────────────────┐ │
│  │ Request Optimization  │──────▶│ Response Cache  │ │
│  │ & Transformation  │      └───────┬─────────┘ │
│  └──────┬──────┘              │           │
│         │                      │           │
│         ▼                      ▼           │
│  ┌─────────────────┐  ┌─────────────────┐ │
│  │ AI Provider I/F │  │ Monitoring &     │ │
│  │ (Unified Interface) │  │ Analysis      │ │
│  └──────┬──────┘      └─────────────────┘ │
└─────────┼─────────────────────────────────┘
          │ HTTPS (Gateway <-> AI Provider)
          │ (Including Provider API Key)
          ▼
    ┌────────────┐┌────────┐┌───────────────┐
    │ OpenAI API ││Claude  ││Other AI Providers │
    └────────────┘│  API   │└───────────────┘
                  └────────┘

Core Component Implementation (Conceptual Explanation)

Authentication and Authorization Module: Verifies client API Key or Token, manages client permissions.
Request Routing and Load Balancing: Selects backend AI Provider based on rules (such as request characteristics, provider status, cost).
Request Optimization and Transformation: Implements compression, format adaptation, context processing logic.
Response Cache Management: Uses Redis or memory cache to store cacheable responses.
AI Provider Interface: Defines a unified trait AiProvider, and implements specific adapters for each provider, encapsulating their API calls and key management.
Monitoring and Analysis: Integrates Prometheus/Grafana or similar systems to record key metrics.

AgentKit and Claude MCP / Google A2A Protocols Complementary Collaboration

Recently, MCP and A2A, these two AI Agent-related protocols, have started to become popular. So I think it's necessary to compare them.

First, let's clarify the core problems that each of these three technologies solves:

Technology	Core Positioning	Main Problem Solved
MCP (Anthropic) Protocol	Tool Connection Layer	"How AI can call external tools and data sources"
A2A (Google) Protocol	Agent Collaboration Layer	"How different AI agents can securely communicate with each other"
AgentKit (Tool)	UI Interaction Layer	"How AI can perceive and operate user interfaces across platforms"

Relationship Analysis Between AgentKit and MCP

MCP provides a standardized way to connect AI models with external tools, while AgentKit focuses on providing cross-platform UI control capabilities. This relationship is naturally complementary.

MCP can handle "tool calls" (such as getting weather, searching for information, accessing files), while AgentKit handles "UI interactions" (such as clicking buttons, inputting text, parsing interface structures).

AgentKit can serve as an MCP tool provider. AgentKit can be implemented as an MCP server, providing a standardized set of UI interaction tools. For example:

# Example of AgentKit implemented as an MCP service
from mcp.server.fastmcp import FastMCP

# Create MCP server
mcp = FastMCP("AgentKit UI Automation")

@mcp.tool()
def click_element(element_id: str) -> bool:
    """Click a UI element with the specified ID."""
    # AgentKit internal implementation of cross-platform clicking
    return agent_kit.bridges.coordinator.execute_action(
        AgentAction.ClickElement(element_id=element_id)
    )

The serious security challenges that MCP currently faces (such as tool poisoning attacks) also provide important warnings for AgentKit:

Tool Isolation: AgentKit needs to implement a sandbox-like mechanism to limit the permission scope of UI interaction operations
Clear Permission Model: AgentKit should adopt fine-grained permission control, distinguishing between reading UI (low risk) and executing operations (high risk)
Secondary Confirmation Mechanism: Key operations (such as submitting forms, deleting content) should require explicit user confirmation

Relationship Analysis Between AgentKit and A2A

The A2A protocol focuses on collaboration and communication between AI Agents, while AgentKit focuses on UI interaction capabilities, which are also highly complementary. AgentKit can be implemented as an A2A-compatible agent, dedicated to handling UI interaction tasks, thereby enhancing AI Agent division of labor and collaboration. A2A's security mechanisms (such as AgentCard, authentication) can also enhance AgentKit's security.

For example:

// Example of AgentKit as an A2A agent's AgentCard
{
  "name": "UI Interaction Agent",
  "description": "Specialized in cross-platform user interface interaction",
  "provider": {
    "organization": "AgentKit.org"
  },
  "skills": [
    {
      "id": "ui_discovery",
      "name": "UI Element Discovery",
      "description": "Discover and analyze interactive elements on the interface"
    },
    {
      "id": "ui_interaction",
      "name": "UI Element Interaction",
      "description": "Interact with interface elements (click, input, etc.)"
    }
  ],
  "authentication": {
    "schemes": ["bearer"]
  }
}

AgentCard: A public metadata file in the A2A protocol (usually located at /.well-known/agent.json), describing the agent's capabilities, skills, endpoint URLs, and authentication requirements. Clients use this file for discovery.

Three-Layer Architecture Integration Scheme

Based on the above analysis, a three-layer architecture integrating MCP, A2A, and AgentKit can be constructed:

┌─────────────────────────────────────────┐
│              A2A Collaboration Layer    │
│  (Agent Coordination, Task Assignment, Secure Communication)  │
└───────────────────┬─────────────────────┘
                    │
┌───────────────────▼─────────────────────┐
│              MCP Tool Layer             │
│  (Standardized Tool Calls, Resource Access)  │
└─────────┬─────────────────────┬─────────┘
          │                     │
┌─────────▼────────┐   ┌────────▼─────────┐
│   AgentKit UI Layer  │   │  Other Specialized Tools  │
│  (Cross-platform UI Interaction)  │   │  (Search, Calculation, etc.)  │
└──────────────────┘   └──────────────────┘

In this architecture:

The A2A Layer handles task assignment and collaboration between agents
The MCP Layer provides a standardized tool calling interface
The AgentKit Layer serves as a specialized tool for MCP, providing cross-platform UI interaction capabilities

Conclusion

Above is my technical vision for AgentKit, a universal AI automation framework (or kit).

We are in an era where AI technology is profoundly influencing human-computer interaction. I foresee that future applications will not be completely replaced by AI, but will form a diversified interaction ecosystem: AI agents, traditional graphical applications, and hybrid systems that combine both will coexist.

User experience will also become layered: at the high level, users can conveniently express their intentions through natural language; at the low level, AI is responsible for translating intentions into specific operations, and when necessary, calling appropriate graphical interfaces for users to perform fine control or receive intuitive feedback.

This evolutionary trend highlights the need for new infrastructure. My AgentKit concept is deeply inspired by Droidrun.ai's exploration of automation on the Android platform. Droidrun.ai's practice verifies the feasibility of AI-driven device control but also exposes its single-platform limitations.

Therefore, the core goal of AgentKit is to transcend platform silos and achieve truly unified cross-platform automation. The key technical support for this vision is AccessKit. It provides a standardized, cross-platform accessibility interface that allows AI Agents to "understand" and "operate" user interfaces under different operating systems and application frameworks in a consistent way.

Through this technical vision of AgentKit, I see a clear possible path for AI-driven automation to move from platform silos to cross-platform unification. Rust's safety, performance, and cross-platform capabilities, combined with AccessKit's unified accessibility interface and the understanding capabilities of modern LLMs, together provide a solid technical foundation for this vision.

Thank you for reading.

Moly: An Open-Source LLM Client Implemented in Pure Rust

Alex — Wed, 01 Jan 2025 17:16:19 +0000

Moly is an AI LLM client written in Rust. As a flagship application project of Robius, it demonstrates the powerful development capabilities of Makepad UI and Robius.
Currently, Moly supports Mac/Linux/Windows platforms, and will support iOS and Android mobile platforms in the near future.
You can follow the instructions at https://github.com/moxin-org/moly to install and use Moly.

Introduction to Moly's Basic Features

Discovering Models

The initial interface displays a list of locally supported Featured Agents and Models. Note that if your version doesn't support Agents yet, you won't see Featured Agents content.
You can choose to download the open-source model that suits your machine configuration. Click the arrow in the bottom right corner of the window to expand and view the current model's download status. You can also pause or delete models that are being downloaded.

When you scroll down the window page, a Sort By dropdown list will appear in the top right corner of the window. You can sort the model list according to your needs.

You can also directly search for the model you want through the search bar at the top of the window.

Managing Downloaded Models

You can click the My Models Tab in the left operation bar to manage your downloaded models.

Click the 'i' icon in each row of the model list to view detailed information about the model.

Click 'Show in Finder' to view the model download directory.

Click 'Change Download location' to modify the download directory path.

Chatting with AI

Click the Chat Tab in the sidebar to bring up the chat window. Click the arrow button at the top of the window to select your currently downloaded large model.
Of course, you can also open this window by clicking the 'Chat with Model' button in the local large model list managed in the My Models Tab.

In the chat input box at the bottom of the window, you can directly ask questions to your chosen large model.
You can also use the '@' operation to bring up a selection box to choose the large model or Agent you want to converse with.

Then you can have a conversation with it.

Click the collapse icon in the top left corner of the window to hide the 'CHATS' chat window list on the left. Click again to expand it.

Similarly, clicking the arrow collapse button in the top right corner of the window will bring up the 'Chat Setting' window, where you can configure the large model's System Prompt and parameters according to your needs.

System Configuration

Click the 'Setting' button in the bottom left corner of the sidebar to open Moly's system configuration window.

Currently, you can modify the backend large model service port. You can also add a new MoFA Agent service.

How Moly Drives Makepad's Evolution

As Robius's flagship application, Moly's role is also to promote the evolution of the Makepad UI framework. Let's use the evolution of two Makepad basic Widgets as examples to illustrate.

Modal Widget

Earliest discussions (early October):

Jmbejar proposed a new Modal design approach - "Modal deref" mode, inspired by practical experience from the Moly project. The main advantages are:
- Modal content can be implemented as an independent widget rather than as a Modal child component
- Simplifies how developers implement complex modal content without needing to consider parent-child component communication
- Follows the deref pattern commonly used in makepad View widget
Kevin raised some considerations about this design:
- The current Modal design only requires developers to correctly handle dismissed action
- The new design requires developers to implement more interfaces (open, close, capture actions, etc.)
- Need to balance whether it increases the burden on novice developers

Problem evolution (mid-October to November):

Some visual issues were discovered in actual use:
- Modal background content "leakage"
- Random text highlighting
- Issues particularly when using Modal + Dock combination

Latest improvement direction (mid-November):

Julian proposed the draw_depth propagation solution:
- Pass draw_depth to child components through Scope
- Child components use larger draw_depth values when drawing
- This approach may solve visual overlay issues

In summary, Moly project's improvements to Makepad Modal widget are mainly reflected in:

Architecture design level: Provided the "Modal deref" design approach, making component structure clearer
Practical verification: Discovered and solved problems in actual applications through use in Moly
Development experience: Promoted discussion of developer friendliness, balancing flexibility and ease of use

This case demonstrates how Moly, as a Makepad practical project, drove improvements and evolution of the underlying widget system.

Sliding Panels Widget

Initial state and requirements of the sliding panels component:

Makepad already had a basic ExpandablePanel component (widgets/expandable_panel.rs), which was actually used in the Wonderous project's timeline_screen.rs. This laid the foundation for subsequent sliding panel development.

A key turning point in evolution emerged when developers proposed a new use case: Kevin wanted to implement an overlay panel that slides in from the right side to display user profile information. This requirement had several important characteristics:

The panel needs to be presented as an overlay layer
Sliding in should not change the size of the main content area
This functionality needs to combine features from Moly project's FadeView and Modal

This requirement prompted the development team to rethink the sliding panel design.

It's particularly noteworthy that this evolution process was significantly influenced by the Moly project. Moly's FadeView and Modal components provided important reference implementations for Makepad, demonstrating how to combine animation effects and overlay layers. This again shows how Moly, as a practical project, drives the advancement of the Makepad widget system.

Overall, the evolution of sliding panels reflects the maturation process of the Makepad UI framework driven by practical applications - developing from basic functional components into a complete, unified interaction design language. In this process, the Moly project played a crucial catalytic role, guiding Makepad's development direction through providing practical experience and mature implementations.

Future Development

Moly has currently added Agent support in the dev branch. This Agent capability is obtained through integration with MoFA.
If you're interested, you can follow the configuration described here to run Moly and MoFA to try the Agent features shown earlier.
Moly will add more Agent tools through MoFA in the future.
Additionally, Moly is considering deep integration with Moxin LLM. Moxin LLM is a truly open-source large model that fully complies with the Model Openness Framework (MOF).
Finally, Moly will also support iOS and Android mobile platforms.

Learning Rust You Need a Cognitive Frame

Alex — Fri, 08 Apr 2022 03:55:32 +0000

Preface

If learning Rust feels hard, painful or confusing, you might want to read this article. But if you feel comfortable learning Rust, then this article is useless to you and can be ignored.

Although there is a wealth of Rust learning materials available, Rust is a relatively expensive language to learn. The cost of learning varies slightly for people with different language experience.

Although there is a wealth of Rust learning materials available, Rust is a language with a relatively high learning curve.The cost of learning varies slightly for people with different language experience.

Before learning Rust, You need to know what the mental cost of learning Rust will be.

People with zero foundation need to make up some necessary computer science related fundamentals as well as build an understanding of programming. Beginning to learn programming is a big challenge in itself.

People who have some basic programming skills can be a bit of a hindrance to learning Rust, although it can be helpful.

People with only C experience have the following challenges when learning Rust:

Rust programming paradigm. The C language is procedural, while Rust is a hybrid programming paradigm that supports both object-oriented and functional programming styles. It is easy for someone coming from C to write Rust in a procedural style, and while it is possible to write full functionality in Rust in a procedural style, the advantages of Rust are lost in the code architecture. Concepts related to programming paradigms: generics / trait / error handling /structs / enums.
Ownership and borrowing checks. C manages memory manually, but Rust manages it with ownership. C uses pointers, but in Rust, pointers are abstracted safely to references, requiring borrow checks. These are the concepts that C developers must master.
Unsafe Rust safe abstraction. C developers need to understand the Unsafe Rustcoding specification and how to do safe abstraction, which is important, especially when calling each other with C.
Macros. Rust declaration macros similar to the C language declaration macros, are code replacement, but more powerful than C, these should also be considered a learning challenge. rust there are more powerful procedural macros, you can learn in the early stages of learning without considering, and then learn later.

People with Cpp experience, who by default have some knowledge of C, have the following challenges when learning Rust.

Rust programming paradigm. The hybrid paradigm of Rust is different from Cpp. Rust is not a pure object-oriented language and does not have constructors. the generics, traits, enumerations, and error handling in Rust are also important for Cpp developers to learn.
Ownership and borrowing checks. Because Rust also introduces the same RAII-based smart pointers as Cpp, memory management is easier to understand for those with experience in Cpp 11 and above. However, Cpp developers with no experience in this area will have some difficulty.
Unsafe Rust safe abstraction. This is the same as for beginners from C. It requires some understanding of the Unsafe Rust coding specification.
Generic and Procedural Macros. Cpp developers have templates, but Rust has generics, which are not as powerful as Cpp templates, but have procedural macros to compensate. That is, Cpp template programming is equivalent to a combination of Rust's generics and procedural macros. If Cpp developers want to pursue the effects of templating in Rust, then they need to master generics and procedural macros.

People with only experience in GC languages, such as Java, Python, Ruby, Haskell, etc., face essentially the same challenges in learning Rust as Cpp, but the learning curve is much steeper because most people using the GC language do not have a deep enough understanding of the underlying memory management.

Thus, the steepness of the learning curve for Rust has to do not only with the complexity of the language itself, but also with each individual's programming base.

Rust Cognitive Frame

Once you realize the root cause of the Rust learning curve, you will find that your previous programming knowledge does not transfer smoothly to learning the Rust language.

So, you need a general learning framework that you can follow to create a learning plan to combat this learning curve and get started with Rust and keep learning.

This learning frame is simple, and requires only two things to understand.

First, don't be in a hurry, keep a beginner's mindset, and treat it in stages.
Second, at each stage of the learning process, do not just have input, but also maintain the output.

It is said to be a learning frame, but it is actually a cognitive frame. Next, let's look at the specifics.

Learning Rust in stages

For those who have some basic programming skills, there are at least three stages to learning Rust.

Learn the Rust syntax as a whole. Get a good understanding of the Rust syntax and language features.
Rust basic ownership concepts need some deep understanding.
Deep domain learning. After the above two phases are completed, you can put the domain into practice and learn it further in depth.

Stage I: Comprehensive Understanding of the Rust Syntax

The goal of this first phase is to gain a comprehensive understanding of the Rust syntax.

What do you need to do?

Gain a more comprehensive understanding of the Rust syntax.
Classify the Rust syntax.

This phase is not for you to learn Rust in one go, so don't get too bogged down in what you don't understand, and allow yourself to keep a list of questions if you don't understand it for a while. The focus of this phase is to gain a comprehensive understanding of the Rust syntax and build a syntax structure in your mind, with a focus on categorization. The syntax should be sorted into categories. For example, data types, control flow, structures, traits and generics, macros, etc., and what each of them does.

Recommended Study Materials for Stage I

The Rust Programming Language
The Rust Cargo Book
Others, free or paid introductory Rust materials.

When looking at these materials, you should focus on the first stage of learning: a comprehensive understanding of the Rust syntax.

Once you have a basic understanding of the Rust syntax, you can test yourself with the official Rust by example and Rustlings to test the results of your learning.

Recommended practice projects for stage II

There are some misconceptions about the choice of first-stage practice projects, and many people like to use Rust to solve algorithmic problems to learn Rust. But in fact, the learning effect is not good.

Because of Rust ownership restrictions, it is not as flexible and free as other languages for implementing some algorithms and data structures. If you don't have a deep understanding of Rust ownership, it's easier to give up on Rust when you encounter difficulties in solving problems, and it's not easy to stick with it.

So at this stage, it is better to do projects that give you a sense of accomplishment. The general principle is: combine your own experience in your domain, choose simple projects to start.

Here are some recommended practice projects.

Combine the official Command Line Apps in Rust book to implement a simple terminal application, such as reading a CSV file or something.
Go to the GitHub open source repository for case inspiration.
1. for example, implement a terminal typing practice application like toipe.
2. or a simple editor like kyun .
Others.

Stage II: Mastering Key Concepts of the Rust Language

Once you have achieved the learning goals of stage 1, you are ready to begin stage 2.

The goal of stage 2 is to master the key concepts of the Rust language. The following concepts are covered:

Ownership and borrowing checks.
Type systems and programming paradigms.
Unsafe Rust and macros.

The focus is on Ownership and Borrowing checks. Only after mastering these two concepts can you get started with the Rust language. The other concepts can be mastered gradually as you work on projects, but you can't be ignorant of them.

Recommended Study Materials for Stage II

《Rust for Rustaceans》
《Programming Rust, Second Edition》
Rust Design Patterns
Rust Standard Library Documentation
Too Many lists
other advanced Rust books, and free or paid learning materials.

It is not necessary to read all of the materials recommended here. you can focus on "Ownership and borrowing checks" in depth. then go through the concepts of "Type Systems and Programming Paradigms", "Macros", and "Unsafe Rust", and also dive into the concepts of Rust design patterns. After that, take the time to read the Rust standard library documentation in depth to understand the Rust coding specification.

After the above, you'll have a good foundation to put Rust into production practice.

Recommended practice projects for stage II

Combine your experience in your domain of expertise and choose simple projects, starting from the simple to the deep.

At the same time, you can also start reading the source code of some of the better-known projects to start learning.

At this point, you can read 《Too Many Lists》 to implement a linked list, or you can solve LeetCode to test your understanding of the Rust ownership mechanism.
GitHub project for inspiration, for example:
- smallvec
- toydb
- Others.

Stage III : Deep into the real-world domain

After the above two stages of learning, learners can commit to their own real-world projects and start learning. If they do not have their own real projects, they can participate in the open source project contributions.

This process is a long-term process of learning and applying Rust. For example, Rust concurrency and asynchronous development-related content, key concepts about type systems, programming paradigms, macros, and in-depth learning and application of Unsafe Rust are all done in this stage.

Keeping up with input and output

The learning process is about maintaining a balance between input and output.

What do I mean by input? Drawing various knowledge from various learning resources is called input.

Output can take many forms. Writing an article, participating in a project, or doing a sharing are all outputs.

Only when input and output are kept in a cycle will the human brain be in thinking mode and what you input will be precipitated into structured memory.

So, in addition to input, you have to keep yourself in output during the above learning phase. That way your energy and time will not be wasted.

Two diagrams showing the current Rust network ecosystem

Alex — Tue, 10 Aug 2021 04:37:16 +0000

Today I drew two diagrams to show the current Rust Web ecosystem.

tokio ecosystem

As you can see from the diagram, the tokio ecosystem is now complete with the basic core components for web services and web development. Especially with the introduction of the Axum framework, tokio is close to being complete in the Web ecosystem.

Axum's middleware uses the tower abstraction directly, which has the following advantages:

the use of a unified Service and Layer abstraction standards, to facilitate everyone to prosper the ecology
reuse the tokio / hyper / tonic ecosystem

axum's routing mechanism does not use property macros like rocket, but provides a simple DSL (chain call). Routing is based on iterations and regular expressions to match, and routing performance should be similar to actix-web.

A convenient extractor is also provided, as long as FromRequest is implemented it is an extractor and very easy to implement.

There are also some others advantages.

In a word, Axum is, in my opinion, a milestone for Rust in the Web development field, and it strongly drives the tokio/tower ecosystem. It's not quite mature yet, but it has a lot of potential.

Others Web Frameworks

actix-web itself adds a layer of runtime threads as Actor to manage multiple threads, each thread is actually running a tokio single thread block_on , so that between the threads can not task stealing , lost the advantages of tokio task scheduling , in exchange for the performance of wireless thread context switching . This is the main difference between actix-web and other frameworks. actix-web's middleware also borrows from Tower Service, but it is not as generic as tower.

The advantage of rocket is a well-developed API, especially for handling forms very well. Unlike other frameworks, rocket has strong constraints on middleware in order to achieve security and correct goals, and it is not as free to implement middleware as Axum. This also predestines it to be more difficult to form an generic ecosystem. rocket is not performance oriented at the moment, maybe it will be optimized for performance in the future after 1.0.

How to choose your own web framework, combined with your scenario and preferences to choose it.

Rust Concept Clarification: Deref vs AsRef vs Borrow vs Cow

Alex — Tue, 06 Jul 2021 12:28:53 +0000

By HanDong Zhang

Understanding by Module

In fact, the classification by standard library will first give you a small idea of what they do.

std::ops::Deref . As you can see, Deref is categorized as an ops module. If you look at the documentation, you will see that this module defines the trait fr all the overloadable operators. For example, Add trait corresponds to +, while Deref trait corresponds to a shared(immutable) borrowing dereference operation, such as *v . Correspondingly, there is also the DerefMut trait， which corresponds to the dereferencing operation of exclusive(mutable) borrowing. Since the Rust ownership semantics is a language feature throughout , the semantics of Owner / immutable borrowing(&T)/ mutable borrowing(&mut T) all appear together.
std::convert::AsRef . As you can see, AsRef is grouped under the convert module. if you look at the documentation, you will see that traits related to type conversions are defined in this module. For example, the familiar "From/To", "TryFrom/TryTo" and "AsRef/AsMut" also appear in pairs here, indicating that the feature is releated to type conversions. Based on the naming rules in the Rust API Guidelines , wen can infer that methods starting with as_ represent conversions from borrow -> borrow, i.e, reference -> reference , and are overhead-free. And such conversions do not fail.
std::borrow::Borrow. As you can see, Borrow is categorized in the borrow module. The documentation for this module is very minimal, with a single sentence saying that this is for using borrowed data. So the trait is more or less related to expressing borrwo semantics. Three traits are provided: Borrow / BorrowMut/ ToOwned , which corresponds exactly to the ownership semantics.
std::borrow::Cow. It can be seen that Cow is also classified as a borrow module. According to the description, Cow is a clone-on-write smart pointer. The main reason for putting it in the borrow module is to use borrowing as much as possible and avoid copying, as an optimization.

std::ops::Deref

First, let's look at the definition of the trait.



pub trait Deref {
    type Target: ?Sized;
    #[must_use]
    pub fn deref(&self) -> &Self::Target;
}

The definition is not complicated, Deref contains only a deref method signature. The beauty of this trait is that it is called "implicitly" by the compiler, officially called "deref coercion ".

Here is an example from the standard library.



use std::ops::Deref;

struct DerefExample<T> {
    value: T
}

impl<T> Deref for DerefExample<T> {
    type Target = T;

    fn deref(&self) -> &Self::Target {
        &self.value
    }
}

let x = DerefExample { value: 'a' };
assert_eq!('a', *x);

In the code, the DerefExample structure implements the Deref trait, so it can be executed using the dereference operator *. In the example, the value of the field value is returned directly.

As you can see, DerefExample has a pointer-like behavior , because it implements Deref, because it can be dereferenced. DerefExample also becomes a kind of smart pointer. This is one way to identify if a type is a smart pointer, by seeing if it implements Deref. But not all smart pointers implement Deref, some implent Drop, or both.

Now let's summarize Deref.

If T implements Deref<Target=U>, and x is an instance of type T, then.

In an immutable context, the operation of *x (when T is neither a reference nor a primitive pointer) is equivalent to *Deref::deref(&x).
The value of &T is forced to be converted to the value of &U. (deref coercion).
T implements all the (immutable) methods of U.

The beauty of Deref is that it enhances the Rust development experience. A typical example from the standard library is that Vec<T> shares all the methods of slice by implemented Deref.



impl<T, A: Allocator> ops::Deref for Vec<T, A> {
    type Target = [T];

    fn deref(&self) -> &[T] {
        unsafe { slice::from_raw_parts(self.as_ptr(), self.len) }
    }
}

For example, the simplest method, len(), is actually defined in the slice module. In Rust, when executing . call, or at the function argument position, the compiler automatically performs the implicit act of deref coercion. so it is equivalent to Vec<T> having the slice method as well.



fn main() {
    let a = vec![1, 2, 3];
    assert_eq!(a.len(), 3); // 当 a 调用 len() 的时候，发生 deref 强转
}

Implicit behavior in Rust is not common, but Deref is one of them, and its implicit coercion make smart pointers easy to use.



fn main() {
    let h = Box::new("hello");
    assert_eq!(h.to_uppercase(), "HELLO");
}

For example, if we manipulate Box<T> , instead of manually dereferencing T inside to manipulate it, as if the outer layer of Box<T> is transparent, we can manipulate T directly.

Another example.



fn uppercase(s: &str) -> String {
    s.to_uppercase()
}

fn main() {
    let s = String::from("hello");
    assert_eq!(uppercase(&s), "HELLO");
}

The argument type of the uppercase method above is obviously &str, but the actual type passed in the main function is &String, so why does it compile successfully? It is because String implementsDeref.



impl ops::Deref for String {
    type Target = str;

    #[inline]
    fn deref(&self) -> &str {
        unsafe { str::from_utf8_unchecked(&self.vec) }
    }
}

That's the beauty of Deref. But some people may mistake it for inheritance. Big mistake.

This behavior seems a bit like inheritance, but please don't just use Deref to simulate inheritance.

std::convert::AsRef

Let's look at the definition of AsRef.



pub trait AsRef<T: ?Sized> {
    fn as_ref(&self) -> &T;
}

We already know that AsRef can be used for conversions. Compared to Deref, which has an implicit behavior, AsRef is an explicit conversion.



fn is_hello<T: AsRef<str>>(s: T) {
   assert_eq!("hello", s.as_ref());
}

fn main() {
    let s = "hello";
    is_hello(s);

    let s = "hello".to_string();
    is_hello(s);
}

In the above example, the function of is_hello is a generic function. The conversion is achieved by qualifying T: AsRef<str> and using an explicit call like s.as_ref() inside the function. Either String or str actually implements the AsRef trait.

So now the question is, when do you use AsRef? Why not just use &T?

Consider an example like this.



pub struct Thing {
    name: String,
}

impl Thing {
    pub fn new(name: WhatTypeHere) -> Self {
        Thing { name: name.some_conversion() }
}

In the above example, the new function name has the following options for the type parameter.

&str. In this case, the caller needs to pass in a reference. But in order to convert to String, the called party (callee) needs to control its own memory allocation, and will have a copy.
String. In this case, the caller is fine passing String, but if it is passing a reference, it is similar to case 1.
T: Into<String>. In this case, the caller can pass &str and String, but there will be memory allocation and copying during the type conversion as well.
T: AsRef<str>. Same as case 3.
T: Into<Cow<'a, str>>, where some allocations can be avoided. Cow will be described later.

There is no one-size-fits-all answer to the question of when to use which type. Some people just like &str and will use it no matter what. There are trade-offs here.

On occasions when assignment and copying are less important, there is no need to make type signatures too complicated, just use &str.
Some need to look at method definitions and whether they need to consume ownership, or return ownership or borrowing.
Some need to minimize assignment and copy, so it is necessary to use more complex type signatures, as in case 5.

Application of Deref and AsRef in API design

The wasm-bindgen library contains a component called web-sys.

This component is the binding of Rust to the browser Web API. As such, web-sys makes it possible to manipulate the browser DOM with Rust code, fetch server data, draw graphics, handle audio and video, handle client-side storage, and more.

However, binding Web APIs with Rust is not that simple. For example, manipulating the DOM relies on JavaScript class inheritance, so web-sys must provide access to this inheritance hierarchy. In web-sys, access to this inheritance structure is provided using Deref and AsRef.

Using Deref



let element: &Element = ...;

element.append_child(..); // call a method on `Node`

method_expecting_a_node(&element); // coerce to `&Node` implicitly

let node: &Node = &element; // explicitly coerce to `&Node`

If you have web_sys::Element, then you can get web_sys::Node implicitly by using deref.

The use of deref is mainly for API ergonomic reasons, to make it easy for developers to use the . operation to transparently use the parent class.

Using AsRef

A large number of AsRef conversions are also implemented in web-sys for various types.



impl AsRef<HtmlElement> for HtmlAnchorElement
impl AsRef<Element> for HtmlAnchorElement
impl AsRef<Node> for HtmlAnchorElement
impl AsRef<EventTarget> for HtmlAnchorElement
impl AsRef<Object> for HtmlAnchorElement
impl AsRef<JsValue> for HtmlAnchorElement

A reference to a parent structure can be obtained by explicitly calling .as_ref().

Deref focuses on implicitly and transparently using the parent structure, while AsRef focuses on explicitly obtaining a reference to the parent structure. This is a trade-off with a specific API design, rather than a mindless simulation of OOP inheritance.

Another example of using AsRef is the http-types library, which uses AsRef and AsMut to convert various types.

For example, Request is a combination of Stream / headers/ URL, so it implements AsRef<Url>, AsRef<Headers>, and AsyncRead. Similarly, Response is a combination of Stream / headers/ Status Code. So it implements AsRef<StatusCode>, AsRef<Headers>, and AsyncRead.



fn forwarded_for(headers: impl AsRef<http_types::Headers>) {
    // get the X-forwarded-for header
}

// 所以，forwarded_for 可以方便处理 Request/ Response / Trailers 
let fwd1 = forwarded_for(&req);
let fwd2 = forwarded_for(&res);
let fwd3 = forwarded_for(&trailers);

std::borrow::Borrow

Take a look at the definition of Borrow.



pub trait Borrow<Borrowed: ?Sized> {
    fn borrow(&self) -> &Borrowed;
}

Contrast AsRef:



pub trait AsRef<T: ?Sized> {
    fn as_ref(&self) -> &T;
}

Isn't this very similar? So, some people suggest that one of these two functions could be removed altogether. But in fact, there is a difference between Borrow and AsRef, and they both have their own uses.

The Borrow trait is used to represent borrowed data. the AsRef trait is used for type conversion. In Rust, it is common to provide different type representations for different use cases for different semantics.

A type provides a reference/borrow to T in the borrow() method by implementing Borrow<T>, expressing the semantics that it can be borrowed, rather than converted to some type T. A type can be freely borrowed as several different types, or it can be borrowed in a mutable way.

So how do you choose between Borrow and AsRef?

Choose Borrow when you want to abstract different borrow types in a uniform way, or when you want to create a data structure that handles self-contained values (owned) and borrowed values (borrowed) in the same way.
When you want to convert a type directly to a reference and you are writing generic code, choose AsRef. simpler case.

In fact, the HashMap example given in the standard library documentation explains this very well. Let me translate it for you.

HashMap<K, V> stores key-value pairs, and its API should be able to retrieve the corresponding value in the HashMap properly using either the key's own value or its reference. Since the HashMap has to hash and compare keys, it must require that both the key's own value and the reference behave the same when hashed and compared.



use std::borrow::Borrow;
use std::hash::Hash;

pub struct HashMap<K, V> {
    // fields omitted
}

impl<K, V> HashMap<K, V> {
    // The insert method uses the key's own value and takes ownership of it.
    pub fn insert(&self, key: K, value: V) -> Option<V>
    where K: Hash + Eq
    {
        // ...
    }

    // If you use the get method to get the corresponding value by key, you can use the reference of key, which is denoted by &Q here
    // and requires Q to satisfy `Q: Hash + Eq + ?Sized`
    // As for K, it is expressed as a borrowed data of Q by `K: Borrow<Q>`.
    // So, the hash implementation of Q is required to be the same as K
    pub fn get<Q>(&self, k: &Q) -> Option<&V>
    where
        K: Borrow<Q>,
        Q: Hash + Eq + ?Sized
    {
        // ...
    }
}

Borrow is a bound on borrowed data and is used with additional traits, such as Hash and Eq in the example.

See another example.



//  Can this structure be used as the key of a HashMap?
pub struct CaseInsensitiveString(String);

// It implements PartialEq without problems
impl PartialEq for CaseInsensitiveString {
    fn eq(&self, other: &Self) -> bool {
        // Note that the comparison here is required to ignore ascii case
        self.0.eq_ignore_ascii_case(&other.0)
    }
}

impl Eq for CaseInsensitiveString { }

// Implementing Hash is no problem
// But since PartialEq ignores case, the hash calculation must also ignore case
impl Hash for CaseInsensitiveString {
    fn hash<H: Hasher>(&self, state: &mut H) {
        for c in self.0.as_bytes() {
            c.to_ascii_lowercase().hash(state)
        }
    }
}

Can CaseInsensitiveString implement Borrow<str>?

Obviously, CaseInsensitiveString and str have different implementations of Hash. str does not ignore case. Therefore, Borrow<str> must not be implemented for CaseInsensitiveString, so CaseInsensitiveString cannot be used as a key for a HashMap. What happens if we force Borrow<str> to be used? It will fail due to case difference when determining the key.

But CaseInsensitiveString can be fully implemented as AsRef.

This is the difference between Borrow and AsRef. Borrow is a bit stricter and represents a completely different semantics than AsRef.

std::borrow::Cow

Look at the definition of Cow.



pub enum Cow<'a, B> 
where
    B: 'a + ToOwned + ?Sized, 
 {
    Borrowed(&'a B),
    Owned(<B as ToOwned>::Owned),
}

As you can see, Cow is an enumeration. It is somewhat similar to Option, in that it represents one of two cases, Cow here means borrowed and self-owned, but only one of these cases can occur.

The main functions of Cow are:

acts as a smart pointer, providing transparent immutable access to instances of this type (e.g. the original immutable methods of this type can be called directly, implementing Deref, but not DerefMut).
if there is a need to modify an instance of this type, or to gain ownership of an instance of this type, Cow provides methods to do cloning and avoid repeated cloning.

Cow is designed to improve performance (reduce replication) while increasing flexibility, because most of the time, business scenarios are read more and write less. With Cow, this can be achieved in a uniform, canonical form, where object replication is done only once when a write is needed. This may reduce the number of replications significantly.

It has the following key points to master.

Cow<T> can directly call the immutable methods of T, since Cow, an enumeration, implements Deref.
the .to_mut() method can be used to obtain a mutable borrow with an ownership value when T needs to be modified.
1. note that a call to .to_mut() does not necessarily result in a Clone.
2. calling .to_mut() when ownership is already present is valid, but does not produce a new Clone.
3. multiple calls to .to_mut() will produce only one Clone.
.into_owned() can be used to create a new owned object when T needs to be modified, a process that often implies a memory copy and the creation of a new object.
1. calling this operation will perform a Clone if the value in the previous Cow was in borrowed state.
2. this method, whose argument is of type self, will "consume" the original instance of that type, after which the life cycle of the original instance of that type will end, and cannot be called more than once on Cow.

Cow is used more often in API design.



use std::borrow::Cow;

// Use Cow for the return value to avoid multiple copies
fn remove_spaces<'a>(input: &'a str) -> Cow<'a, str> {
    if input.contains(' ') {
        let mut buf = String::with_capacity(input.len());
        for c in input.chars() {
            if c != ' ' {
                buf.push(c);
            }
        }
        return Cow::Owned(buf);
    }
    return Cow::Borrowed(input);
}

Of course, when to use Cow comes back to the "when to use AsRef" discussion in our previous article, there are trade-offs and no one-size-fits-all standard answer.

Summary

To understand the various types and traits in Rust, you need to take into account the ownership semantics and ponder the documentation and examples, which should be easy to understand. I don't know if reading this article has solved your doubts? Feel free to share your feedback.

DEV Community: Alex

Is Unsafe the Original Sin? A Deep Dive into the First CVE After Rust Entered the Linux Kernel

Prelude: A Predictable Controversy

Part One: What Exactly Happened with This CVE?

Background: Safe Abstraction in Unsafe Rust

The Problematic Code

Formation of the Race Condition

The Fix

Key Insight

Part Two: What Exactly Is Unsafe Rust?

unsafe ≠ Unsafety

The Five Operations unsafe Allows

Invariants: The Soul of unsafe

Part Three: Why Must the Kernel Use unsafe?

Three Hard Requirements of Systems Programming

The Linux Kernel's Special Challenges

Part Four: How to Use unsafe Correctly

Principle One: Minimize

Principle Two: Document

Principle Three: Encapsulate

Architecture Diagram: Proper Layering of unsafe

Part Five: Tools and Methods for Making unsafe Verifiable

Miri: The Gatekeeper of unsafe

Loom: The Concurrency Revealer

Sanitizers: Sentinels at FFI Boundaries

RustBelt: Formal Verification

Part Six: A Rational View of This CVE

Let the Data Speak

What Does This Bug Tell Us?

Rust's Promise Was Never "Zero Bugs"

Comparison with C

Part Seven: Responding to Rust Haters

Conclusion: Safety Isn't About Avoiding Low-Level Work, But Doing It the Right Way

Appendix: CVE-2025-68260 Technical Details

Forging the Future: My Ten-Year Journey Growing with Rust

First Encounter with Rust: The Turning Point of 2015

The Evangelism Path: From Daily Reports to Writing Books

The Birth and Impact of "The Way of Rust Programming"

Community Building: Connecting China with the World

The Founding and Reflection of "Rust Magazine"

Industrial Adoption: From Theory to Practice

Open Source Contributions: Connecting Technology and Community

Future Outlook: Continuing to Expand the Scale of Domestic Rust Developers

AgentKit: A Technical Vision for Building Universal AI Automation for Human-Computer Interaction Based on Rust

Introduction

Table of Contents

The Future of Applications in the AI Era

Analysis: Droidrun AI's Pioneering Exploration of Android Automation

Droidrun Overall Architecture and Working Principles

Droidrun (Python Agent)

Droidrun Portal (Android Application)

Foundation of the AgentKit Vision: Cross-Platform Capabilities of AccessKit

AgentKit: Universal AI Automation Framework Concept

AgentKit Architecture Macro Overview

Using dora-rs to Implement Automated Control of Non-Phone Smart Terminals

AgentKit Dedicated AI Gateway Service (Optional Enhancement)

AgentKit and Claude MCP / Google A2A Protocols Complementary Collaboration

Relationship Analysis Between AgentKit and MCP

Relationship Analysis Between AgentKit and A2A

Three-Layer Architecture Integration Scheme

Conclusion

Moly: An Open-Source LLM Client Implemented in Pure Rust

Introduction to Moly's Basic Features

Discovering Models

Managing Downloaded Models

Chatting with AI

System Configuration

How Moly Drives Makepad's Evolution

Modal Widget

Sliding Panels Widget

Future Development

Learning Rust You Need a Cognitive Frame

Preface

Rust Cognitive Frame

Learning Rust in stages

Stage I: Comprehensive Understanding of the Rust Syntax

Recommended Study Materials for Stage I

Recommended practice projects for stage II

Stage II: Mastering Key Concepts of the Rust Language

Recommended Study Materials for Stage II

Using `dora-rs` to Implement Automated Control of Non-Phone Smart Terminals