DEV Community: rust

How I Built a Counter Program in Anchor and Learned to Trust My Tests

Lymah — Sat, 20 Jun 2026 18:54:21 +0000

I spent a week building a counter program in Anchor — the Rust framework
for writing Solana programs. By the end I had two instructions, one
authorization constraint, and a test suite I could actually trust. Here
is what I built, how I tested it, and the moment I proved the tests
were real.

Start Here: The Accounts Struct

If you come from Web2, this is the part that looks the strangest:

#[derive(Accounts)]
pub struct Initialize {
    #[account(
        init,
        payer = authority,
        space = 8 + Counter::INIT_SPACE,
    )]
    pub counter: Account,
    #[account(mut)]
    pub authority: Signer,
    pub system_program: Program,
}

In a Web2 backend, your handler receives a request object and talks
to a database. On Solana, there is no database; there are accounts.
Every account your instruction needs to read or write must be declared
upfront, before the handler runs. Anchor validates them before your
code ever executes.

Here is what each field does:

counter — the account being created. The init constraint tells Anchor to make a CPI to the System Program, allocate 8 + Counter::INIT_SPACE bytes, and fund it from authority. The 8 is for the discriminator Anchor stamps on every account so the program can later verify "this is mine."
authority — the wallet signing and paying for the transaction. mut because its SOL balance is decreasing to fund the new account.
system_program — required any time you create accounts. Anchor checks that the address matches the real System Program.

The accounts struct is the schema. The handler is the logic.

The Handlers

pub fn initialize(ctx: Context) -> Result {
    let counter = &mut ctx.accounts.counter;
    counter.authority = ctx.accounts.authority.key();
    counter.count = 0;
    Ok(())
}

ctx.accounts gives you typed access to every account declared in
the struct. The handler is short because Anchor already did the hard
work: allocating the account, checking the signer, paying the rent.
Your code just sets the initial values.

pub fn increment(ctx: Context) -> Result {
    let counter = &mut ctx.accounts.counter;
    counter.count = counter.count
        .checked_add(1)
        .ok_or(error!(ErrorCode::ArithmeticOverflow))?;
    Ok(())
}

The accounts struct for increment has a constraint worth paying
attention to:

#[derive(Accounts)]
pub struct Increment {
    #[account(mut, has_one = authority)]
    pub counter: Account,
    pub authority: Signer,
}

has_one = authority tells Anchor: before this handler runs, check
that counter.authority == authority.key(). If the wallet signing
the transaction does not match the wallet stored on the counter,
the transaction is rejected. My handler never sees a bad caller —
the constraint rejects them first.

This is the Solana equivalent of a 403 check, but it is declarative
and enforced by the runtime. There is no application layer to
accidentally bypass.

The Tests

I used LiteSVM — an in-process
Solana VM that runs your compiled program against a fresh ledger in
milliseconds. No devnet, no flakiness, no airdrop required.

Happy path

#[test]
fn initialize_then_increment() {
    let mut svm = LiteSVM::new();
    // ... load program, airdrop, create keypairs ...

    svm.send_transaction(init_tx).unwrap();
    svm.send_transaction(inc_tx).unwrap();

    let account = svm.get_account(&counter_kp.pubkey()).unwrap();
    let parsed = counter::Counter::try_deserialize(
        &mut account.data.as_slice()
    ).unwrap();

   assert_eq!(parsed.count, 1);
   assert_eq!(parsed.authority, authority.pubkey());
 }

This test would fail if increment stored the wrong number, or if
initialize set the wrong authority. It proves both instructions
work correctly together.

Failure path

#[test]
fn increment_fails_when_wrong_authority_signs() {
    // authority_a creates the counter
    svm.send_transaction(init_tx).expect("initialize should succeed");

    // authority_b tries to increment it
    let bad_tx = build_increment_tx(&svm, program_id,
        &authority_b, counter.pubkey());

    let result = svm.send_transaction(bad_tx);
    assert!(result.is_err(),
        "increment should fail when signed by the wrong authority");
}

This test would fail if I removed or weakened the has_one = authority
constraint. It proves the gate is real, not just assumed.

The Experiment That Made the Tests Real

A passing test suite is a story. The question is whether it tells the
truth.

On the last day of the week I planted bugs on purpose, one at a time,
and watched the suite catch them.

The most instructive experiment: I changed checked_add(1) to
checked_add(2) in the increment handler. The transaction still
succeeded — no error, no panic. But the stored value was wrong.

The test output:
test initialize_then_increment ... FAILED
thread panicked at:

assertion left == right failed
left: 1
right: 2

One character change in production code. One specific failure with a
specific line number pointing exactly at the assertion that caught it.
That is what assertions are for.

Then I removed the has_one = authority constraint entirely. The
happy-path test stayed green — it uses the correct authority. But:

test increment_fails_when_wrong_authority_signs ... FAILED

increment should fail when signed by the wrong authority

The wrong-signer transaction now succeeded, and the test that expected
a rejection panicked. Without that failure test, I would have silently
shipped a program that lets anyone increment anyone else's counter.
The negative test is the only reason I would have known.

Both times I put the code back, ran the suite, and got green. The
suite told the truth both times.

What I Would Build Next

The counter account in this program lives at a random keypair's
address. That means the client has to remember which keypair holds
which user's counter — messy in practice. The natural next step is
Program Derived Addresses (PDAs): deterministic addresses derived
from the user's wallet and a seed string, so any client can find any
user's counter without storing a keypair.

After that: a decrement instruction, a reset instruction, and
then connecting the program to a TypeScript client so it can run
on devnet with a real wallet.

Resources

Anchor framework — the framework used throughout
Anchor account constraints reference — full list of constraints including has_one, init, mut
LiteSVM — the in-process test harness
Solana docs — accounts model primer

This post is part of *#100DaysOfSolana*. Building on Solana every
day — follow along or jump in any time.

I built a self-hosted DPI-resistant tunnel over TLS + WebSocket in Rust

Илья Федотов — Sat, 20 Jun 2026 14:32:32 +0000

I built BibaVPN for one reason: I did not want to hand traffic to a third-party VPN provider.

It is a self-hosted SOCKS5 / HTTP CONNECT tunnel over TLS + WebSocket, with a Rust core and Android/Desktop clients.

Some users in Russia, Iran, and China use it to get around network blocks through their own VPS.

The project is small on purpose. It is not trying to be a full private network stack. It is meant for private, self-hosted access in restrictive environments.

GitHub: https://github.com/Eljaja/BibaVPN

Web Developer Travis McCracken on Handling Failures Gracefully in Backend Systems

Travis McCracken Web Developer — Sat, 20 Jun 2026 13:23:29 +0000

Unlocking the Power of Backend Development with Rust and Go: Insights from Web Developer Travis McCracken

As a dedicated Web Developer focused on backend technologies, I’ve spent the past few years exploring the nuances and advantages of programming languages like Rust and Go. These languages have transformed how we build fast, reliable, and scalable APIs, and I’m passionate about sharing insights, trends, and the potential they hold for modern backend development.

The Rise of Rust and Go in Backend Development

Rust and Go have become household names among backend developers for their performance, safety, and concurrency features. Rust, with its focus on memory safety without a garbage collector, is ideal for building high-performance servers and APIs where efficiency is critical. Meanwhile, Go’s simplicity and built-in concurrency support make it a favorite for rapidly developing scalable cloud services.

From my experience, ecosystems around these languages are blossoming, with innovative projects and tools emerging constantly. For instance, I recently worked extensively on a project I jokingly dubbed ‘rust-cache-server’—a fictional but representative high-performance caching server built with Rust. Its design leverages Rust’s zero-cost abstractions to maximize throughput while ensuring thread safety. The project illustrated how Rust can be a game-changer for latency-sensitive backend components.

On the Go side, I developed a prototype API called ‘fastjson-api’, which demonstrated how efficiently Go handles JSON processing and concurrent API requests. Its lightweight nature and ease of deployment made it a go-to choice for building microservices that demand rapid response times and high throughput.

Practical Benefits of Rust and Go for APIs

Rust excels in scenarios where safety, zero-cost abstractions, and raw speed matter. Its ownership model eliminates many classes of bugs at compile time, leading to more reliable APIs. Additionally, projects like ‘rust-cache-server’ show Rust’s capability to handle heavy loads with minimal resource consumption.

Go, on the other hand, is renowned for its simplicity and ease of use. The language’s built-in goroutines allow developers to create highly concurrent systems with less code and complexity. This makes ‘fastjson-api’ not only performant but also easy to maintain and extend. The standard library’s robust support for networking and HTTP makes API development straightforward.

Real-World Implementation and Trends

In my projects, combining Rust and Go has often led to hybrid architecture solutions, where critical backend services are written in Rust for performance, while orchestration and less performance-critical components are built with Go for speed of development.

For example, a recent project involved a Rust-based microservice for real-time data processing, linked with a Go-powered API gateway that manages authentication, logging, and routing. This approach leverages each language’s strengths and provides an optimized backend ecosystem.

Future Directions and Challenges

One challenge with adopting Rust and Go at scale is the learning curve and tooling maturity. While both languages have matured significantly, integrating them into existing systems requires thoughtful planning. Additionally, open-source projects like ‘fastjson-api’ and ‘rust-cache-server’—though fictional—serve as inspiration for developers to experiment and innovate.

The evolution of these languages suggests a future where backend systems are more performant, safer, and easier to scale. Continuous improvements in their ecosystems, such as advanced package managers, frameworks, and deployment tools, will make it even easier for developers to leverage Rust and Go for API development.

Final Thoughts

As someone passionate about backend development, I believe Rust and Go represent two sides of the same coin—with each bringing unique advantages to the table. Whether you’re optimizing performance-critical components or building scalable, maintainable APIs, these languages are worth mastering.

If you’re interested in exploring my work related to backend development, feel free to check out my profiles for more insights, projects, and tutorials:

Embrace the power of Rust and Go, and transform your backend systems into high-performance, reliable services that stand the test of time. Happy coding!

Building an Enterprise Hybrid AI Shield: Remote OTA, Kernel Process Isolation, ChaCha20 FIM, and eBPF Distributed Mesh (Rust + C++)

nikhilsharma987880-bot — Sat, 20 Jun 2026 12:54:04 +0000

Moving Beyond Static Firewalls: Elevating Cyber Aura to an Enterprise Distributed EDR Suite

A few days ago, I designed a Hybrid Rust + C++ log parser with a self-modifying AI mutation engine. But threat landscapes evolve in milliseconds. Today, I upgraded the entire architecture to handle internal breaches, cloud-managed defenses, and multi-server orchestration without requiring a single system reboot.

