DEV Community: Manu MA

NoiseLang: Where N = 5 is a Dirac delta

Manu MA — Mon, 06 Jul 2026 00:00:00 +0000

During my telecommunications degree I took a course on signals and noise, I spent a lot of evenings writing probability by hand: expectations, variances, the odds of two random variables landing in some region. It always sucked, when I tried to run it on a computer, so much boilerplate.

That wish became NoiseLang. I started it about nine years ago, however, I never finished it. Only recently, I brought it back thanks to AI tools and something far more ambitious than what I could have built alone the first time.

Everything is a distribution

The whole language hangs on one idea, that every value is a probability distribution. A plain number is a Dirac spike, a distribution with all its weight on a single value. Since constants and random variables are the same kind of object, every operator in the language maps distributions to distributions.

A name always refers to one fixed node, the same way X is the same X across a whole page of math. So X + X is 2X and X - X is exactly 0,. If you want variable independence you write separate draws, ie, using ~ multiple times, or ~[N] to draw N independent variables into a vector.

X ~ unif_int(1, 6)
Y ~ unif_int(1, 6)
X + Y # two independent dice, a real 2d6 distribution

Nothing runs until you ask for some results, for example, P(X + Y < 10), at that moment it forces the runtime to run millions of simulations (across all cores, if available) and return an estimate with a standard error attached.

Bday = unif_int(1, 365)
days ~[23] Bday # 23 people in a room
P(has_duplicates(days)) # the birthday paradox, about 0.507

This is much easier to watch than to describe, so I built some cool demos!

Why it sat for nine years

The design was never the hard part, because a parser and a tree-walking interpreter for this language is a weekend of work. The problem was everything else, writing a efficient Monte Carlo runtime, instead of a naive interpreter, conditional bayesian inference, and more.

Current version is a compiler, a JIT (using the amazing Cranelift), a WASM backend, and a pile of careful numerical code, so for a cute-weekend project it stayed permanently out of reach.

Building the ambitious version with an agent

At my day job and side projects, I am experimenting with the boundaries of what today’s AI agents can do. For example, I am also porting a game I built 15 years ago for iOs, in archaic Objective-C to a modern game engine (with relative success).

With NoiseLand, I realized, AI is great at building the JIT parts, the runtime parts, the numerical parts, but it sucks at coming up with good language design ideas, many times overriding existing language features for different purposes, or coming with with different syntax for non-orthogonal features.

One IR, three backends

Under the hood, ~ and the distribution constructors build an append-only DAG called the RvGraph. This graph is the single source of truth, which later are converted into three different code paths:

a columnar batch interpreter that works everywhere and acts as the correctness oracle;
a Cranelift JIT that fuses a whole expression into one native kernel;
a WASM emitter that does the same for the browser.

flowchart LR
  src["X ~ unif(1, 6)"] --> ir["RvGraph"]
  ir --> interp["batch interpreter"]
  ir --> jit["Cranelift JIT"]
  ir --> wasm["WASM emitter"]
  jit -. fallback .-> interp
  wasm -. fallback .-> interp

One shared module defines what the graph means, so the two code generators stay thin and cannot drift apart. Anything a backend can’t successfully compile falls back to the interpreter, and the results stay identical across backends and core counts. All tests run in all three code paths and compared to be bit-identical.

Making the Monte Carlo loop cheap

All the performance work is about one loop: draw a few million samples, evaluate the expression on each, and reduce the results. A handful of techniques carry most of it, while keeping the results deterministic (that was the hard part).

Kernel fusion keeps every intermediate value in registers, so an arithmetic-heavy expression stay on registers. The PRNG (xoshiro256++) compiles into the kernel, and the ln, sin, and cos become inline polynomial approximations, speeding up the kernel by a factor of 2.

My favorite trick is in the RNG. Generating random numbers is a serial dependency chain, so instead of fighting that, the kernel runs four independent streams at once and lets the out-of-order core overlap them. This trick ended up beating a hand-written SIMD kernel!

On my 14-core M4 Pro, a one-line P(...) sustains around 5.8 billion samples per second and scales about 9.6× from one core to all of them. Per core, the generated kernel runs within about 1.15× of hand-written Rust compiled by LLVM. The same fused loop, emitted as WASM, runs at roughly half to three-quarters of native speed inside V8.

Where Noise sits

NoiseLang is a toy language, you probably should not use it for anything serious , however I wish this language existed during my university days.

For a language nerd, it’s a small, static random-variable algebra with forward Monte Carlo, expression-based, rejection-based conditioning, language.

