Apache Thrift serialization in pure Mojo — compact and binary protocols — plus every struct, union and enum of the Parquet metadata schema, generated ahead of time.
- TCompactProtocol and TBinaryProtocol behind one trait
- All of parquet.thrift, pre-generated
- Footer, page-header and page-index decode helpers
- No RPC, no runtime IDL, no dependencies
Checked against Apache Thrift itself — 13 generated wire vectors, byte-identical
A Mojo binding to libzstd — one-shot and streaming, both directions — through a small C shim loaded at runtime, so consumers need no link flags.
- One-shot and streaming compress and decompress
- Frame introspection: is_zstd_frame, frame_content_size
- The shim is dlopen'd once, not per call
- 10–14 GB/s decompress
Checked against Python zstandard, against independently produced frames baked in as constants
A Mojo binding to liblz4 covering the block format, the frame format and the legacy Hadoop framing that older Parquet files still use.
- LZ4_RAW blocks for Parquet pages
- LZ4F frames for Iceberg Puffin blobs
- Hadoop framing for legacy Parquet LZ4
- 8–19 GB/s
Checked against CPython's lz4 package, on known vectors and round trips
A Mojo binding to libbrotli, the last of the seven Parquet page codecs. Bound rather than written: RFC 7932 needs two prefix-code forms, context maps, block-type switching, a distance cache and a 122 KB static dictionary with 121 word transforms that are part of the format itself.
- One-shot compress and decompress, quality 0–11
- A Brotli stream records no uncompressed size, so sized and unsized decoding are separate calls
- The shim is dlopen'd once, not per call
- 2.5 GB/s decompress
Checked against CPython's brotli package, on streams it produced and this one had never seen
Snappy in pure Mojo — the raw block format and the CRC-32C-checksummed framing format. No FFI, no C dependency.
- Raw block format and sNaPpY framing
- CRC-32C verified per chunk
- Pure Mojo — nothing to build, nothing to link
- Up to 20 GB/s incompressible, ~3 GB/s compressible
Checked against python-snappy, byte-exact
The three hashes Iceberg and Parquet actually need — CRC-32, MurmurHash3 x86-32 and XXH64 — in pure Mojo, with no dependencies and no FFI.
- CRC-32 for page CRCs and deletion-vector checksums
- MurmurHash3 for the Iceberg bucket[N] transform
- XXH64 for Parquet bloom filters
- 1.2–1.5 GB/s, identical results on every platform
Checked against zlib, mmh3 and xxhash, plus the Iceberg spec's Appendix B vectors
Durable execution in Mojo, via Restate. A Rust shim embeds the official Restate SDK — Rust owns the HTTP/2 endpoint, the event loop and the journal — while your handlers are Mojo, driven by a synchronous loop where every durable operation crosses one C-ABI call.
- State, sleep, run and awakeables from a plain next() loop
- app.serve(num_workers) runs that loop on N threads via threads-mojo's WorkerPool
- Self-calls need two or more workers: one worker has no second thread to run the callee
- Payloads are raw bytes — parse and serialize in your handler
Checked against Two end-to-end suites against a real restate-server booted per run, on macOS and Linux
Minimal OS threads for Mojo: spawn and join pthreads, share state through atomics and a mutex, and fan a loop out over cores with parallel_for. A stopgap, distilled from flare, until the language ships its own.
- parallel_for over cores — Mojo currently ships no other way to use a second one
- Atomics that bridge the stable/nightly std.atomic split
- Mutex, spawn, join and thread pinning
- Spawn and join in 14 µs; parallel_for scales ~4×
- Typed parallel_for and TypedPool: shared state held alive by origin, the void* erasure inside the library
Checked against Contended-count and memory-visibility proofs designed to give a wrong number, not a flake