Here is how the newly integrated enterprise architecture works under the hood:

🛠️ The Core Architectural Upgrades

1. Zero-Downtime Remote OTA Update Engine & Process Killer (C++ Layer)

Spawning a detached background thread using std::thread, the system periodically fetches the latest signatures (aura_rules.conf) and hot-reloads them directly into RAM. If an internal attacker tries to compromise critical fields, the Rust core intercepts the anomaly, tracks the *Process ID (PID), and calls a low-level C++ FFI hook to trigger kill(pid, SIGKILL) instantly.

2. Military-Grade ChaCha20 File Integrity Monitor (FIM)

Moving beyond basic monitoring, I hooked the system into the Linux inotify subsystem via Rust. If an unauthorized process attempts to modify production infrastructure (like /var/www/html/index.php or configurations), the engine intercepts it in real-time and automatically executes an **in-place ChaCha20 lockdown. Critical files are immediately encrypted and rendered completely unreadable until the master key is supplied.

3. Kernel-Level Packet Dropping via eBPF (XDP)

To achieve zero CPU overhead bypass defense, the ecosystem now features *eBPF (Extended Berkeley Packet Filter) integration. Instead of waiting for logs to be written to disk, we inject bytecode directly into the Linux Kernel network interface layer using XDP (eXpress Data Path). When the AI engine detects an aggressive attack vector, it updates the eBPF maps in real-time, dropping malicious packets natively inside the kernel before they even reach the user-space network stack.

4. Distributed Mesh Agent Network (Master-Worker Architecture)

Enterprise networks span across hundreds of nodes. I implemented an asynchronous TCP communication grid (network_mesh) in Rust.

AURA Master Node: Acts as a centralized command hub.
AURA Worker Agents: Deployable across hundreds of production servers to sniff local activities. If a single worker agent detects a zero-day intrusion on its server, it coordinates via the mesh to dynamically push blocklists to all other 99+ servers in the cluster instantly, neutralizing the threat globally.

🎯 The Ultimate Tactical Impact

With these additions, Cyber Aura has evolved into a fully autonomous, self-healing Endpoint Detection and Response (EDR) suite:

Global Swarm Defense: Attack one server, and the entire infrastructure hardens its perimeter within microseconds.
Pre-Log Interception: Malicious traffic is eliminated inside the kernel layer via eBPF.
Cryptographic Self-Defense: Automated ChaCha20 file lockdown stops data exfiltration in its tracks.

👉 Check out the fully modular repository: https://github.com/nikhilsharma987880-bot/hybrid_log_parser/tree/main

Developer Credit: Nikhil Sharma (Cyber Aura)

Elixir 1.20 has a type system now: comparing it with Rust and TypeScript

GeekMasahiro — Sat, 20 Jun 2026 12:12:16 +0000

This English version is an AI translation of my original article on Qiita (in Japanese).

About this article

On June 3, 2026, Elixir 1.20 shipped with a type system. But it aims at something a little different from the type systems we are used to, the ones where you write types to buy safety.

This article started from my own questions, which I worked through with an AI agent. We went to primary sources (the official blog, the docs, the paper), and in the end I installed Elixir 1.20 and checked how the type checker actually behaves. I may still have gotten things wrong, so if you notice anything, I would be glad to hear it in the comments.

What the type system aims for: soundness

First, the word sound. In type systems, a type system is sound when, if it says a value has some type, you will not get a type error of that kind at runtime. The opposite, unsound, means a program can type-check and still hit a type error when it runs.

Making a dynamic language fully sound is hard. TypeScript openly states that it is not sound (it lists "apply a sound or 'provably correct' type system" as a non-goal). Elixir, on the other hand, lists soundness as one of the goals of its type system. But it too admits it is best-effort ("we do not guarantee we will find every mistake"), so it does not claim to be fully sound either. Both projects talk about their type systems in terms of sound and unsound, so I will use the same words here.

There is room for different stances on how far, and how, to pursue soundness. The key question is how each one treats things it cannot be sure about.

	Sound?	Unknowns are...
Rust	sound (strong)	rejected
Elixir	sound (best-effort)	passed
TypeScript	unsound	passed

Rust rejects what it cannot be sure about. Because it refuses to let those through, it is strongly sound about types and ownership. (The unsafe parts, and runtime errors like out-of-bounds array access, are outside that guarantee.)

TypeScript and Elixir both let unknowns through in the end. The difference is what happens before that. TypeScript is designed around writing types as much as you can, and where type information is missing (an any, or something made unknown by an as cast) it treats that as out of scope and lets it through without checking. Elixir, before letting a value through, traces the flow of the code (branches and guards) to work out the possible types, and rejects only what it can prove will always fail. Same "letting it through," but the question is whether it looks first. That difference is what separates unsound (TypeScript) from sound (Elixir).

Elixir 1.20's type system

Three things stand out.

1. dynamic() defers the judgment. Where type information is missing, TypeScript passes it without checking (by design: it assumes you write types, and treats what you did not as out of scope). Elixir instead assigns the unknown spot a type that literally means "unknown" (dynamic()) and holds off. As that value flows through the code it gets narrowed, and Elixir reports only the spots where every possible value is certain to fail. Where only some paths might fail, it stays quiet. It is built to say only what it is sure of, and to avoid false positives. If something stays gray to the end it is missed (the project itself admits this best-effort limit), but whatever it does report is certain.

2. You can express negation in a type. Elixir's types are built from set operations: union, intersection, and negation (set-theoretic types). So "not nil" is natural to write. TypeScript can also say "exclude this" via Exclude and narrowing, but Elixir has negation as a type operation itself. That is the difference.

3. It starts from writing no types. For now, you do not write type annotations; the compiler infers types from the code and checks them. The point is to make it work on huge existing codebases without adding anything. Later, the plan is to let you write type signatures at the boundaries where you want stronger guarantees (per the official roadmap), and 1.20 is the "inference first" milestone on that path. Note that the long-standing @spec is for documentation and Dialyzer; the new type system does not use it. The new type signatures are being designed as a separate thing.

Once you can write types explicitly, guarantees should reach places inference cannot follow today (struct fields, boundaries across modules). But the team itself is cautious ("we still need to assess the impact on how it feels to write code" and "it may turn out the type system is not practical"), and it is still being evaluated. The future where you write types should be better, but the people building it are still feeling their way.

How much it catches without a single type annotation (I ran it)

I installed Elixir 1.20 and tried, without writing a single type, to see what it catches.

For example, when every branch of a case returns an atom, the result is inferred to be an atom, and things stop when you hand that to a function that works on strings. Elixir calls strings "binaries," so the warning says binary().

def categorize(n) do
  label =
    case n do
      x when x < 0 -> :negative
      0 -> :zero
      _ -> :positive
    end
  String.length(label)
end

warning: incompatible types given to String.length/1:
    given types:     dynamic(:negative or :positive or :zero)
    but expected one of:     binary()

It also follows types that change midway through a pipeline.

def pipeline(n) do
  n
  |> Integer.to_string()   # turn the integer into a string (Elixir calls strings "binaries")
  |> Kernel.+(1)           # warns: trying to add an integer to a string (binary)
end

warning: incompatible types given to Kernel.+/2:
    given types:     binary(), integer()
    but expected one of:     integer(), integer()   # and the other numeric combinations

Neither has any type annotations. It bundles the three case branches into :negative or :positive or :zero, follows the type change through the pipe, and points at the single spot where every value is bound to fail.

To be honest, I tried to build an example where TypeScript misses it but only Elixir catches it, and I could not make one work. TypeScript catches type mismatches too, and unsound cases like out-of-bounds array access are missed by Elixir as well (best-effort). The difference is not the range of what can be caught; it is that it catches this without my writing a single type for the example.

Pushed further: wouldn't a statically typed language be enough?

After running all this, a deeper question surfaced. If we have statically typed languages like Rust, then pushed to the limit, wouldn't those be enough? Why do dynamically typed languages need to exist at all? I wanted to find out, so I asked an AI agent. Here is the answer that came back.

First, let me split the question a little. Rust's heaviness comes less from static types themselves and more from ownership and lifetimes (the machinery for memory safety without a GC). A statically typed language with a GC gets type inference too, so you barely write annotations. So the real divide is not "Rust or dynamic" but "static or dynamic," with GC'd static languages sitting in between.

To be honest, the "static is enough" side has gotten stronger. Inference has narrowed the old "dynamic is faster to write" gap, and the trend of adding types to a dynamic language after the fact (TypeScript, Python, and now Elixir 1.20) is itself evidence that once code matters, people end up wanting static guarantees.

Even so, there are two reasons dynamic types will not disappear in principle.

1. A sound static type system must reject some programs that actually run correctly. Whether a program "never hits a type error at runtime" is undecidable in general (Rice's theorem), so if you prioritize never letting an unsafe program through, the price is that some "actually runs, but cannot be proven, so it is rejected" code always remains. This is not a flaw you fix by improving the type system; it is a hard ceiling. The proof is that every static language has an escape hatch (Rust's unsafe, the Any or dynamic casts in various languages). They admit there is a part static cannot cover, and quietly bring dynamic typing back in.

2. Some work has types that are only determined at runtime. Messy data coming from outside, a REPL you poke at interactively, macros that generate code, hot code reloading that swaps modules while the system runs. All of these are dynamic by nature, and clash with the premise of "check the whole thing up front."

In short, static and dynamic just differ in where you pay for type correctness. Static pays up front, at compile time, for every possible execution. Dynamic pays later, at runtime, for the one execution that actually happened. Because there are situations where you cannot pay up front, or where paying up front is not worth it, dynamic typing is needed. And the real answer is not "one or the other" but is heading toward "keep a dynamic base, and add static where it pays."

Reading that answer, I came to understand Elixir 1.20's reason for being, and its position, a little better.

Elixir is not trying to become Rust. It keeps a base you can run while still dynamic, statically stops only the certain mistakes, and plans to let you add types at the boundaries where you want guarantees later. It has chosen "a dynamic base, with static added where it pays" as a matter of language design.

And this overlaps with the era of having AI write code. AI can write a lot, fast, but it does not get everything completely right. So the type system points out, at the compiler level, the mistakes that are certain to be found, and assists with the parts AI does not quite finish. Elixir 1.20's type system looks like one form of that.

References

Elixir v1.20 released: now a gradually typed language (official release blog)
Gradual set-theoretic types (official docs: the note on soundness, best-effort, and phasing out typespecs)
Typespecs reference (@spec is for documentation and Dialyzer)
Type inference of all constructs and the next 15 months (roadmap)
Giuseppe Castagna, Guillaume Duboc, José Valim, "The Design Principles of the Elixir Type System"
TypeScript Design Goals (lists a sound type system as a non-goal)

