Writing
Notes from the build
Longer pieces about the parts that turned out to be interesting — what the APIs should look like, and what the measurements actually say.
-
Arrow through shared memory, between two processes
What each way of handing Arrow data across a process boundary costs, and how to pick one.
-
Arrow Flight to integrate your Mojo code in your legacy pipelines
Flight allows you to distribute processing between servers.
-
DuckDB and Mojo: a sound example
Five audio features as ordinary SQL expressions, computed in Mojo on the bytes of the DuckDB vector. What it guarantees, what it costs to carry, and where the speed actually comes from.
-
One source tree, two Mojo versions
Mojo 1.0 and nightly will diverge over time. Here is one possible pattern on how to handle that.
-
The parquet.mojo performance bar
Flat columnar reads are ahead of pyarrow on one core and on four, writes are at parity, and nested data loses before threading comes into it.
-
Multithreading with origins in Mojo 1.0
The typed context in the previous post erased the origin of the state it shared, and the compiler destroyed that state before the threads started. Here is the one-line fix, the library change behind it, and a test harness that holds the compiler to what it catches and what it does not.
-
The parquet.mojo correctness bar
Our native Parquet reader now reads 66 of the 69 files in Apache's own corpus.
-
Writing async-like code in durable execution
Write straight-line Mojo. If the process dies halfway through, it resumes without redoing the work that already succeeded. Here is the whole API, and how to handle every way a step can fail.