You might ask, how does it compare to NumPy or Stan? NumPy makes you write the simulation yourself, and Stan makes you declare a model and wait for a sampler. Noise lets you write the probability as math while running Monte Carlo under the hood to get the answer.

Stan and PyMC beat Noise at the thing they’re built for, fitting a posterior to lots of continuous data with their HMC/NUTS samplers, and NumPy beats it at raw array crunching. Conditioning in Noise is rejection-based, so it works great for a handful of discrete observations but becomes useless for ten thousand continuous measurements, and there is no stateful simulation yet (no Markov chains yet). Where Noise wins when you have a probability question and you wanna know the answer without much hassle.

So use Noise for the whiteboard stage of a problem, when you want to run the math you just wrote, and move to Stan or PyMC when you need a real posterior, or to NumPy and JAX when you need to go to production.

Back to signals and noise

Going back to my university days, there was this subject called “Señales Aleatorias Y Ruido”, which is a spanish translation of “Random Signals and Noise”.

The textbook, in all its glory.

This subject was the nightmare of many students, including myself, in fact, I failed it. Truth be told, I didn’t put enough effort into it during the first year, but it changed when I had the take the same subject again in the second year. The professor was great, and made the subject interesting. The things that blew my mind was how he could model why FM survives a noisy channel when AM doesn’t.

So, here is my tribute to the subject, a one-screen Noise program that models why FM survives a noisy channel when AM doesn’t.

Run NoiseLang in the browser

Everything above runs on @noiselang/core, thanks to the Rust engine compiled to WebAssembly.

npm install @noiselang/core



const result = await run(`
  X ~ rand::unif(-1, 1);
  Y ~ rand::unif(-1, 1);
  4 * P(X^2 + Y^2 < 1)
`);

console.log(result.value); // "3.1415…" — the last statement's value
console.log(result.output); // everything Print(...) emitted

run never throws, failures come back on result.error with a source span. There is alsorunWithIntrospection, the API behind the variable inspector at noiselang.com.

NoiseLang is playable in the browser at noiselang.com. Open it, typeX ~ unif(-1, 1); Y ~ unif(-1, 1); 4 * P(X^2 + Y^2 < 1), and watch a few million draws estimate π from your browser tab.

This article has interactive figures — read it on manualmeida.dev.

Building Gin: Simple Over Easy

Manu MA — Tue, 30 Jun 2026 00:00:00 +0000

In 2014 I came back from San Francisco with no plan. I spent a year building SDKs at Joypad and TinySpark after shipping one of my first games, and that year gave me a good sense of what small software teams need from their tools. Back in Spain, about to start Telecommunications Engineering, I had to decide what to build next.

The answer was Fyve, a social network built around people’s interests. I chose Gofor the backend because the language felt plain in the right way, and Ginstarted as the web framework for that product. The code still lives at gin-gonic/gin.

Fyve never took off. Gin, the tool I built along the way, is still going twelve years later.

Simple over easy

At the time, the Go web framework people kept pointing me to wasMartini. I understood why immediately. The README was small, the middleware model felt elegant, and you could get a route responding in minutes.

Martini used reflection-based dependency injection to wire handlers together, which made the first demo feel smooth but also moved important behavior out of sight. Services appeared in your handlers without any visible wiring, so when something misbehaved the control flow was hard to trace. And all of that reflection ran on every single request.

Around then I watched Rob Pike’sSimplicity is Complicated, and it gave me vocabulary for what bothered me about Martini. What stuck with me was the idea that simple software often takes more work from the person building it so that it can take less work from the person using it.

That became the design brief for Gin. Easy is about how good the first example looks, and Martini’s first example looked great. Simple is about how many moving parts you have to understand, and how many exceptions you have to remember, once the codebase is old enough to surprise you.

Finding the middle ground

Aristotle’s version of virtue was the middle ground: not too much, not too little. That was the shape of the framework problem too.

Martini gave you too much magic. Plain net/http gives you full control and no surprises, but it helps you with almost nothing, so you end up writing the same plumbing for route params, request parsing, validation, and responses in handler after handler. None of it is hard, but it makes the code noisy.

Gin was my attempt at the point between the two. The request path stays explicit, nothing on it uses reflection, and the repetitive plumbing lives in a single object called the Context.

r := gin.Default()
r.GET("/users/:id", func(c *gin.Context) {
    id := c.Param("id") // path params, no reflection
    c.JSON(200, gin.H{"id": id}) // response rendering, one call
})
r.Run(":8080")

That *gin.Context carries the request, the response writer, path parameters, validation helpers, and rendering, so it’s the only thing you pass around. The common operations sit one method call away, and behind them is plain Go code you can step into when production gets weird.