How I Built a Lightweight Rust Web Browser with Zero Coding Experience (Using Gemini & Qwen)

LocShadowVN — Sat, 20 Jun 2026 11:05:43 +0000

Hey DEV community! 👋

I wanted to share a personal experiment I've been working on recently. The catch? I have absolutely zero professional coding background. I just wanted to see how far a complete beginner could push current AI tools to build a real, functional desktop application from scratch.

After weeks of prompting, configuring, and troubleshooting, here is the result: Nexus Browser — a secure, lightweight web browser built in Rust, featuring a Neon Cyberpunk GUI, a built-in ad blocker, and a multi-threaded download engine.

🛠️ My AI Development Crew
Since I couldn't write the code myself, I had to manage and coordinate three different AI assistants like a project manager:

Google Gemini 🤖 – Acted as my software architect and system administrator. It helped me map out the project structure and, most importantly, guided me through complex environment setup errors (like handling tricky NixOS and Google IDX configuration issues when compiling libraries like webkit2gtk).

Qwen Studio 💻 – Served as my primary backend developer. It generated, optimized, and compressed the Rust source code, and also helped craft the Cyberpunk-themed HTML/JS interface.

Replit AI ☁️ – Provided a quick cloud environment to test and run my early prototypes before moving things locally.

⚠️ Current Status: Lots of Bugs & The 4GB RAM Struggle!
To be completely honest, the browser currently has a lot of bugs and internal issues. Since it was built entirely through AI prompts, some parts of the code are not fully optimized, and there are occasional crashes and weird UI rendering glitches. I am actively working with the AIs to debug, refactor the code, and fix these issues one by one.

But here is the funniest part: I can't even properly test my own browser right now because my laptop only has 4GB of DDR3 RAM! 💀

Every time I try to run a heavy compile or open too many preview windows, my poor laptop gasps for air and threatens to explode. So if you clone the repo and find a major bug, just know that my 4GB RAM setup was doing its absolute best to survive the compilation process!

💡 Key Lessons I Learned Along the Way
Modular Prompting is Everything: Asking an AI to "build a whole web browser" right away is a recipe for broken code. I had to break the project down into tiny, isolated pieces: first building a basic window, then adding the Cyberpunk UI styling, then injecting the ad blocker logic, and finally implementing the download manager.

Environment Setup is the Real Boss: Writing code with AI is relatively fast, but setting up the correct compiler flags, managing dependencies, and making sure Rust plays nice with Linux graphics libraries took up a lot of time. Having Gemini double-check my build logs was a lifesaver.

🚀 Check it out!
I'm honestly amazed at what's possible today. A few years ago, building a custom Rust browser as a beginner would have felt impossible. Now, with the right AI collaboration, anyone can bring their ideas to life.

If you are curious about the project, want to help me debug, or have some solid advice on how a beginner can optimize the Rust code further, please check out the repository!

👉 GitHub Repository: https://github.com/LocShadowVN/nexus-browser

If you like this experiment and want to support a beginner developer struggling on a 4GB RAM machine, leaving a ⭐ on GitHub would mean the world to me!

Thank you for reading! Let me know in the comments if you have any tips for debugging Rust apps with AI.

Rust-Based Aurora Browser Engine Aims to Tackle Complex Web Apps Like YouTube Despite Technical Hurdles

Sergey Boyarchuk — Sat, 20 Jun 2026 10:26:38 +0000

Introduction: The Aurora Project and the YouTube Challenge

The Aurora browser engine, built from scratch in Rust, represents a bold attempt to address the growing complexity of modern web applications. Its primary goal? Rendering YouTube, a notoriously intricate Single Page Application (SPA) that pushes browser engines to their limits. This challenge isn’t just about YouTube—it’s a litmus test for Aurora’s ability to handle the shadow DOM composition, custom elements, and extensive JavaScript that define today’s web.

At its core, Aurora integrates V8 for JavaScript execution, Stylo (via blitz-dom) for CSS resolution, and Vello for pixel painting. These dependencies, while powerful, introduce their own constraints. For instance, Stylo’s style invalidation bugs—like the panic triggered by elements lacking computed styles—can cascade into rendering failures. Rust’s memory safety guarantees mitigate certain risks, such as double-parented nodes (which caused YouTube’s cleanup logic to spin indefinitely), but they also complicate integration with external components.

YouTube’s architecture, built on Polymer and ShadyDOM, exacerbates these challenges. Its detached logical fragments require precise shadow DOM composition to ensure connected callbacks fire correctly. Aurora’s initial failure to render the masthead logo stemmed from this: fragments weren’t reattached to the connected tree, leaving the logo as a 0x0 layout. Fixing this required not just understanding ShadyDOM’s behavior but also rewriting Aurora’s parent validation code to handle shadow roots separately from the normal child list.

The iterative nature of Aurora’s development is evident in its progress. Each fix—like resolving the Stylo panic or correcting event propagation—brings YouTube closer to full renderability. However, the process is fraught with edge cases. For example, a blank video player turned out to be a removed YouTube video, not an Aurora bug, highlighting the need for robust error handling in complex systems.

Aurora’s approach, centered on capability gating, allows for modular development but introduces trade-offs. While leveraging V8 and Stylo accelerates progress, it ties Aurora to their release cycles and bugs. A fully custom implementation would offer greater control but at the cost of increased development time and complexity. The optimal choice depends on the priority of innovation versus stability: if rapid iteration is key, external dependencies are preferable; if long-term control is critical, custom implementations are necessary.

In summary, Aurora’s quest to render YouTube isn’t just a technical challenge—it’s a strategic one. Success would demonstrate Rust’s viability for browser engines and reduce reliance on dominant engines like Chromium. Failure, however, would underscore the risks of browser engine monoculture, where innovation stalls and security vulnerabilities proliferate. As Aurora progresses, its lessons will shape the future of web rendering—one paint path at a time.

Technical Hurdles: Deconstructing YouTube’s Complexity

Rendering YouTube in Aurora isn’t just a test of browser engine capability—it’s a stress test of modern web technologies pushed to their limits. YouTube’s architecture as a Single Page Application (SPA) built on Polymer and ShadyDOM introduces a cascade of technical challenges. These aren’t theoretical problems; they’re mechanical failures in the DOM tree, JavaScript execution, and rendering pipeline that manifest as missing elements, infinite loops, or crashes.

Shadow DOM Composition: The Silent Killer of Rendering

YouTube’s reliance on shadow DOM for encapsulation creates a critical bottleneck. Polymer stamps content into detached logical fragments, which must be reattached to the connected tree for connected callbacks to fire. Aurora’s initial failure with the masthead logo—rendering as 0x0—was caused by improper composition of these fragments. The impact was twofold: connected callbacks never fired, and the logo remained unrendered. The mechanism was a flaw in Aurora’s parent validation code, which treated shadow roots as stale and disconnected them from their hosts. Fixing this required rewriting the validation logic to handle shadow roots separately, ensuring fragments were correctly reattached. Rule: If shadow DOM elements fail to render, verify fragment reattachment and callback firing in the composition pipeline.

Stylo Panics: When Style Invalidation Breaks the Engine

Aurora’s dependency on Stylo for CSS resolution introduces a failure mode tied to style invalidation. When an element lacks computed styles, Stylo panics, halting rendering. This isn’t a theoretical edge case—it’s a recurring blocker in YouTube’s feed, where dynamic style updates trigger invalidation. The mechanism is a bug in Stylo’s handling of unstyled elements, already fixed upstream but not yet released. Aurora’s workaround is to fail gracefully, but this is a temporary patch. Rule: For Stylo-dependent engines, prioritize upstream fixes for style invalidation bugs, as they cascade into rendering failures.

Custom Elements and Event Propagation: The Hidden Glue

YouTube’s use of custom elements and mutation observers exposes gaps in Aurora’s implementation. Initially, custom elements failed to upgrade correctly, and events didn’t propagate, causing interactive elements to malfunction. The mechanism was incomplete lifecycle management for custom elements and missing event handlers in the DOM tree. Fixing this required aligning Aurora’s implementation with browser standards, ensuring elements defined and upgraded correctly. Rule: If custom elements or events break, audit lifecycle hooks and event propagation paths against standards.

Edge Case: The Blank Video Player

A blank video player in Aurora was initially suspected to be a rendering bug. The mechanism was simpler: the video had been removed from YouTube, but Aurora lacked robust error handling for missing media. This highlights a broader risk: edge cases in complex systems often mimic internal failures. Rule: When debugging media rendering, verify external resource availability before assuming engine failure.

Rust’s Memory Safety: A Double-Edged Sword

Rust’s memory safety prevents issues like double-parented nodes, which caused YouTube’s cleanup logic to spin indefinitely. However, it complicates integration with external components like V8 and Stylo. The mechanism is Rust’s strict ownership model, which conflicts with C++-based libraries’ memory management. This introduces integration overhead but reduces undefined behavior risks. Rule: Use Rust’s safety guarantees to eliminate memory-related bugs, but budget for integration challenges with non-Rust components.

Capability Gating: Trade-offs in Design

Aurora’s use of capability gating accelerates development by integrating V8, Stylo, and Vello. However, this ties Aurora to their release cycles and bugs. The mechanism is a dependency on external components, which introduces latency in adopting fixes. A fully custom implementation would offer greater control but at higher development cost. Rule: If innovation is the priority, use external components; if stability is critical, invest in custom implementations.

Strategic Implications: Beyond YouTube

Aurora’s progress with YouTube demonstrates Rust’s viability for browser engines, reducing reliance on Chromium. However, failure would underscore the risks of browser engine monoculture. The mechanism is stagnation in innovation and security vulnerabilities from a single dominant engine. Rule: Diversify browser engine development to mitigate ecosystem risks.

Rust’s Role: Advantages and Limitations in Browser Engine Development

Rust’s memory safety guarantees are a double-edged sword in Aurora’s development. On one hand, they prevent undefined behavior like double-parented nodes, which caused YouTube’s cleanup logic to spin indefinitely. This is because Rust’s ownership model enforces strict parent-child relationships in the DOM tree, eliminating dangling references. However, this same safety introduces integration challenges with C++-based libraries like V8 and Stylo. Rust’s strict borrowing rules clash with C++’s manual memory management, requiring unsafe code blocks or bindings like blitz-dom to bridge the gap. This trade-off highlights a key rule: Use Rust for memory safety, but budget for integration friction with non-Rust components.

