need to rewire my brain

on the orange website

www.youtube.com/watch?v=6uaq...

building marimo pair has been a new kind of engineering (for me). a lot changes when the consumer of your api is a model rather than another program.

we’ve shipped “breaking” changes without upgrading or migrating the skill. the models just figure it out.

hope you like it :)

the latest release of the @marimo.io @vscode.dev extension adds LSP diagnostics for marimo rules

multiple variable definitions and dependency cycles are flagged as you type:

Snapshotting lets you just capture the full inferred type.

I built up ~1000 lines of these quickly. Things subtly change and that's sometimes fine — snapshotting makes it visible and easy to update.

You just review the diff and accept or fix.

the biggest benefit is catching silent inference regressions or places where inference could be narrower (more precise). types can subtly change without a compile error

you want to check the ~container~ type is correctly distributed, not just the leaves. that's hard to assert and harder to read

I started quiver during my PhD but was stuck on the last mile — exhaustive tests that match inferred types to runtime behavior.

The snapshot idea finally unblocked it and caught some edge cases and bugs. (Thanks for the help, Claude!).

Give it a try and let me know what you think!

Code snippet showing a test for int32 columns. Three variables — col, arr, val — each have a twoslash type snapshot comment below them showing the inferred TypeScript type (Column, Int32Array, number). Below that, runtime assertions check that the actual values match: arr is an instance of Int32Array and val is typeof number.

One thing I'm most happy with is the testing setup. Wrote a utility that snapshots the inferred TS types _inline_ alongside runtime checks of the actual values.

Change something in type inference (quiver) or runtime (flechette) and the snapshots break.

Code snippet showing three levels of schema strictness in quiver. q.js.number() returns a broad union of typed arrays from toArray(). q.int() narrows to integer typed arrays only. q.int32() narrows all the way to Int32Array. All three return number from at().

flechette columns have `toArray()` and `at()`. With quiver, you pick your level of strictness.

The types propagate through `getChild`, `select`, `toArray`, iteration, even into nested structs and lists.

flechette's `tableFromIPC` is to Arrow what `JSON.parse` is to JSON.

quiver is like Zod or Pydantic for that — define your expected schema, check it at parse time, and get a flechette Table with the types overlaid

Code snippet showing quiver's API: import quiver, define a table schema with int32, nullable utf8, and float64 columns, then call parseIPC on bytes. Accessing row values returns fully typed results — name is string | null, score is number.

Introducing quiver: a (type-safe) place to keep your arrows @arrow.apache.org

quiver is a small schema library for Arrow, built on @idl.uw.edu flechette

- Define table schemas in TS
- Validate schemas at IPC parse time
- Get back fully typed Tables (no type-casting)

github.com/manzt/quiver

spent some time last weekend getting higlass to play nicely inside @marimo.io

molab.marimo.io/notebooks/nb...

always fun to jump back into some interaction design work

some details:

- collapsible tree → progressive disclosure of full config
- color → module type (i.e., the `nn` submodule)
- opacity → trainability (e.g., frozen or no params)

A marimo notebook cell showing a TinyVGG model rendered as a collapsible tree. The header shows 8.5M params and 32.3 MB. Layers are color-coded: Conv2d and Linear in blue, BatchNorm2d in green, ReLU in orange, Dropout in red. Each layer shows its config and parameter count.

some of the first things new users notice and love in @marimo.io are our opinionated formatters (e.g., our table for dataframes)

for v0.20.0 I worked on one aimed at AI engineers: a rich formatter for @pytorch.org `nn.Module`

always fun to jump back into some interaction design work. some design details:

- collapsible tree → progressive disclosure of full config
- color → module type (i.e., the `nn` submodule)
- opacity → trainability (e.g., frozen or no params)

A marimo notebook cell showing a TinyVGG model rendered as a collapsible tree. The header shows 8.5M params and 32.3 MB. Layers are color-coded: Conv2d and Linear in blue, BatchNorm2d in green, ReLU in orange, Dropout in red. Each layer shows its config and parameter count.

some of the first things new users notice and love in @marimo.io are our opinionated formatters (e.g., our table for dataframes)

for v0.20.0 I worked on one aimed at AI engineers: a rich formatter for @pytorch.org `nn.Module`

pals

my new bug, minnow

i'm sure there's some magic one could do with bundlers/ts config to configure imports from a bare "zod"... but not too bad

notice the type-only export for UserId, so the only way to have a UserId instance is through `z.userid()`.

i think i recall colin mentioning a pattern of BYOZ(od):

```ts
import * as z from "zod";
export * from "zod";

export type { UserId };

class UserId {/* ... */}

export function userid() {
return z.uuid()
.transform((v) => new UserId(v));
}
```

then,

import * as z from "./zod.ts"

breaking news: dads are learning @marimo.io

thanks for having me!

Announcing our VS Code and Cursor extension Bringing a native marimo experience to your favorite IDE

byoe (bring your own editor) for @marimo.io is here. built from scratch with LSP + uv

marimo.io/blog/vscode

same… i went all in on effect.website for the @marimo.io VS Code extension. started with Schema, and then spread..

testing and error handling have been the biggest wins, but the cohesiveness of all the modules and strong patterns helps for collaboration.

github.com/marimo-team/...

👀 preview: @marimo.io notebooks are Python first inside @vscode.dev.

we're also integrating managed sandboxed environments for PEP 723 notebooks, powered by uv ofc. forget venvs

look ma, @marimo.io 🤝 cursor (w/ the upcoming @vscode.dev extension). things are starting to come together...

the upcoming @marimo.io language server is fully astral stack. code base is small enough that i’m ok with some of the typing TODOs in preference for ergonomics… and astral team is shipping so fast!

a new life for my 2019 macbook pro