Patrick Dubroy
LightNews LightNews
dubroy.com
Patrick Dubroy
@dubroy.com
1.5K followers 270 following 570 posts
Programmer & researcher, co-creator of https://ohmjs.org. ๐Ÿ‡จ๐Ÿ‡ฆ ๐Ÿ‡ฉ๐Ÿ‡ช ๐Ÿ‡ช๐Ÿ‡บ

Co-author of https://wasmgroundup.com โ€” learn Wasm by building a simple compiler in JavaScript.

Prev: CDG/HARC, Google, BumpTop
Posts Replies Media Videos
Pinned
dubroy.com
Patrick Dubroy @dubroy.com ยท Mar 10
Here it is โ€” very happy to officially release the book that @marianoguerra.org and I have been working on for the past 2ยฝ years.

If you bought it in early access, thanks for your support! ๐Ÿ™

If you haven't bought it yet, please check it out!!
wasmgroundup.com WebAssembly from the Ground Up @wasmgroundup.com ยท Mar 10
Excited to announce the official launch of our online book, WebAssembly from the Ground Up! ๐ŸŽ‰

It's the book we wish we'd had 3 years ago.

No messing with tools and frameworks. It's a hands-on guide to the core of Wasm: the instruction set and module format.

Link below. ๐Ÿ‘‡
Learn Wasm by building a simple compiler in JavaScript. No compiler expertise necessary. All the code is in the book; we'll take you through it step by step. Get your hands dirty and see for yourself what WebAssembly is all about.
dubroy.com
It's even responsive!
November 21, 2025 at 3:59 PM
dubroy.com
Definitely one of the cooler language playgrounds I've seen: pinky.cool.omg.lol
November 21, 2025 at 3:46 PM
dubroy.com
Excited to finally release the blog post that @marianoguerra.org has been working on for a while!
wasmgroundup.com WebAssembly from the Ground Up @wasmgroundup.com ยท 5d
Per your request, please find enclosedโ€ฆa new blog post!

A WebAssembly interpreter (Part 1)
โ†’ wasmgroundup.com/blog/wasm-vm...

We build up a simple interpreter from scratch, in JavaScript, for a small subset of Wasm instructions (arithmetic and comparison).
A WebAssembly interpreter (Part 1)
Implementing a Wasm Interpreter to explore its design and semantics
wasmgroundup.com
November 20, 2025 at 2:02 PM
dubroy.com
Interesting, thanks! Apparently it comes from Modula-3.
November 20, 2025 at 5:20 AM
dubroy.com
TIL: Branded types in TypeScript
โ†’ github.com/pdubroy/til/...
Branded types in TypeScript TypeScript is structurally typed: the type system doesn't distinguish between types that are structurally identical. By sometimes you want something more like nominal typing (like C, Java, Swift, Rust, etc.) In TypeScript, it's possible to do that via a pattern known as branded types. I first heard about this a few months ago, but really only learned how it works the other day. An example The book Learning TypeScript uses the example of currency conversion. Suppose you have the following types: type Euro = number; type USD = number; โ€ฆand you wanted to prevent mistakes with mixing currencies, and you don't want to change the runtime representation. Enter branded types! Branded types Here's how we can address this with branded types: type Currency<T> = number & { __brand: T }; type Euro = Currency<"EUR">; type USD = Currency<"USD">; const eur = (amount: number) => amount as Euro; const usd = (amount: number) => amount as USD; function usdToEur(amount: USD): Euro { return eur(amount * 0.87); } usdToEur(usd(35)); // this works // `usdToEur(35)` fails to compiile: // Argument of type 'number' is not assignable to parameter of type 'USD'. // Type 'number' is not assignable to type '{ __brand: "USD"; }'.(2345)``` Note that this is purely in the type system โ€” the runtime values are just numbers. As Learning TypeScript puts it: Branded types are a useful lie to the type system: our positive numbers will never actually have that __brand property. We're just making sure that no developer accidentally provides a value of a non-branded type to a location that requires one that is branded. Also, the name __brand is not important here โ€” we could have used __currency or any other name we wanted. Preventing forging When you use a regular property like __brand, it doesn't prevent someone from forging values: import {usdToEur} from "./currency.ts"; type Greenbux = number & { __brand: "USD" }; usdToEur(50 as Greenbux); To protect against this, you can use a Symbol for the property: const brand = Symbol(); type Currency<T> = number & { [brand]: T }; type USD = Currency<"USD">; If you do it this way, it's no longer purely in the types โ€” your generated JS code will have a const brand = Symbol() (though it's never used). To eliminate that, you can use declare const with unique symbol: declare const brand: unique symbol; type Currency<T> = number & { [brand]: T }; type USD = Currency<"USD">; AFAIK, this is equivalent to the previous example, but it's a type-only declaration.
November 19, 2025 at 7:40 PM
dubroy.com
"Some compiler-development experiences are long slogs where you write code for months without ever having a thing that produces an actual executable that you can run."