Rust’s concurrency model, particularly its fearless concurrency via ownership and borrowing, theoretically enables efficient parallelization of tasks like layout computation and painting. However, Aurora’s current bottleneck lies in shadow DOM composition, where detached logical fragments must be reattached to the connected tree. This process is inherently sequential, as connected callbacks must fire in a specific order. Rust’s concurrency advantages are muted here, as the problem is not parallelizable without breaking the DOM’s integrity. This reveals a practical insight: Concurrency benefits are limited by the sequential nature of certain browser engine tasks.

Advantage: Rust’s memory safety prevents infinite loops in YouTube’s cleanup logic by eliminating double-parented nodes.
Limitation: Integration with V8 and Stylo requires unsafe code or bindings, increasing complexity.
Edge Case: Shadow DOM composition remains sequential, limiting Rust’s concurrency benefits.

Performance-wise, Rust’s zero-cost abstractions and lack of garbage collection provide a predictable execution profile, critical for rendering-intensive applications like YouTube. However, this comes at the cost of development complexity. For instance, fixing the masthead logo issue required rewriting parent validation code to handle shadow roots separately. While Rust’s safety caught the initial bug, the solution demanded deep understanding of both Rust and browser standards. This underscores a rule: Rust’s performance gains require higher developer expertise, particularly in edge cases like shadow DOM handling.

Finally, Rust’s ecosystem limitations pose a practical challenge. Unlike C++, Rust lacks mature libraries for browser engine development, forcing reliance on external components like Stylo and Vello. This ties Aurora to their release cycles and bugs, as seen with the Stylo panic from uncomputed styles. While this accelerates development, it introduces dependency risks. The optimal strategy here is to use external components for rapid iteration but invest in custom implementations for critical paths. Rule: Prioritize external dependencies for innovation; build custom solutions for stability.

Trade-off: Rust’s performance predictability vs. higher development complexity in edge cases.
Risk Mechanism: Dependency on Stylo’s release cycle delays fixes for style invalidation bugs.
Optimal Choice: Use external components for non-critical paths; custom implementations for core logic.

Progress and Future Roadmap: From Prototype to Production

Aurora’s journey from a Rust-based prototype to a production-ready browser engine capable of handling YouTube is a testament to both the potential and the pitfalls of modern browser engine development. The project has already achieved significant milestones, but the road ahead is paved with technical challenges that demand precision, innovation, and strategic decision-making.

Current Achievements: Incremental Wins in a Complex Landscape

Aurora’s ability to render parts of YouTube—a notoriously complex SPA built on Polymer and ShadyDOM—is a critical proof of concept. This progress hinges on several system mechanisms:

Shadow DOM Composition: Aurora now correctly reattaches detached logical fragments created by Polymer, ensuring connected callbacks fire. This fixes issues like the masthead logo rendering as 0x0, where the logo’s layout was broken due to uncomposed fragments. The causal chain here is: detached fragments → untriggered callbacks → missing elements → corrected composition → visible logo.
Parent Validation Code: Rewriting the validation logic to handle shadow roots separately resolved a bug where shadow roots were treated as stale, disconnecting them from their hosts. This change increased the paint path count from under 300 to over 400, indicating more accurate DOM tree traversal and rendering.
Event Propagation and Custom Elements: Fixing event propagation and custom element lifecycle management allowed YouTube’s interactive components to function partially. For example, the player frame now renders, though playback remains non-functional due to unresolved Stylo panics.

These achievements highlight Aurora’s iterative approach, where each fix addresses a specific failure mode in the system. However, they also expose the interdependence of browser engine components: a bug in one mechanism (e.g., shadow DOM composition) can cascade into failures in others (e.g., layout and painting).

Ongoing Milestones: Tackling the Next Layer of Complexity

The current blocker—a Stylo panic during style invalidation—exemplifies the trade-offs of relying on external components. While Stylo accelerates CSS resolution, its bugs introduce instability. The optimal solution here is:

If an upstream fix is available but unreleased, use a temporary workaround to fail gracefully, ensuring Aurora doesn’t crash. This buys time until the fix is integrated.
If the bug persists, consider forking Stylo for critical paths, trading rapid iteration for stability. However, this introduces maintenance overhead and risks diverging from upstream improvements.

Another priority is resolving YouTube’s remaining rendering issues, such as the blank video player. While initially suspected to be an Aurora bug, this turned out to be a removed YouTube video—an edge case in media resource handling. The rule here is: if media elements fail to render, verify external resource availability before assuming engine failure.

Long-Term Vision: Becoming a Fully Functional Browser Engine

Aurora’s end goal is to render YouTube and other demanding web applications seamlessly. Achieving this requires addressing systemic challenges:

Concurrency in Layout Computation: Rust’s fearless concurrency is theoretically advantageous, but browser engine tasks like shadow DOM composition are inherently sequential. Attempting parallelization here risks breaking DOM integrity. The optimal strategy is to focus concurrency on independent tasks, like JavaScript execution via V8, while keeping sequential operations optimized.
Memory Safety vs. Integration: Rust’s memory safety prevents issues like double-parented nodes but complicates integration with C++ libraries (e.g., V8, Stylo). The rule is: use Rust for memory-critical components, but budget for integration friction, possibly leveraging bindings like blitz-dom.
Capability Gating Trade-offs: External dependencies accelerate development but tie Aurora to their release cycles. The optimal choice depends on the priority: use external components for innovation; invest in custom implementations for stability. For example, replacing Stylo with a custom CSS engine would reduce dependency risks but significantly increase development time.

Strategic Implications: Diversifying the Browser Engine Ecosystem

Aurora’s success would demonstrate Rust’s viability for browser engines, reducing reliance on Chromium and WebKit. Failure, however, would underscore the risks of browser engine monoculture: stalled innovation, security vulnerabilities, and limited competition. The key mechanism here is ecosystem diversity: multiple engines drive standards compliance, security, and performance improvements.

In conclusion, Aurora’s progress from prototype to production is a high-stakes experiment in balancing innovation and stability. Each technical decision—whether to use external components, rewrite critical code, or prioritize memory safety—shapes its trajectory. As Aurora tackles YouTube’s complexity, it not only tests its own maturity but also charts a path for the future of browser engine development.

Efficient Streaming JSON Parser Solves Large File Handling with Low Memory and High Speed

Pavel Kostromin — Sat, 20 Jun 2026 09:55:16 +0000

Introduction: The Challenge of Large JSON Files

Handling large JSON files efficiently is a critical yet often overlooked problem in modern software development. As data volumes explode and real-time processing becomes the norm, the limitations of traditional JSON parsing methods become painfully apparent. JSON.parse(), the default choice in many environments, is a blocking operation that loads the entire file into memory before processing. For files in the MB or GB range, this approach is a recipe for disaster: memory consumption skyrockets, performance plummets, and systems risk crashing under the load.

The root cause lies in the structural mismatch between JSON’s hierarchical nature and the linear, in-memory processing model. JSON files, especially large ones, are often deeply nested or contain arrays with thousands of elements. When parsed conventionally, each layer of nesting or array element requires additional memory allocation. This allocation is not just a one-time cost—it accumulates as the parser traverses the document, leading to exponential memory growth. For example, a 10MB JSON file with nested arrays can easily consume 100MB+ of RAM when parsed with JSON.parse(), as each level of nesting duplicates memory references.

Streaming parsers attempt to mitigate this by processing JSON incrementally, but existing solutions fall short in two key areas: memory control and speed. Most streaming libraries either lack the ability to balance memory usage dynamically or sacrifice performance to achieve it. This trade-off is unacceptable in production environments where both resources are scarce. Developers are left with a Hobson’s choice: tolerate slow performance, risk memory exhaustion, or rewrite critical components in lower-level languages—a costly and error-prone process.

Enter Bote, a streaming JSON parser designed to break this deadlock. By leveraging Rust’s memory safety and performance characteristics, Bote achieves up to 16x lower memory usage than JSON.parse() while maintaining 1.5x faster throughput. Its core innovation lies in a structural position bitmap that tracks JSON elements without requiring full in-memory representation. This bitmap acts as a navigational map, allowing Bote to jump to any part of the JSON stream without buffering intermediate data. The result is a parser that scales linearly with file size, not exponentially.

Bote’s design is further optimized for real-world use cases. Its AsyncIterator API integrates seamlessly with modern JavaScript workflows, while compatibility with Standard Schema ensures type safety. Critically, Bote’s memory footprint is user-controllable: developers can trade off memory for speed by adjusting buffer sizes, a feature absent in competing libraries. This flexibility is a game-changer for applications where resource constraints are unpredictable, such as cloud-native services or edge computing.

However, Bote is not a silver bullet. Its performance gains come at the cost of increased complexity. The Rust-based core, while efficient, requires careful integration with JavaScript runtimes. Additionally, Bote’s streaming model assumes non-blocking I/O, making it less suitable for synchronous environments. Developers must also be mindful of JSON structure: highly fragmented or deeply nested documents may still strain memory, though to a far lesser degree than traditional parsers.

In summary, Bote addresses a pressing need in the JSON parsing landscape by combining memory efficiency, speed, and usability. Its technical innovations—particularly the structural bitmap and Rust implementation—set a new benchmark for streaming parsers. While not without limitations, Bote represents a significant step forward for developers grappling with large JSON datasets. As data volumes continue to grow, tools like Bote will become indispensable for building scalable, resource-efficient applications.

Key Takeaways

Problem Mechanism: Traditional JSON parsing causes memory bloat due to recursive allocation during nested structure traversal.
Bote’s Solution: Structural bitmap navigation eliminates redundant memory allocation, enabling linear scaling.
Optimal Use Case: If processing JSON files >1MB with limited memory (e.g., serverless, edge devices), use Bote to avoid OOM errors.
Failure Condition: Bote’s streaming model breaks down in synchronous environments or when JSON structure is extremely fragmented.
Decision Rule: If memory usage is critical and JSON size exceeds available RAM, prioritize Bote over JSON.parse() or other streaming libraries.

The Challenge of Large JSON Parsing

Parsing large JSON files is a deceptively complex task, often exposing critical weaknesses in traditional methods. At the heart of the problem is the structural mismatch between JSON’s hierarchical nature and linear, in-memory processing models. When a parser like JSON.parse() encounters a nested JSON structure, it recursively allocates memory for each layer, leading to exponential memory growth. For example, a 10MB JSON file with deeply nested arrays can consume 100MB+ of RAM due to the overhead of intermediate object representations. This mechanism triggers memory exhaustion, causing systems to crash or grind to a halt—a risk amplified in resource-constrained environments like serverless platforms or edge devices.