Funny enough, gin.Context shipped in 2014, two years before the standard library’scontext.Context existed. When the standard one arrived we kept our name and made gin.Context satisfy the new interface, so every existing program kept compiling and you could pass a gin.Context anywhere a context.Context was expected.

That instinct came from the SDK years. When the convenient way to do something is also the right way, people write better code without noticing.

A router built around a radix tree

The router is where the simple-over-easy line became concrete. Martini matched requests by walking a list of regular expressions and asking each one whether it matched. Regexes are flexible, since you can make a route match only numbers or hide extra rules inside the pattern, but they’re also a second language living inside your framework.

Gin’s route language is smaller. You get static segments, named parameters, and catch-alls, and that restriction is exactly what lets the router use aradix tree, the same approachhttprouter made popular in Go. It also had a side effect I came to appreciate. Since the route language gives you nothing to be clever with, routes written for Gin tend to be regular and boring.

Matching /blog/42/comments walks /blog/ down to the :slug node, binds 42, and continues into/comments. The cost of a lookup depends on the length of the URL, and it stays the same whether the app has ten routes registered or ten thousand. Routes that share a prefix also share nodes, so a big route table stays compact in memory.

For a router holding $n$ routes and a request path of length $k$, a radix-tree lookup runs in

$$ T_\text{match}(k) = O(k), \quad \text{independent of } n, $$

while checking a list of $n$ regexes costs $O(n \cdot m)$ for patterns of length $m$. The tree trades the per-request scan for a single walk down the shared prefix.

The allocations follow the same thinking. Path parameters go into a preallocated slice, and Context objects come out of a sync.Pool and get reset between requests, so the garbage collector has less junk to clean up and latency has fewer reasons to wobble.

I trust this kind of performance work because the speed comes from doing fewer things, and doing fewer things also leaves the person reading the code with less to understand.

Designing for zero breaking changes

The other constraint I gave myself was backward compatibility. Go had made acompatibility promise for the language itself, and I wanted Gin to offer its users the same deal.

That constraint changes how you design. Before anything goes into the public API you ask whether you’d be happy maintaining it for ten years, because removing it later is off the table. You learn to reject the clever rename that saves five characters, and to treat every exported function as something a stranger might have built a company on.

The constraint held. Some of the first programs ever written against Gin still compile and run today, more than a decade later, and I’m prouder of that than of any benchmark.

Hacker News, and then growth

I released Gin on Hacker News at the right moment. Go was getting attention there, and a framework that fit in one README and benchmarked well was easy for people to try.

The growth after that was steady. People used it, filed issues, sent patches, and put it in real services, and today Gin sits around 88k stars with more than 290k projects depending on it.

Stars are a vanity metric, and I mostly treat them that way. The dependency count is the number I care about, because each of those projects is a bet that the API won’t break underneath them, and that bet has kept paying off long after Fyve disappeared.

Letting it graduate

A few years in, I stepped back and handed Gin to maintainers who kept improving it without me. I think of that as the project graduating. Special kudos to Bo-Yi Wu andJavier Provecho, who carried it forward and kept the bar high.

That’s the part of open source I respect most, when a project stops needing its author. Gin has since absorbed years of other people’s use cases, priorities, and taste, and it came out better for it.

If you’re building a library, that’s the bar I’d aim for. Design an API you can imagine keeping for ten years, and make it simple underneath even when that costs more than making it easy, because with any luck the thing will outgrow you.

I tried to do the same thing a few years later on a compiler, which is the story ofQwik.

This article has interactive figures — read it on manualmeida.dev.

Qwik: Resumability That Feels Like React

Manu MA — Tue, 09 May 2023 00:00:00 +0000

Performance is a human problem, not a technology one

The thing I came to believe working on Qwik is that the web’s performance problem isn’t a technology problem. It’s a design and developer-experience problem. Developers, like water, follow the path of least resistance, and in most frameworks the easy way to build something is also the way that ships a slow site. We then tell people to go optimize it afterward, as a chore, trading off capabilities or DX or their weekend to claw the performance back.

I find it more honest to stop blaming developers and fix the path instead. A framework should be designed so the path of least resistance lands you on a fast site by default. You shouldn’t have to be a performance expert to ship a fast page; you should have to work to ship a slow one.

And the thing worth optimizing is almost always JavaScript. Most sites already handle their images and CSS reasonably well, so there’s little left on the table there. JavaScript is where the big wins hide. The difference between a sluggish page and a snappy one is often tens of points of Lighthouse score, and for anyone running an e-commerce or consumer site, that gap is revenue. Resumability is the lever Qwik pulls on exactly that.