"My First Fifteen Compilers" by Lindsey Kuper
blog.sigplan.org/2019/07/09/m...
Backend-first compiler development Although the nanopass approach doesnโ€™t specifically mandate implementing a compiler in a back-to-front manner โ€” starting with code generation and working upward from there โ€” the back-to-front approach was a hallmark of P523 in the year I took it. For me, a first-year grad student who had never worked on compilers before, this way of organizing the work was incredibly motivating: at the end of week one of the course (and at the end of week two, and so on for each week), I had written a compiler! Admittedly, what I had at the end of week one was a compiler for an input language that wasnโ€™t very different from the output language. But it converted code in its input language to honest-to-goodness x86 assembly code on which I could then run an off-the-shelf assembler and produce a working executable. Some compiler-development experiences are long slogs where you write code for months without ever having a thing that produces an actual executable that you can run. But with the back-to-front nanopass approach, we got that hit of gratification every week! Furthermore, thinking of each component of the compiler as itself being a compiler was useful because it encouraged us to structure our code in a readable, modular, and maintainable way, in much the same way that parser combinator libraries support the development of readable, modular, maintainable parsers.
November 18, 2025 at 12:34 PM
dubroy.com
A new blog post โ€”

devlog: garbage collection is useful
โ†’ dubroy.com/blog/garbage...