Streaming parsers, while designed to mitigate this by processing data incrementally, often fail due to inadequate memory control or performance trade-offs. Most lack the ability to balance memory usage dynamically, forcing developers into a false choice: either accept slower throughput or risk system instability. This failure is rooted in their inability to track structural positions without buffering intermediate data, a limitation that Bote addresses through its Structural Position Bitmap. This mechanism allows Bote to navigate JSON hierarchies without fully materializing them in memory, achieving a linear memory scaling model—a critical shift from the exponential growth of traditional methods.

The causal chain here is clear: impact (memory exhaustion) → internal process (recursive allocation during traversal) → observable effect (system crashes or slowdowns). Bote disrupts this chain by decoupling navigation from memory allocation, ensuring that memory usage scales linearly with file size, not structure depth. This innovation is further amplified by its Rust implementation, which leverages memory safety and zero-cost abstractions to minimize overhead, resulting in 16x lower memory usage and 1.5x faster throughput compared to JSON.parse().

Edge Cases and Failure Conditions

While Bote excels in memory-constrained, large-file scenarios, it is not universally optimal. In synchronous environments or with extremely fragmented JSON structures, its asynchronous, streaming design can introduce latency. The mechanism here is straightforward: synchronous workflows require immediate data availability, which Bote’s incremental processing model cannot guarantee without buffering—defeating its memory efficiency. Similarly, fragmented JSON (e.g., deeply nested objects with sparse data) forces Bote to allocate more bitmap entries, increasing memory overhead. However, these cases are edge scenarios; Bote’s user-controllable buffer sizes allow developers to tune performance for specific trade-offs, a flexibility absent in alternatives.

Decision Rule: When to Use Bote

Prioritize Bote over JSON.parse() or other streaming libraries when memory usage is critical and JSON size exceeds available RAM. Specifically:

If X (JSON file >1MB and memory-constrained environment) → Use Y (Bote).
Avoid Z (traditional parsers or outdated streaming libraries) due to exponential memory growth risk.

Typical choice errors include overestimating available memory or underestimating JSON complexity, both of which lead to system failures. Bote’s linear scaling and adjustable buffers provide a safety net against these miscalculations, making it the optimal choice for large-scale, resource-sensitive applications.

Bote: Features and Performance

Bote, a new open-source streaming JSON parser, emerges as a critical tool for developers grappling with the challenges of processing large JSON files. Its design philosophy centers on low-memory streaming and high-speed performance, addressing the inherent limitations of traditional methods like JSON.parse(). By dissecting its features and benchmarking its performance, we uncover how Bote solves real-world problems in JSON handling.

Core Features: Mechanisms and Impact

Bote’s innovation lies in its Structural Position Bitmap, a mechanism that decouples JSON navigation from memory allocation. Unlike traditional parsers, which recursively allocate memory for nested structures, Bote tracks JSON elements using a bitmap. This approach avoids intermediate object representations, preventing the exponential memory growth that occurs when parsing deep or complex JSON hierarchies. For example, a 10MB JSON file with nested arrays might consume 100MB+ RAM with JSON.parse() due to recursive allocation, whereas Bote’s bitmap-based navigation keeps memory usage linear with file size.

The parser is written in Rust, leveraging its memory safety and zero-cost abstractions to achieve 16x lower memory usage and 1.5x faster throughput than JSON.parse(). Rust’s ownership model ensures that memory is managed efficiently, eliminating the risk of memory leaks or fragmentation that plague traditional parsers. This is particularly critical in resource-constrained environments like serverless functions or edge devices, where memory exhaustion can lead to system crashes.

Benchmarks: Evidence of Superiority

Benchmarks, available in the project’s README, demonstrate Bote’s performance advantages. When processing a 1GB JSON file, Bote consumes 16x less memory than JSON.parse() while maintaining 1.5x faster parsing speed. This is achieved through:

Streaming Architecture: Bote processes JSON incrementally, avoiding the need to load the entire file into memory. This linearizes memory usage, preventing the exponential growth caused by recursive allocation in traditional parsers.
Bitmap Navigation: The Structural Position Bitmap allows Bote to jump to any part of the JSON without buffering intermediate data, reducing memory overhead and improving throughput.
AsyncIterator API: Bote integrates seamlessly with modern JavaScript workflows, enabling asynchronous processing that minimizes blocking and maximizes resource utilization.

Edge Cases and Failure Conditions

While Bote excels in memory-constrained, large-file scenarios, it has limitations. In synchronous environments, the asynchronous streaming architecture introduces latency, making it suboptimal for small, simple JSON files. Additionally, extremely fragmented JSON structures increase the number of bitmap entries, raising memory overhead. However, Bote mitigates this with user-controllable buffer sizes, allowing developers to tune performance based on their specific use case.

Decision Rule: When to Use Bote

Bote is the optimal choice when:

JSON file size exceeds 1MB and memory is constrained.
Traditional parsers like JSON.parse() risk memory exhaustion due to recursive allocation.
Performance and usability are critical, and developers need an ergonomic API with modern features like AsyncIterator and Standard Schema integration.

Avoid Bote in synchronous environments or when processing small, simple JSON files, as the overhead of asynchronous streaming may outweigh the benefits.

Practical Insights: Lessons from Development

The creator’s transparency about the development process highlights key insights. Inspired by simdjson and JSONSki, Bote combines their performance-focused approaches with a low-memory niche. The use of Rust for performance-critical components, despite the creator’s initial inexperience, underscores the importance of leveraging specialized tools for specific problems. The AI-assisted development and rigorous verification of the Rust code demonstrate a pragmatic approach to balancing innovation with reliability.

Conclusion: Bote’s Role in Modern JSON Processing

Bote disrupts the traditional JSON parsing paradigm by linearizing memory scaling and optimizing for speed. Its Structural Position Bitmap and Rust implementation address the root causes of memory inefficiency in JSON processing, making it a dominant solution for large-scale, resource-sensitive applications. By understanding its mechanisms, benchmarks, and edge cases, developers can make informed decisions to avoid common pitfalls like memory exhaustion and system crashes. If you’re handling JSON files >1MB in memory-constrained environments, Bote is the tool to use.

Use Cases and Scenarios

1. Real-Time Analytics in Serverless Environments

In serverless architectures, memory and execution time are strictly limited. Bote’s linear memory scaling prevents exponential memory growth, which would otherwise trigger out-of-memory (OOM) errors when processing large JSON payloads. For example, a 10MB JSON file processed with JSON.parse() might consume 100MB+ RAM due to recursive object allocation, crashing the function. Bote’s Structural Position Bitmap decouples navigation from memory allocation, keeping memory usage under 6MB for the same file, ensuring stable operation within serverless constraints.

2. Edge Device Data Processing

Edge devices (e.g., IoT sensors) often have limited RAM (256MB–1GB). Traditional parsers fail when handling multi-megabyte JSON logs due to memory fragmentation. Bote’s Rust implementation ensures memory safety and zero-cost abstractions, eliminating leaks. Its streaming architecture processes JSON incrementally, avoiding full file buffering. For a 50MB JSON log, Bote uses ~3MB RAM, while JSON.parse() would require 500MB+, causing system instability.

3. High-Frequency API Response Parsing

APIs returning large JSON responses (e.g., financial data feeds) require low-latency parsing. Bote’s 1.5x faster throughput compared to JSON.parse() stems from its async processing and bitmap navigation, which avoids buffering intermediate data. In a scenario with 10,000 requests/second, Bote reduces parsing time from 20ms to 13ms per request, preventing API bottlenecks and ensuring real-time data availability.

4. Log Aggregation in Distributed Systems

Aggregating JSON logs from distributed nodes often involves nested structures that trigger exponential memory growth in traditional parsers. Bote’s bitmap-based tracking linearizes memory usage, enabling aggregation of 1GB+ logs without OOM errors. For instance, a nested array of 1M objects would cause JSON.parse() to allocate 10GB+ RAM, while Bote maintains ~64MB usage, ensuring reliable log processing.

5. Frontend Data Aggregation

Fetching large JSON datasets for frontend rendering (e.g., dashboards) risks browser memory exhaustion. Bote’s AsyncIterator API integrates seamlessly with modern JavaScript workflows, allowing incremental processing. For a 20MB JSON payload, Bote streams data in ~1MB chunks, keeping memory usage under 10MB, whereas JSON.parse() would lock up the browser with 200MB+ allocation.

6. ETL Pipelines with Memory Constraints

ETL pipelines processing GB-scale JSON files often fail due to memory fragmentation or recursive allocation. Bote’s user-controllable buffer sizes allow tuning memory-speed trade-offs. For a 5GB JSON file, setting a 128MB buffer ensures linear memory scaling, preventing pipeline crashes. Without Bote, JSON.parse() would require 50GB+ RAM, exceeding typical server capacity.

Decision Rule: When to Use Bote

Use Bote if: JSON file size >1MB and memory is constrained (e.g., serverless, edge devices, browsers).
Avoid Bote if: JSON files are small (<1MB) or synchronous environments are required (asynchronous streaming introduces latency).

Common Errors and Mitigation

Error 1: Overestimating available memory → Mechanism: Developers assume sufficient RAM without accounting for recursive allocation. Solution: Use Bote’s buffer tuning to cap memory usage.

Error 2: Underestimating JSON complexity → Mechanism: Nested structures amplify memory growth exponentially. Solution: Benchmark with Bote’s linear scaling to avoid surprises.

Edge Case Analysis

Fragmented JSON: Increases bitmap entries, raising memory overhead. Mitigation: Adjust buffer size to balance memory and speed.

Synchronous Environments: Asynchronous streaming introduces latency. Mitigation: Use Bote only if latency is acceptable or refactor to async workflows.

Conclusion and Future Outlook

Bote stands as a transformative solution in the realm of JSON parsing, addressing the critical need for fast, low-memory processing of large JSON files. By leveraging a Structural Position Bitmap and a Rust-based implementation, it achieves 16x lower memory usage and 1.5x faster throughput compared to traditional parsers like JSON.parse(). This is not just a marginal improvement—it’s a paradigm shift, enabling developers to handle gigabyte-scale JSON files in environments where memory and speed are non-negotiable, such as serverless platforms, edge devices, and high-frequency APIs.

Why Bote Matters

The core innovation lies in Bote’s ability to decouple JSON navigation from memory allocation. Traditional parsers create intermediate object representations, leading to exponential memory growth as JSON depth increases. For example, a 10MB JSON file can consume 100MB+ of RAM, causing system crashes or slowdowns. Bote’s bitmap-based approach tracks structural positions without buffering, ensuring linear memory scaling with file size. This mechanism is particularly critical in memory-constrained environments, where traditional parsers fail due to recursive memory allocation.

Practical Insights and Edge Cases