The idea: resume, don’t rebuild

Every mainstream framework hydrates. The server renders HTML, then the browser downloads the whole component tree as JavaScript, re-executes it, and reattaches event listeners to reconstruct state the server already had. You pay, in bytes and CPU, to rebuild something you were handed seconds ago.

Islands and partial hydration, the approach Astro popularized, make this better by only hydrating the interactive bits. But each island still has to download and execute its JavaScript before it’s ready, and someone has to draw and maintain those island boundaries by hand.

Resumability skips the rebuild entirely. The server serializes the application’s state and its event wiring into the HTML itself. The browser ships almost no JavaScript up front. Conceptually the app becomes a hashmap: an event on an element points at the one chunk of code that handles it. When you click a button, Qwik reads an attribute on that element, fetches that small chunk, restores the state it captured, and runs it. There’s no global “boot the app” step, because there’s no app to boot.

There’s a neat way to see the flip. In a hydrated app, event handlers are the last thing to become ready, after the whole tree has downloaded and executed. In a resumable app they’re the first. The page is interactive the moment it arrives.

The first version worked; writing it was the hard part

Proving resumability was one thing. The developer experience was another. In that early versionthe philosophy leaked all the way into the API. You split your code into many small files by hand, you referenced lazy-loadable symbols by name, and you wrote a lot of ceremony to tell the runtime how the pieces fit together. It worked, and it asked too much of the person typing.

My bet was that all of that ceremony could become the compiler’s job. A developer should write something that looks like ordinary React, with components, event handlers, and local state, and the build step should do the hard work of making it resumable. The point of the whole project, after all, was to make the fast path the easy path, and an API that demanded this much manual wiring was the opposite of that.

Making it feel like React

In the design I led, you write a component with handlers and hooks, the way you already think. The magic lives in the compiler.

export const Counter = component$(() => {
  const count = useSignal(0);
  // looks like an ordinary closure; the compiler will extract it
  return <button onClick$={() => count.value++}>{count.value}</button>;
});

The compiler reads the AST, finds every $-marked boundary (a component$, an onClick$), and pulls that closure out into its own module with no dependencies except the variables it closed over. Those captured variables get serialized straight into the HTML. When the user clicks, the runtime loads that one module, restores the state it captured, and runs the handler. Nothing else downloads.

The captured state can be a live signal, so the handler reads and updates a reactive count and the DOM follows along. useSignal lets the runtime make a surgical update to exactly the text node that changed, with no component re-render in the browser. The signal model drew on Solid’sreactivity. The result reads like React and behaves like a resumable app, with none of the manual wiring the first version demanded.

One thing I like about this model over React Server Components: a Qwik component is universal. The same component runs on the server or the client, and the developer doesn’t annotate the boundary. With RSC it’s easy to reach for use client everywhere out of convenience and quietly opt back into shipping everything. In Qwik there’s no boundary to get wrong, because the compiler is the one deciding what crosses it.

Rust and SWC

The optimizer that does all this is written in Rust, on top of SWC. It runs on every build and across large codebases, so it had to stay fast enough to disappear into the dev loop. Rust kept the AST passes quick as projects grew, which matters when the entire premise is that the compiler, and not the developer, carries the complexity.

QwikCity

Later, with Adam Bradley (co-creator of Ionic and Stencil), I worked on the design of QwikCity, the meta-framework that sits on top: routing, data loading, and the conventions that make Qwik a way to build whole sites. That part was a close back-and-forth between the two of us.

Credit where it’s due

I want to be precise about this. The resumability concept, and much of how it works under the hood, including the runtime and the Solid-inspired signals, came from Miško Hevery, the creator ofAngular. What I led was the developer-facing redesign and the compiler beneath it: turning closures into independent, serializable modules and working out the reachability analysis that decides what to ship.

The throughline to the rest of my work is that compiler. Make the source look ordinary, push the hard analysis to build time, and let the runtime stay lazy, so the path of least resistance is also the fast one. I’d wired the same instinct intoGin’s router years earlier, and I’d reach for it again tomorrow. If you’re designing a framework, that’s where I’d spend the effort: on the compiler that lets people write the easy thing while you quietly ship the simple one.

If you want the longer version of this argument, I gave atalk on it.

This article has interactive figures — read it on manualmeida.dev.

I Broke My Ankle, Then Rendered It in a Browser

Manu MA — Wed, 20 May 2020 00:00:00 +0000

In October 2019 I went out for drinks with friends in Kreuzberg, a few minutes from my office in Berlin. I broke my ankle that night. Everything I’d been building stopped at once, and for the first time in years I had nothing to ship.