Trying something new: quick, technical posts about things I'm working on. Let's see if it sticks.
devlog: garbage collection is useful November 14, 2025 A long time ago, I spent a few years working on garbage collection in the J9 Java VM. And even though Iโ€™ve since done mostly done higher-level stuff, having a deeper knowledge of GC has continued to come in useful. Yesterday, it was an insight from one of my favourite GC papers, A Unified Theory of Garbage Collection, which helped me solve a tricky problem. ohmโ€™s incremental parsing Iโ€™m working with a team thatโ€™s using Ohm to parse text documents and render a rich text version in ProseMirror. The goal is bidirectional updates: changes in ProseMirror should propagate to the text version, and vice versa. Ohm supports incremental parsing, which means that if you parse some text and then make a small edit, it can quickly reparse by reusing portions of the previous result.
November 14, 2025 at 4:14 PM
dubroy.com
(Just noticed that the Kotlin doc shows assigning into a temp var, yeah I don't use it that way.)
November 14, 2025 at 10:29 AM
dubroy.com
Sure, I use assertions as well (depends on the situation). But I find checkNotNull very handy for stuff like this:

const newCount = checkNotNull(refCounts.get(node)) - 1;

I generally wouldn't assign the result into a new var, I agree that an assertion or type predicate is preferable then.
November 14, 2025 at 9:13 AM
dubroy.com
In basically every TypeScript codebase I touch, I end up adding a `checkNotNull` function exactly like the one from the Kotlin stdlib.

So useful! Surprisingly I haven't seen many TS resources which mention this specific pattern.
checkNotNull inline fun <T : Any> checkNotNull(value: T?): T(source) Throws an IllegalStateException if the value is null. Otherwise returns the not null value.
November 14, 2025 at 8:05 AM
dubroy.com
Yeah, I'm not sure either. I think the argument is that due to the conversion rules in C++, you aren't (effectively) making the invalid states unrepresentable.

So I buy the argument for C++, but it's less clear to me that it makes sense for languages like Mojo or Odin.
November 12, 2025 at 4:13 PM
dubroy.com
Bjarne Stroustrup: "Subscripts and sizes should be signed" open-std.org/jtc1/sc22/wg...
I will dig into the arguments and consider alternatives, but my conclusion stands: Use signed subscripts and sizes for span as it was deliberately designed to do. The original use of unsigned for the STL was a bad mistake and should be corrected (eventually). Why we have unsigned subscripts in the STL As far as I remember (the STL is 25 years old so my memory may not be completely accurate) three reasons were given for the STL using unsigned types for subscripts โ€ข (As opposed to pointer subscripts) vector subscripts canโ€™t be negative, so unsigned is obviously the right type. โ€ข We get one more bit to play with so we can get larger vectors; this is important on machines with 16-bit address spaces. โ€ข Range checking needs only one check (no need to check for less than 0). I have heard such rationales many times over the years, but โ€ข C/C++โ€™s unsigned is a very odd set of types. They do not model natural numbers. In particular, they have modular arithmetic and conversions to/from signed ints that can be very surprising. Beware of any argument using the word โ€œobviousโ€.
November 12, 2025 at 5:35 AM
dubroy.com
Thanks for writing/sharing this! Definitely interesting, and you're writing is always a pleasure to read.
November 11, 2025 at 5:39 PM
dubroy.com
This seems like such a tiny thing but I always thought using unsigned ints for sizes was the "correct" thing to do, so I do it even though it's generally a little annoying (b/c casts, fretting about whether temp vars should be unsigned or signed, etc.)
November 11, 2025 at 3:52 PM
dubroy.com
Somewhat surprising (to me) advice in Google's C++ style guide:

"Try to avoid unsigned types (except for representing bitfields or modular arithmetic). Do not use an unsigned type merely to assert that a variable is non-negative."

Example of a possible bug: abseil.io/tips/227

(via @wingolog.org)
On Unsigned Integers Unsigned integers are good for representing bitfields and modular arithmetic. Because of historical accident, the C++ standard also uses unsigned integers to represent the size of containers - many members of the standards body believe this to be a mistake, but it is effectively impossible to fix at this point. The fact that unsigned arithmetic doesn't model the behavior of a simple integer, but is instead defined by the standard to model modular arithmetic (wrapping around on overflow/underflow), means that a significant class of bugs cannot be diagnosed by the compiler. In other cases, the defined behavior impedes optimization. That said, mixing signedness of integer types is responsible for an equally large class of problems. The best advice we can provide: try to use iterators and containers rather than pointers and sizes, try not to mix signedness, and try to avoid unsigned types (except for representing bitfields or modular arithmetic). Do not use an unsigned type merely to assert that a variable is non-negative.
November 11, 2025 at 3:45 PM
dubroy.com
A cool paper from OOPSLA '25 โ€”

An Empirical Evaluation of Property-Based Testing in Python
โ†’ dl.acm.org/doi/pdf/10.1...

Some interesting findings:
- "Each property-based test finds about 50x as many mutations as the average unit test"
- "76% of mutations were found within the first 20 inputs"
Property-based testing (PBT) is a testing methodology with origins in the functional programming community. In recent years, PBT libraries have been developed for non-functional languages, including Python. However, to date, there is little evidence regarding how effective property-based tests are at finding bugs, and whether some kinds of property-based tests might be more effective than others. To gather this evidence, we conducted a corpus study of 426 Python programs that use Hypothesis, Pythonโ€™s most popular library for PBT. We developed formal definitions for 12 categories of property-based test and implemented an intraprocedural static analysis that categorizes tests. Then, we evaluated the efficacy of test suites of 40 projects using mutation testing, and found that on average, each property-based test finds about 50 times as many mutations as the average unit test. We also identified the categories with the tests most effective at finding mutations, finding that tests that look for exceptions, that test inclusion in collections, and that check types are over 19 times more effective at finding mutations than other kinds of property-based tests. Finally, we conducted a parameter sweep study to assess the strength of property-based tests as a function of the number of random inputs generated, finding that 76% of mutations found were found within the first 20 inputs To address RQ2, assessing the effectiveness of test categories, we used mutation testing to assess the bug-finding power of each projectโ€™s test suite. Mutation testing or mutation analysis is a method of evaluating a test suiteโ€™s effectiveness. In a mutation test, small changes are made to a programโ€™s source code, called mutations. The mutations are generated by mutation operators, which are syntactic transformation rules. Mutation operators often include swapping arithmetic operators (+ to -), flipping logical operators (and to or), and changing literals. The test suite is then run on the mutated program, and if any test fails, then the mutation is considered caught or killed. If no test fails, then the test suite did not identify the bug. The number of mutations caught is the test suiteโ€™s mutation score, and a higher score is indicative of a more robust test suite.
November 8, 2025 at 7:31 PM
Reposted by Patrick Dubroy
developer.chrome.com
Ever thought about writing #WebAssembly by hand? ๐Ÿค”

Authors Patrick @dubroy.com and @marianoguerra.org think it's crucial for learning. They join #WasmAssembly host Thomas Steiner to discuss their ebook, "WebAssembly from the Ground Up" โ†’ goo.gle/3Ln67Pp
WebAssembly from the Ground Up with Patrick Dubroy and Mariano Guerra
November 4, 2025 at 9:00 PM
dubroy.com
Did you know that Microsoft MakeCode (a Scratch-like coding environment) supports a variant of TypeScript called "Static TypeScript"?

github.com/microsoft/px...

Also described in a 2019 MPLR paper: www.microsoft.com/en-us/resear...
Static TypeScript ~ hint This is a draft reflecting the design of Static TypeScript (STS) - not exactly what is implemented, but quite close. Comments welcome. ~ TypeScript is a typed superset of JavaScript designed to enable JavaScript developers to take advantage of code intellisense, static checking and refactoring made possible by types. TypeScript is gradually typed, meaning that types are optional. Type inference helps to assign types to untyped code. In this document, we define a subset of TypeScript called Static TypeScript (STS, for short), which was created to make it possible to use a scripting language to program physical computers based on microcontrollers with small amounts of memory. The first use of Static TypeScript is for the micro:bit, which has 16Kb of RAM. The best way to think of STS is as C#/Java/C++ subset of TypeScript where all types are known at compile time, which permits efficient linking to a C++ runtime (in the case of the micro:bit, the Lancaster University micro:bit DAL). STS tries to maintain as much of JavaScript semantics as much as possible, given the constraints imposed by a static typing discipline. Goodbye to Any, Union, Intersection Types and the Bad Parts In TypeScript, the Any type is โ€œthe one type that can represent any JavaScript value with no constraintsโ€. In TypeScript, every program expression, value, and function must have some type, even if not explicitly provided by the programmer. Per the TypeScript Language Reference: โ€œin places where a type is not explicitly provided and TypeScript cannot infer one, the Any type is assumed.โ€ STS does not permit use of the Any, Union and Intersection types. The result of this is that STS disallows programs where a program element can denote many kinds of runtime values (for example, a variable that is a string at one point in execution and a number at another point, as specified by the union type string | number). Static TypeScript: An Implementation of a Static Compiler for the TypeScript Language. Abstract: While the programming of microcontroller-based embeddable devices typically is the realm of the C language, such devices are now finding their way into the classroom for CS education, even at the level of middle school. As a result, the use of scripting languages (such as JavaScript and Python) for microcontrollers is on the rise. We present Static TypeScript (STS), a subset of TypeScript (itself, a gradually typed superset of JavaScript), and its compiler/linker toolchain, which is implemented fully in TypeScript and runs in the web browser. STS is designed to be useful in practice (especially in education), while being amenable to static compilation targeting small devices. A userโ€™s STS program is compiled to machine code in the browser and linked against a precompiled C++ runtime, producing an executable that is more efficient than the prevalent embedded interpreter approach, extending battery life and making it possible to run on devices with as little as 16 kB of RAM (such as the BBC micro:bit). This paper is primarily a description of the STS system and the technical challenges of implementing embedded programming platforms in the classroom.
October 31, 2025 at 8:58 AM
Reposted by Patrick Dubroy
mattkeeter.com
jumpscared by my own research paper appearing halfway down this blog post
dubroy.com Patrick Dubroy @dubroy.com ยท 27d
A blog post from last year, which I never posted here โ€”

Bytecode VMs in surprising places
โ†’ dubroy.com/blog/bytecod...
Bytecode VMs in surprising places April 30, 2024 In response to a question on Twitter1, Richard Hipp wrote about why SQLite uses a bytecode VM for executing SQL statements. Most people probably associate bytecode VMs with general-purpose programming languages, like JavaScript or Python. But sometimes they appear in surprising places! Here are a few that I know about. eBPF Did you know that inside the Linux kernel, thereโ€™s an extension mechanism that includes a bytecode interpreter and a JIT compiler? I had no idea. Well, itโ€™s called eBPF, and itโ€™s pretty interesting: a register-based VM with ten general-purpose registers and over a hundred different opcodes.
October 29, 2025 at 11:47 PM
dubroy.com
Periodic reminder (since I apparently don't talk about it enough) โ€”

If you are interested in a hands-on way to learn #wasm, check out the book that @marianoguerra.org and I wrote together!
wasmgroundup.com WebAssembly from the Ground Up @wasmgroundup.com ยท Mar 10
Excited to announce the official launch of our online book, WebAssembly from the Ground Up! ๐ŸŽ‰

It's the book we wish we'd had 3 years ago.

No messing with tools and frameworks. It's a hands-on guide to the core of Wasm: the instruction set and module format.

Link below. ๐Ÿ‘‡
Learn Wasm by building a simple compiler in JavaScript. No compiler expertise necessary. All the code is in the book; we'll take you through it step by step. Get your hands dirty and see for yourself what WebAssembly is all about.
October 29, 2025 at 12:29 PM
dubroy.com
Oh, cool! Looks like you actually took a very similar approach :-)
October 29, 2025 at 12:05 PM
dubroy.com
Working on a diagram for an upcoming @wasmgroundup.com blog post.
Diagram showing WebAssembly bytecode execution with a horizontal memory strip containing hexadecimal values (41 03 41 02 6c 41 04 6a 0a 46). Above the strip are labels 'instructions' and 'pc' (program counter) with arrows pointing to specific bytes. The program counter highlights byte '6c'. Below the strip, purple arrows point to different instruction bytes, labeled with their corresponding WebAssembly operations: 'i32.const' (pointing to 41 03 and 41 02), 'i32.mul' (pointing to 6c), 'i32.add' (pointing to 6a), and 'i32.eq' (pointing to 46). On the right side is a stack representation showing values '2' and '3' in rectangular boxes.
October 29, 2025 at 10:24 AM
dubroy.com
(Needed a thread here where I can post new examples!)

Dodrio (by Nick Fitzgerald) is an experimental virtual DOM library for Rust and Wasm. It uses bump allocation for the VDOM nodes and uses a stack machine language to represent change lists: github.com/fitzgen/dodrio
Change List as Stack Machine The change list that represents the difference between how the physical DOM currently looks, and our ideal virtual DOM state is encoded in a tiny stack machine language. A stack machine works particularly well for applying DOM diffs, a task that is essentially a tree traversal.
October 29, 2025 at 7:25 AM
dubroy.com
A blog post from last year, which I never posted here โ€”

Bytecode VMs in surprising places
โ†’ dubroy.com/blog/bytecod...
Bytecode VMs in surprising places April 30, 2024 In response to a question on Twitter1, Richard Hipp wrote about why SQLite uses a bytecode VM for executing SQL statements. Most people probably associate bytecode VMs with general-purpose programming languages, like JavaScript or Python. But sometimes they appear in surprising places! Here are a few that I know about. eBPF Did you know that inside the Linux kernel, thereโ€™s an extension mechanism that includes a bytecode interpreter and a JIT compiler? I had no idea. Well, itโ€™s called eBPF, and itโ€™s pretty interesting: a register-based VM with ten general-purpose registers and over a hundred different opcodes.
October 29, 2025 at 7:19 AM
dubroy.com
Looking forward to this tomorrow!
wasmgroundup.com WebAssembly from the Ground Up @wasmgroundup.com ยท 29d
This week the W3C WebAssembly Community Group is holding an in-person meeting in Munich.

We (@dubroy.com and @marianoguerra.org) are planning to be there. Patrick tomorrow, and both of us on Thursday for the Research Day.

If you see us, come say hi!
October 27, 2025 at 4:44 PM