While Bote excels in asynchronous, memory-constrained scenarios, it’s not a one-size-fits-all solution. In synchronous environments, the asynchronous streaming architecture introduces latency, reducing efficiency. Similarly, highly fragmented JSON structures increase bitmap entries, raising memory overhead. However, these edge cases can be mitigated through buffer size tuning, a feature unique to Bote that allows developers to balance memory usage and speed dynamically.

Future Developments

As JSON parsing continues to evolve, Bote’s open-source nature invites contributions to enhance its capabilities. Potential improvements include:

Enhanced Schema Integration: Expanding support for more complex schemas to improve type safety and validation.
Synchronous Mode: Developing a synchronous variant to cater to environments where asynchronous processing is suboptimal.
Fragmentation Optimization: Further refining bitmap construction to handle fragmented JSON more efficiently.

Decision Rule: When to Use Bote

Use Bote if:

Your JSON file size exceeds 1MB and you’re in a memory-constrained environment.
Traditional parsers risk memory exhaustion or system crashes.
You require modern API features like AsyncIterator and Standard Schema integration.

Avoid Bote if:

Your JSON file size is less than 1MB or you’re in a synchronous environment where latency is unacceptable.

Final Thoughts

Bote is not just another JSON parser—it’s a purpose-built tool for the modern data landscape. Its linear memory scaling, bitmap navigation, and Rust-powered performance make it indispensable for large-scale, resource-sensitive applications. Whether you’re aggregating logs, processing API responses, or handling frontend data, Bote offers a reliable, efficient solution. Explore its potential, contribute to its growth, and redefine how you handle JSON data.

Stripping Away Abstractions: How I Built a Rust Microkernel from Scratch in 100 Hours (At Age 13)

Daxo — Sat, 20 Jun 2026 09:27:03 +0000

Most developers take the operating system for granted-treating it as an invisible, obedient foundation for browsers, Docker, and heavy IDEs. For me, this foundation was always the ultimate mystery. I wanted to understand: what actually happens on the bare metal when you strip away high-level abstractions?

That's how my 15-day experiment started. I carved out 100 hours from a tight schedule between school and intense martial arts training (judo and wrestling) to build a standalone, microkernel-based operating system from scratch: Daxo OS, written in Rust.

In this article, I’ll share how I broke free from standard tutorials, wrote a custom PIO ATA disk driver, brought async programming into Ring 0, and why Terry Davis and his legendary TempleOS became my ultimate engineering inspiration.

![Daxo OS in Action](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/nwiom7r5gtvtviq6h6yd.jpg)

Inspired by Madness: Why Bare-Metal?

If you ask a regular software engineer why they are writing their own OS, they might think you're crazy. But if you’ve ever read about Terry Davis and TempleOS, you understand that pure, unadulterated engineering excitement. Terry built his world without looking back at Linux or Windows-communicating directly with CPU registers and controllers.

I didn't want to build another CLI tool running on top of a ready-made Linux kernel. I wanted a system that manages physical hardware by my own rules. The choice was obvious: Rust Nightly. Its #[no_std] attribute allows writing blazing-fast code without a garbage collector while maintaining strict memory safety.

Here is the anatomy of Daxo OS:

daxo_os/ ├── .cargo/ │ └── config.toml # Linker settings and build flags ├── src/ │ ├── allocator/ # Custom heap allocators (Bump, Fixed Size Block) │ ├── task/ # Async engine (Executor, keyboard handling) │ ├── allocator.rs # Heap management interface │ ├── ata.rs # The custom PIO ATA hard drive driver │ ├── framebuffer.rs # Graphics output management │ ├── gdt.rs / interrupts.rs# Descriptor tables & interrupt handling │ ├── main.rs # Kernel entry point (kernel_main) │ └── vga_buffer.rs # Good old 80x25 text output ├── disk.bin # Disk image for QEMU testing └── x86_64-blog_os.json # Target platform specification

*The Tutorial Illusion and My First Triple Fault
*
Initially, like many OSdev beginners, I relied on Philipp Oppermann's amazing "Writing an OS in Rust" guide. Printing ASCII characters to the screen via direct VGA memory access at 0xb8000 is inspiring, but it's a linear experience. You are just following someone else's tracks.

Real engineering started where the guide ended. Since the modern Rust Nightly compiler moves fast, some older code broke. The rust-lld linker suddenly started throwing errors like undefined symbol: memcpy, and the kernel would plunge into a bootloop (Triple Fault) at the slightest mistake.

I realized that modern Rust editions require explicit encapsulation of raw operations inside unsafe blocks, even within unsafe fn in some contexts, alongside strict handling of compiler_builtins. Fixing this required diving into Cargo flags and manually rebuilding core libraries. It was the exact moment I transitioned from passively reading tutorials to hardcore systems research.
**
Hardware with No Safety Nets: Writing a PIO ATA Driver**

My main critique of existing OSdev tutorials is that they often abandon the reader halfway through. You get text output, you get keyboard interrupts, but the system remains a "black box"-it cannot persist data.

I decided to fix this by writing a custom PIO ATA driver for hard drive interaction.

The hard part? The OS needs to read disk sectors before the Interrupt Descriptor Table (IDT) and the Programmable Interrupt Controller (PIC) are fully set up. If the drive fires a hardware signal when the kernel isn't ready to catch it, you get an immediate crash.
I used an architectural hack: isolated port polling right before turning on interrupts.

Here is how the boot logic looks in my main.rs:
`#![no_std]

![no_main]

![feature(custom_test_frameworks)]

![test_runner(daxo_os::test_runner)]

![reexport_test_harness_main = "test_main"]

extern crate alloc;

use daxo_os::{print, println};
use core::panic::PanicInfo;
use bootloader::{BootInfo, entry_point};
use x86_64::VirtAddr;
use alloc::vec;

// Import structures for async multitasking
use daxo_os::task::{Task, keyboard};
use daxo_os::task::executor::Executor;

entry_point!(kernel_main);

async fn async_number() -> u32 {
42
}

async fn example_task() {
let number = async_number().await;
println!("async number from example_task: {}", number);
}

fn kernel_main(boot_info: &'static BootInfo) -> ! {
// 1. First, print the ASCII banner (works via VGA, interrupts are not needed yet)
println!(" ###### ### ## ## ####### ####### ###### ");
println!(" ## ## ## ## ## ## ## ## ## ## ## ## ");
println!(" ## ## ## ## ## ## ## ## ## ## ## ");
println!(" ## ## ## ## ### ## ## ## ## ###### ");
println!(" ## ## ######### ## ## ## ## ## ## ## ");
println!(" ## ## ## ## ## ## ## ## ## ## ## ## ");
println!(" ###### ## ## ## ## ####### ####### ###### ");

println!("\n[Daxo OS Multitasking Kernel Booted]");

// 2. Set up the memory mapper and heap (interrupts are still disabled)
let phys_mem_offset = VirtAddr::new(boot_info.physical_memory_offset);
let mut mapper = unsafe { daxo_os::memory::init(phys_mem_offset) };
let mut frame_allocator = unsafe {
    daxo_os::memory::BootInfoFrameAllocator::init(&boot_info.memory_map)
};

daxo_os::allocator::init_heap(&mut mapper, &mut frame_allocator)
    .expect("heap initialization failed");

// 3. --- ATA DRIVE DRIVER TEST IN COMPLETE ISOLATION ---
// PIC controller is not enabled yet, timer isn't ticking, nothing to crash!
println!("[Testing ATA Drive Driver...]");

let mut disk_vec = vec![0u8; 512];

if let Ok(disk_buffer) = <&mut [u8; 512]>::try_from(&mut disk_vec[..]) {
    daxo_os::ata::ATA_BUS.lock().read_sector(0, disk_buffer);

    println!("Data read from LBA 0:");
    let mut data_found = false;
    for &byte in disk_buffer.iter().take(90) {
        if byte >= 32 && byte <= 126 {
            print!("{}", byte as char);
            data_found = true;
        }
    }
    if !data_found {
        print!("[Sector contains binary data]");
    }
    println!("\n[ATA Test Finished]\n");
}
// ---------------------------------------------------------------------------------

// 4. NOW initialize IDT, GDT, and the PIC interrupt controller
// Any hardware signals from QEMU pending during the disk test will reset upon PIC initialization!
daxo_os::init(); 

#[cfg(test)]
test_main();

// 5. Create the task executor/scheduler
let mut executor = Executor::new();
executor.spawn(Task::new(example_task()));
executor.spawn(Task::new(keyboard::print_keypresses()));

// 6. Enable hardware interrupts on the CPU
x86_64::instructions::interrupts::enable();

// 7. Run the executor loop indefinitely
executor.run();

}

[cfg(not(test))]

[panic_handler]

fn panic(info: &PanicInfo) -> ! {
println!("{}", info);
daxo_os::hlt_loop();
}

[cfg(test)]

[panic_handler]

fn panic(info: &PanicInfo) -> ! {
daxo_os::test_panic_handler(info)
}`

To test the driver without a real file system, I used some Unix magic to write a test string into the first 512-byte sector of a blank disk.bin file:

echo "Daxo OS ATA Test String" | dd of=disk.bin bs=512 count=1 conv=notrunc

The conv=notrunc flag is critical here—it ensures dd overwrites only the initial bytes without truncating the disk image. I configured QEMU in Cargo.toml to mount this file as a hard drive on the IDE bus. When the kernel printed Daxo OS ATA Test String read directly from the controller ports, I knew it worked.

Async in Ring 0 Space

Once the disk is verified, control goes to a custom asynchronous task executor. Implementing async/await mechanics inside a custom kernel without the standard library is pure joy. There is no Tokio or async-std here.

The architecture relies heavily on raw Future and Waker types. When a task (like waiting for a keypress in keyboard::print_keypresses) cannot proceed, it yields, giving CPU cycles to other tasks. As soon as the PIC catches a keyboard interrupt, the handler wakes that specific Waker, and the executor resumes it. It runs concurrently and endlessly inside executor.run().

Conclusion: Real Engineering Starts Where Tutorials End

This 100-hour sprint taught me the most important lesson: don't panic when facing complete darkness. When you are looking at a raw terminal crash log with a low-level error you can't Google, the only way out is to read dependency source code, look up x86_64 architecture specifications, and understand the physics of the process.

Moving forward, I plan to take Daxo OS further: shifting from Ring 0 to Ring 3 (separating kernel and user spaces), exploring process isolation, and researching microkernel security mitigations.

👉 Check out the full source code here: github.com/aitoolsdx-glitch/daxo_os
(Drop a star ⭐ or open an issue if you want to roast my unsafe code or contribute!)

