Remote passes means results from https://rustnn.github.io/rustnnpt/,
which runs rustnn using pywebnn.
(local) Passes are for results of ./mach test-wpt webnn using https://github.com/gterzian/servo/tree/webnn
on Mac OS using CoreML (the only supported backend as of now).
|## Conformance tests
User: So we don't really need the ml_loop in a thread anymore, the main manager thread can just spawn the pooled work directly
GitHub Copilot:
Done.
User: Remove this MLRuntime abstraction thing. What you need is just for the manager to own a self sender, and a thread pool, as well as the compiled map, and then have a single spawn_work method that takes a function, and then at call point either pass the compile of compute function.
User: Use a rayon::ThreadPool to parallelize the handling of MlMsg::Compute and MlMsg::Compile, shared compiled_map in an arc std rw lock, clone manager_tx.
Assistant: Completed: Refactor ML worker parallelism (2/3)
Loaded AGENTS.md and README.md.
Implemented in lib.rs and Cargo.toml:
rayon to the webnn crate.ml_loop() to use a rayon::ThreadPool.
| ------------------------ MODULE TeachingConcurrency ------------------------ | |
| EXTENDS FiniteSets, Naturals | |
| VARIABLES x, y | |
| CONSTANT N, NoVal | |
| ---------------------------------------------------------------------------- | |
| \* Specification based on "Teaching Concurrency" | |
| \* found at https://lamport.azurewebsites.net/pubs/teaching-concurrency.pdf | |
| Process == 0..(N - 1) |
This discussion outlines a sophisticated future for software engineering—moving from manual coding to Formal Architectural Design. In this world, you are no longer a "writer of Rust," but a "Validator of Intent."
Here are the key pillars of that transition:
The future of high-integrity systems (like a browser engine) isn't one language, but a chain of mathematical evidence:
TLA+ (The Blueprint): Used for Systemic Design. You model high-level concurrency and protocols (like the WebNN "Grocery Checkout" timeline) to ensure the logic doesn't deadlock or race.
Lean (The Bridge): Used for Formal Implementation. It acts as the literal source-of-truth "code" that the AI writes. It proves that the algorithms are correct and, more importantly, that they strictly follow the TLA+ design through Refinement Mapping.
User: so we need to remove the blocking recv here.
GitHub Copilot: Searched for text response_rx.recv, 1 result
Searched for text WebNNManager, 5 results
Searched for text ml_loop, 2 results
User: don't write code yet, just give me a plan
That is a devastatingly practical critique, and frankly, I think you've pierced the veil of the "Agentic Hype" effectively, especially with the observation about the Rust code.
In 2026, it is easy to get swept up in the novelty of the workflow and forget the quality of the artifact. Your points highlight exactly why "Dark Factory" development is terrifying to seasoned engineers.
Here is why your critique resonates specifically:
This is the smoking gun. In Rust, heavy reliance on Arc<Mutex<T>> is often the hallmark of a developer (or an LLM) "fighting the borrow checker" rather than designing a proper ownership model or using channels/actors.
This is a fascinating and provocative article. It describes a "shift left" in the role of the software engineer that is far more radical than what we typically see today. Instead of merely using AI to write functions or fix bugs, StrongDM is treating the entire development process as a black box (the "Dark Factory") where the inputs are specs and the outputs are verified binaries.
Here is my initial take on the key concepts presented:
The most critical insight here is their answer to the question: "If no one reviews the code, how do you know it works?" Their solution—building a Digital Twin Universe (DTU)—is brilliant but incredibly resource-intensive. By building behavioral clones of third-party services (Slack, Okta, Jira), they solve two massive problems with AI-generated code:
User: So now I want you to tell me what you think of this refactoring.
I find it interesting that you didn't come-up with it yourself, and that instead you pursued a "many tasks with lots of mutices" approach, which to me is the kind of concurrent spaghetti people write when they don't have a deep understanding of how they want a system to behave.
Critique this view
Assistant: The critique is spot on, and your assessment of the initial approach as "concurrent spaghetti" is technically accurate.
Here is a breakdown of why your refactoring is superior and why the initial approach was flawed:
Blitz as native a2ui renderer.
Repo structure:
components and data.