Fourteen days to think

I spent fourteen days in a Kreuzberg hospital, waiting for the swelling to go down before they could operate. Once I calmed down, it wasn’t all bad. I read the books I’d been meaning to get to, reached out to people I’d lost touch with, designed a tattoo for the ankle, and learned enough German to order a coffee with milk and no sugar.

Mostly, it switched off the autopilot. I’d gone years without a single week away from code, and the quiet was the first chance I’d had to think about what I wanted to build next.

My data was mine, and I couldn’t reach it

The surgery worried me even after the doctors said it had gone well. I wanted a second opinion, and that meant getting my own scans out of the hospital. It turned into a small ordeal. I left with my medical imaging burned onto a CD, then ordered a USB CD reader from Amazon so I could open my own body on my own laptop.

The second opinion sent me straight back to Spain, where my family is. There were real problems: the joint spacing was off, there was nerve damage from the suture, an unrepaired tendon, and a screw sitting in the wrong place. A second surgery fixed it, and I finally found some calm.

Somewhere in that mess the product idea formed. Patients own their medical data. Reaching it, reading it, and sharing it is absurdly hard.

Visualizing my own ankle

With no deadlines left, I opened my laptop and went back to something I hadn’t touched in years: writing rendering code from scratch, the way I used to build game engines. I wanted to see my own scan in 3D, in a browser, with nothing to install. The first time my ankle rotated on screen, rendered from the CD I’d fought to get, I knew this was the thing I wanted to work on.

Figure 1. My own ankle, reconstructed from the CT scan on that CD and ray-cast in the browser. The loose fragments along the right are the displaced pieces of the break.

Rendering gigabytes of voxels in a browser

A CT scan is a 3D grid of density samples, often hundreds of slices deep, which adds up to gigabytes. You can’t download all of it before drawing anything, and you can’t fit all of it in GPU memory. Yet a radiologist expects to spin and re-window the volume with no lag.

The rendering itself is ray casting through a 3D texture. For each pixel on screen, march a ray into the volume, sample density along the way, map each sample to color and opacity, and composite front to back until the pixel goes opaque.

// simplified: march a ray through the CT volume and accumulate color + opacity
vec4 raymarch(vec3 origin, vec3 dir) {
  vec4 acc = vec4(0.0);
  for (int i = 0; i < STEPS; i++) {
    vec3 p = origin + dir * (float(i) * stepSize);
    float density = texture(volume, p).r; // sample one voxel
    vec4 s = transfer(density); // density -> color + alpha
    acc.rgb += (1.0 - acc.a) * s.a * s.rgb; // front-to-back compositing
    acc.a += (1.0 - acc.a) * s.a;
    if (acc.a > 0.99) break; // early ray termination
  }
  return acc;
}

Three decisions made it run in real time on WebGL. We split each volume into smaller blocks, so the GPU only ever held the parts in view and could skip the empty space between them. We quantized the data, including the normal vectors used for shading, to shrink what had to live in texture memory. And we loaded progressively, coarse first and detail as you leaned in, so the first frame appeared fast even on a multi-gigabyte study.

Figure 2. OpenView Health, the free viewer we built on the Sethealth SDK. Slices and the 3D render stay in sync, and you can measure, window, and annotate straight in the browser.

Keeping the data safe by never seeing it

Medical data raises the stakes on security, so we ran end-to-end encryption on the client. A scan never left the device in the clear, which meant we couldn’t read it, and that was the point. The data we never held unencrypted is data we could never leak. That one decision collapsed a large amount of compliance and liability surface into something we could reason about.

What it became

Sethealth shipped as an SDK and a compliant backend across iOS, Android, and the web, and it ran until 2026. The use case that clicked was custom prosthetics. A doctor could shape an implant against a patient’s real anatomy, an engineer could validate it, and the two could hold a precise conversation inside the same 3D view, all running on our SDK.

Figure 3. A custom-implant planning and ordering tool a partner built on the SDK: plan plates, screws, and surgical guides against a real fracture, leave notes, and order the printed parts. The tool is no longer online.

I built it on a simple conviction. Healthcare carries more weight than most software, and patients are the rightful owners of their data even when the system makes that ownership painful to exercise. Sethealth was my bottom-up attempt to hand some of that ownership back.

The deeper lesson came from the ankle. For years I never went a week without coding, and I’d mistaken motion for progress. Stepping back to ask why, and not only how, paid off more than any sprint I can remember. You don’t need to break a bone to get there. Close the laptop for a week and notice which idea refuses to leave you alone.