SQLite riscritta in Rust? Perché qualcuno sta provando a toccare il codice “più affidabile” che abbiamo

frontendfacile.it — Sat, 20 Jun 2026 09:08:34 +0000

Dalla libreria embedded che ha invaso ogni dispositivo a un’implementazione moderna con concorrenza, async I/O e vector search: cosa cambia davvero per chi sviluppa app.

Nel frontend e nel full‑stack capita spesso di parlare di database come servizi: Postgres gestito, cluster, repliche, connessioni, pooling, credenziali e una lunga lista di “cose che possono rompersi”. Ma esiste un’altra filosofia, più vicina all’idea di “dipendenza” che di “infrastruttura”: un motore SQL che vive dentro l’applicazione.

Questa è la ragione per cui SQLite è ovunque. È una libreria, non un server. Legge e scrive su un singolo file su disco. Riduce drasticamente configurazione, porte, processi separati e complessità operativa. Ed è proprio questa semplicità a renderla una delle fondamenta silenziose dell’informatica moderna: la usi in browser, smartphone, desktop app, tool CLI, IoT… spesso senza nemmeno accorgertene.

Ora immagina di riscrivere tutto da capo, in Rust, cercando di essere compatibile al 100% e allo stesso tempo più “moderna”. Sembra un’idea folle per definizione—finché non inizi a guardare ai limiti pratici che oggi emergono in molte applicazioni.

Perché toccare SQLite, se funziona così bene?

SQLite non è “il problema”. Anzi: è considerata estremamente robusta perché è conservativa, minimalista, e custodita con un rigore quasi maniacale.

Il punto è un altro: il suo modello di sviluppo e manutenzione è atipico rispetto a quello che molti intendono per open source collaborativo. Il codice è disponibile e utilizzabile liberamente, ma l’evoluzione è guidata da pochissime persone e—di fatto—non segue la dinamica classica delle contribution esterne.

Questa scelta ha un effetto collaterale positivo: riduce il rischio di regressioni introdotte da cambiamenti non coerenti con la visione del progetto. Ma ha anche un costo: se la tua azienda o il tuo prodotto hanno esigenze nuove (concorrenza più spinta, I/O non bloccante, funzionalità specifiche), “aspettare che arrivi upstream” non è sempre un’opzione.

Da qui nasce l’idea: costruire un’alternativa che mantenga la compatibilità con SQLite, ma che possa evolvere con un set di priorità diverse.

Cosa significa davvero “drop‑in replacement”

Quando parliamo di database embedded, la fiducia è tutto. Non basta essere veloci. Non basta avere feature nuove. Il requisito numero uno è: non perdere mai dati.

Il requisito numero due è: non costringere gli utenti a riscrivere l’app.

Essere un drop‑in replacement significa:

compatibilità con il formato e/o comportamento atteso (SQL, pragma, edge case noti);
stesse semantiche nei casi limite che la gente dà per scontati da anni;
integrazione semplice nei binding e nei driver esistenti.

In pratica: “lo sostituisco e funziona” deve valere non solo per l’happy path, ma anche per i percorsi più brutti—quelli che incontrerai in produzione alle 3 di notte.

Le tre aree dove una riscrittura può cambiare le regole

Alcune scelte architetturali di SQLite sono volutamente conservative. Funzionano benissimo in tantissimi scenari, ma diventano colli di bottiglia quando l’app cresce o quando cambiano le aspettative.

1) Concorrenza in scrittura: non solo “un writer alla volta”

Un limite storico di SQLite è il modello in cui, semplificando, solo uno writer può scrivere alla volta sul database. È una scelta coerente con un file singolo e con l’obiettivo di robustezza.

Un approccio più moderno prova a consentire più scritture simultanee su porzioni diverse dei dati, facendo emergere il conflitto solo quando due operazioni toccano realmente le stesse righe (o la stessa area logica). Se funziona bene, questo cambia parecchio per carichi con:

molte richieste concorrenti;
job asincroni in background;
app locali con più thread/worker.

Per un frontend, l’impatto è indiretto ma concreto: API più reattive sotto carico, meno code lato server, meno timeout percepiti in UI.

2) I/O asincrono: evitare di bloccare thread quando si tocca il disco

SQLite tipicamente esegue I/O su disco in modo bloccante: quando legge o scrive, il thread aspetta.

In architetture moderne (specialmente in ambienti con runtime async), la possibilità di cedere il controllo durante l’I/O aiuta a:

aumentare la capacità di gestire richieste concorrenti;
ridurre sprechi di thread in attesa;
migliorare la prevedibilità della latenza.

Per chi lavora con Node.js, Rust, o servizi con event loop, questa differenza non è un dettaglio: è una leva architetturale.

3) Vector search: embeddings nello stesso database

La svolta “AI‑driven” ha creato un nuovo requisito: salvare embeddings e cercare i più vicini rapidamente.

La soluzione comune oggi è aggiungere un secondo sistema (vector database o servizio esterno). Funziona, ma raddoppia la complessità:

due database, due backup strategy;
due permessi/connessioni;
sincronizzazione applicativa;
query che diventano una pipeline di chiamate.

Integrare tipi vettoriali e indici nativi significa poter tenere:

dati relazionali tradizionali;
embeddings;
e query di similarità

…in un unico file, con un unico linguaggio (SQL) e un unico modello operativo. Per prodotti piccoli/medi—o per edge/desktop/mobile—questa è una semplificazione enorme.

Il vero problema: guadagnarsi la fiducia (senza 25 anni di storia)

Aggiungere feature è relativamente “facile”. Il difficile è costruire un database che non tradisca mai.

Qui entra in gioco un’idea molto interessante: test tramite simulazione deterministica.

Invece di affidarsi solo a test tradizionali, si esegue il database in un ambiente simulato dove puoi controllare tempo e condizioni e, soprattutto, iniettare guasti riproducibili:

perdita di alimentazione durante una scrittura;
pagina corrotta a metà;
disco che “mente” e conferma un flush che non è avvenuto;
interruzioni nel momento peggiore.

La parte cruciale è la ripetibilità: stesso seed, stesso scenario, stesso fallimento, fino a quando il bug viene isolato e rimosso. È un modo pragmatico per attaccare il tipo di problemi che non vuoi mai scoprire su un laptop dell’utente o in un POS in negozio.

Implicazioni pratiche per chi fa frontend (e prodotto)

Anche se “riscrivere un database” sembra lontano dalla UI, le conseguenze arrivano fino al client:

Meno dipendenze di sistema: un motore embedded con capacità moderne può ridurre il numero di servizi esterni necessari.
Offline e edge più potenti: avere SQL + vector search in locale abilita ricerche semantiche e feature AI senza roundtrip costanti.
Prestazioni percepite: concorrenza e I/O non bloccante migliorano latenza e throughput dei servizi che alimentano l’interfaccia.

Sintesi: una scommessa rischiosa, ma comprensibile

SQLite è diventata “invisibile” perché è affidabile e semplice. Riscriverla è rischioso proprio perché la posta in gioco è massima: i dati.

Eppure, in un mondo dove servono più concorrenza, integrazione async e funzionalità come la vector search senza moltiplicare i componenti, la spinta verso un’alternativa compatibile e più evolvibile è naturale.

La domanda non è tanto se sia una buona idea in assoluto, ma per quali prodotti e con quali garanzie. La differenza la farà la capacità di dimostrare affidabilità nel tempo, con test che cercano attivamente il fallimento—prima che lo faccia la produzione.

Articolo originale: https://frontendfacile.it/blog/sqlite-riscritta-in-rust-perche-qualcuno-sta-provando-a-toccare-il-codice-piu-af

aitm 1.0: a terminal where the AI is a participant, not the driver

kanfu-panda — Sat, 20 Jun 2026 07:33:52 +0000

I was doing AI-assisted coding inside a terminal session. The AI kept modifying files, but I had no way to view those changes in the same window — I had to switch apps, switch context, come back. Every loop through the cycle was an interruption.

What I wanted was simple: the terminal and the AI and the files, all in the same place, without the context-switching. So I built it.

That's the origin of aitm. The version 1.0 is that thing, shipped.

The design choice: participant, not driver

Most AI terminals are built around a single model: you describe intent, the AI executes. It's efficient when it works and a bad afternoon when it doesn't.

aitm draws a different line. The AI can see your environment, read your files, and call tools — but execution is always gated by you. The invariant is:

AI suggests → you decide → it happens.

In practice: the AI calls list_files, read_file, get_terminal_history, and search_history automatically. These are read-only. You see the results in the conversation as they come in. But run_command — anything that changes state — stops the loop and waits for your approval.

That distinction sounds obvious in retrospect. It wasn't obvious at design time. The first version had a "trust mode" that auto-approved low-risk commands. I removed it. The UX was slightly smoother; the feeling of being in control was not worth trading away.

Why Tauri and Rust

Electron was the obvious first option to evaluate. At idle: ~150 MB RAM, several seconds to show the window. Fine for a prototype, not acceptable for something that sits open all day. So Electron was ruled out early.

The choice was Tauri 2 + Rust from the start. Two months to get to something usable. The numbers:

5.3 MB binary (vs 150+ MB Electron)
3–5 ms cold start
~30 MB RAM at idle

The React 19 frontend handles the UI. The Rust layer handles the PTY, IPC, tool execution, and security. This matters: the security gates run in Rust, which means the JavaScript/React layer cannot bypass them. The AI layer sends requests over Tauri IPC; the Rust handler is the one that decides whether a command actually runs.

The four-layer security model

Every run_command call goes through four sequential gates before it reaches your shell.

L1 — Blocklist regex. Hard-coded patterns that always fail. rm -rf /, the fork bomb :(){ :|:& };:, dd if=/dev/zero, and ~50 others. These are commands where "the user confirmed it" is still not enough — the blocklist exists precisely to be unconditional.

L2 — Heuristic risk scoring. The command string is scored against a set of signals: does it touch /, use redirection (>), pipe to sh, reference system directories? The output is DESTRUCTIVE, HIGH, or LOW. This label shows up in the confirmation dialog so you can see why something got flagged.

L3 — Project scope allowlist. Each session has a configured project directory. You can define a globset — paths and patterns the AI is allowed to operate on. Anything outside scope is flagged before reaching L4. This is opt-in, but it's what makes "AI working on this project" distinct from "AI with access to your whole machine."

L4 — Explicit user confirmation. Every run_command produces a modal: full command text, risk level, scope check result. There is no auto-approve mode and no way to configure one.

L1 and L2 run synchronously in Rust with no async overhead. L3 uses the globset crate. L4 is a hard gate in the IPC handler — no call path in the AI layer can reach the shell without passing through it.

run_command request
    │
    ├─ L1: blocklist regex ────────────► REJECT immediately
    │
    ├─ L2: heuristic scoring
    │       DESTRUCTIVE / HIGH / LOW
    │
    ├─ L3: project scope check ────────► flag if out of scope
    │
    └─ L4: confirmation modal ─────────► shell only if approved

What else shipped in 1.0

The tool loop and security model are the headline. Everything else in 1.0 was stuff I'd been deferring:

Project scope + SQLite persistence. Sessions now have a project directory. Conversation history, session state, and config all live in a local SQLite database. Nothing leaves your machine, no account required.

Six LLM providers. OpenAI, Anthropic, DeepSeek, Qwen (Alibaba DashScope), Zhipu, and Moonshot (Kimi). You can switch per session. The six were chosen for coverage: Western API providers plus the major Chinese providers for users who want lower-latency access from CN.

Eight themes, English and Chinese UI. The themes are opinionated. There's a dark ink-wash one that I find easier on the eyes during long sessions.

Split-pane CodeMirror editor. A file editor built into the window. For quick edits without losing terminal context.

macOS Developer ID notarization. The .dmg is signed and notarized. No Gatekeeper warning on first launch.

What's not in 1.0

Windows support exists — CI builds it, I've run it — but macOS is the platform I use daily and where the edge cases are best covered. Windows testing is less thorough.

There's no streaming AI response in the tool-calling loop. The AI responds after all tool calls complete. In practice the wait is usually under two seconds, but it's a noticeable gap when a sequence involves several reads. I'll revisit this in 1.1.

Plugin system and user-defined tools are on the roadmap, not here.

Download

Binary at the GitHub release:

macOS Apple Silicon
Windows x86_64
Windows ARM64

Source on GitHub under Apache 2.0. Issues and discussions are open. If you want to talk about the security model specifically, that's where to do it.

WebSocket and SSE

tengxgfyrz67s — Sat, 20 Jun 2026 06:12:33 +0000

WebSocket and SSE in Hyperlane

Project Code：https://github.com/hyperlane-dev/hyperlane

Hyperlane is a lightweight, high-performance, cross-platform Rust HTTP server library built on Tokio. Beyond standard HTTP request-response cycles, Hyperlane provides first-class support for two important real-time communication protocols: WebSocket and Server-Sent Events (SSE). In this article, we will explore how to implement both protocols using Hyperlane's powerful middleware and streaming APIs.

Introduction to Real-Time Communication
WebSocket Protocol Overview
WebSocket Implementation in Hyperlane
WebSocket Frame Handling
Broadcasting with WebSocket
Server-Sent Events (SSE) Overview
SSE Implementation in Hyperlane
Client-Side Code Examples
WebSocket vs SSE: When to Use Each
Conclusion

Introduction to Real-Time Communication

Modern web applications often require real-time data delivery — think chat applications, live dashboards, notification systems, and collaborative editing tools. Hyperlane supports two protocols that enable real-time communication:

WebSocket: A full-duplex, bidirectional communication channel over a single TCP connection.
SSE (Server-Sent Events): A unidirectional channel where the server pushes events to the client over HTTP.

Both protocols are supported through Hyperlane's streaming and middleware APIs, making it straightforward to add real-time capabilities to your application.

WebSocket Protocol Overview

WebSocket is a communication protocol that provides full-duplex communication channels over a single TCP connection. Unlike HTTP, which follows a request-response model, WebSocket allows both the client and server to send messages independently at any time after the initial handshake.

The connection starts as an HTTP request with an Upgrade: websocket header. If the server accepts, the protocol is upgraded, and the connection remains open for ongoing message exchange.

WebSocket Implementation in Hyperlane

Hyperlane makes it easy to handle WebSocket connections through its middleware system. The key is to use the #[is_ws_upgrade_type] attribute macro to detect WebSocket upgrade requests and the #[try_get_websocket_request] macro to extract the WebSocket frame data.

Basic WebSocket Handler

#[route("/ws_upgrade_type")]
struct Websocket;

impl ServerHook for Websocket {
    async fn new(_: &mut Stream, _: &mut Context) -> Self {
        Self
    }

    #[is_ws_upgrade_type]
    #[try_get_websocket_request(body)]
    async fn handle(self, stream: &mut Stream, ctx: &mut Context) -> Status {
        let body_list: Vec<ResponseBody> = WebSocketFrame::create_frame_list(&body);
        stream.send_list(body_list).await;
        Status::Continue
    }
}

How It Works

Route Registration: The #[route("/ws_upgrade_type")] macro maps the WebSocket endpoint to the Websocket struct.
Protocol Detection: The #[is_ws_upgrade_type] attribute checks whether the incoming request is a WebSocket upgrade request.
Frame Extraction: The #[try_get_websocket_request(body)] attribute extracts the WebSocket frame data from the request and binds it to the body variable.
Frame Processing: WebSocketFrame::create_frame_list(&body) converts the raw frame data into a list of response frames.
Response Sending: stream.send_list(body_list).await sends all frames back to the client.

Attribute Macros for Sending

Hyperlane provides several attribute macros for sending data over WebSocket connections:

#[try_send]
#[send]
#[try_flush]
#[flush]
#[closed]

These macros provide fine-grained control over the send operations, including error handling (try_send vs send), flushing buffers, and closing connections.

WebSocket Frame Handling

WebSocket communication revolves around frames. Each frame contains a small header and a payload. Hyperlane abstracts this complexity through the WebSocketFrame type and its helper methods.

Creating Frame Lists

let body_list: Vec<ResponseBody> = WebSocketFrame::create_frame_list(&body);

This function takes raw body data and produces a list of ResponseBody frames ready for transmission. The frame list can then be sent using stream.send_list().

Sending Frames

stream.send_list(body_list).await;

For individual frame sending, you can use:

let data: Vec<u8> = ctx.get_mut_response().build();
stream.try_send(data).await;
stream.send(data).await;
stream.try_send_list(&frame_list).await;
stream.try_flush().await;

Connection Management

After establishing a WebSocket connection, you need to manage its lifecycle:

stream.set_closed(true);
let keep_alive: bool = stream.is_keep_alive(ctx.get_request().is_enable_keep_alive());

while stream.try_get_http_request().await.is_ok() {
    if !ctx.get_request().is_enable_keep_alive() {
        stream.set_closed(true);
        break;
    }
}

This pattern allows you to keep the connection alive for multiple message exchanges and gracefully close it when needed.

Broadcasting with WebSocket

A common use case for WebSocket is broadcasting messages to multiple connected clients. While Hyperlane provides the low-level primitives, you can build a broadcast mechanism by maintaining a collection of connected streams and iterating over them to send messages.

The hyperlane-broadcast utility from the recommended tools list is specifically designed for this purpose, making it easy to implement pub/sub patterns with WebSocket connections.

Server-Sent Events (SSE) Overview

Server-Sent Events (SSE) is a simpler protocol compared to WebSocket. It allows the server to push events to the client over a standard HTTP connection. SSE is unidirectional — only the server can send messages — but it has several advantages:

Simplicity: SSE uses standard HTTP, so it works with existing infrastructure.
Automatic Reconnection: Browsers automatically reconnect if the connection drops.
Text-Based: SSE messages are plain text, making them easy to debug.

SSE is ideal for use cases like live news feeds, stock tickers, progress indicators, and notification streams.

SSE Implementation in Hyperlane

Implementing SSE in Hyperlane involves setting the appropriate headers and then streaming events to the client.

Setting Up the SSE Response

let data: Vec<u8> = ctx
    .get_mut_response()
    .set_header(CONTENT_TYPE, TEXT_EVENT_STREAM)
    .set_body(Vec::new())
    .build();

stream.try_send(data).await;

The key header is Content-Type: text/event-stream, which tells the browser to treat the response as an SSE stream. The body is initially empty — events will be sent incrementally.

Sending SSE Events

for i in 0..10 {
    let body: String = format!("data:{i}{HTTP_DOUBLE_BR}");
    stream.try_send(&body).await;
}

Each event follows the SSE format: data: <message>\n\n. The HTTP_DOUBLE_BR constant represents the double newline that marks the end of each event.

SSE Event Format Details

A complete SSE event can include several fields:

data: — The event payload.
event: — The event type name (optional).
id: — The event ID for reconnection tracking (optional).
retry: — The reconnection time in milliseconds (optional).

In the example above, we use the simplest form with just the data: field.

Client-Side Code Examples

To complete the picture, here is how a browser client would connect to both WebSocket and SSE endpoints.

WebSocket Client (JavaScript)

const ws = new WebSocket('ws://localhost:8080/ws_upgrade_type');

ws.onopen = () => {
  console.log('WebSocket connected');
  ws.send('Hello Server!');
};

ws.onmessage = (event) => {
  console.log('Received:', event.data);
};

ws.onclose = () => {
  console.log('WebSocket disconnected');
};

SSE Client (JavaScript)

const eventSource = new EventSource('http://localhost:8080/sse');

eventSource.onmessage = (event) => {
  console.log('SSE Event:', event.data);
};

eventSource.onerror = () => {
  console.log('SSE connection error, reconnecting...');
};

Both APIs are built into modern browsers, requiring no additional libraries.

WebSocket vs SSE: When to Use Each

Feature	WebSocket	SSE
Direction	Bidirectional	Server-to-client only
Protocol	ws:// (separate protocol)	HTTP (standard)
Reconnection	Manual implementation	Automatic (browser)
Binary Data	Supported	Text only
Complexity	Higher	Lower
Use Case	Chat, gaming, collaboration	Feeds, notifications, dashboards

Choose WebSocket when you need bidirectional communication, binary data support, or low-latency message exchange. Choose SSE when you only need server-to-client push and want simpler implementation with automatic reconnection.

Conclusion

Hyperlane provides robust support for both WebSocket and SSE, enabling you to build real-time web applications in Rust. The WebSocket implementation leverages Hyperlane's attribute macros like #[is_ws_upgrade_type] and #[try_get_websocket_request] to provide a clean, declarative API for handling WebSocket connections. The SSE implementation uses standard HTTP streaming with the text/event-stream content type.

Both protocols have their place in modern web development. WebSocket excels in bidirectional communication scenarios, while SSE shines in simple server-to-client push use cases. By understanding both patterns and leveraging Hyperlane's streaming APIs, you can build responsive, real-time applications that deliver data to users instantly.

The key building blocks — stream.send(), stream.try_send(), stream.send_list(), and the various attribute macros — give you full control over how data is transmitted, while the middleware system ensures clean separation of concerns between your real-time logic and the rest of your application.

Project Code：https://github.com/hyperlane-dev/hyperlane