Show HN: Plasmite – 재미있는 경량 IPC 시스템

Easy interprocess communication. What would it take to make IPC pleasant and predictable? - Reading and writing processes come and go... so message channels should outlast them - Machines crash... so channels should persist on disk - Disks are finite... so channels should be bounded in size - Message brokers bring complexity and ceremony... so for local IPC, don't require a broker - Observability matters... so messages must be inspectable - Schemas are great... but schemas should be optional - Latency matters... so IPC should be fast, zero-copy wherever possible So, there's Plasmite. Plasmite is a CLI and library suite (Rust, Python, Go, Node, C) for sending and receiving JSON messages through persistent, disk-backed channels called "pools", which are ring buffers. There's no daemon or broker for local IPC, no fancy config, and it's fast (~60k 1KB msgs/sec writes, ~3M msgs/sec reads on a laptop). Readers mmap the pool file and walk frames in place, and payloads use Lite3, a zero-copy JSON binary encoding. For IPC across machines, pls serve exposes local pools securely, runs an MCP server, and serves a minimal web UI too. | Alice | Bob (a local reader) | |---|---| Alice creates a channel (aka a pool)pls pool create channel Alice sends a message pls feed channel '{"from": "A", "msg": "hello world"}' | Bob starts watching pls follow channel Bob sees it on stdout { "data": {"from": "A", "msg": "hello world"}, ... } | | Alice | Bob | Carol (remote) | |---|---|---| Alice runs pool serverpls serve init pls serve Alice sends pls feed channel '{"from": "A", "msg": "hi all"}' | (Bob never quit his follow process, so he's still watching the same pool.) Bob sees it { "data": {"from": "A", "msg": "hi all"}, ... } | Carol watches remotelypls follow http://alice:9700/channel Carol sees it { "data": {"from": "A", "msg": "hi all"}, ... } | The APIs work the same way as the CLI. | Drawbacks | Plasmite | | |---|---|---| | Kafka, RabbitMQ, | Lots of machinery: partitions, groups, exchanges, bindings, oh my. | Covers the 80/20 cases: no config, no broker, no partitions, no topology. | | Redis / NATS | Server required even for local messaging. Messages live in server memory; if the server dies, messaging stops. | Pools persist on disk independent of any process. Server only if you need one. | Log files / tail -f | Messages are unstructured. Logs grow and must be rotated (which breaks tail -f ). Can't easily replay from a specific point. No remote access without setting up syslog. | Messages have structure and sequence numbers. Disk usage is bounded. Replay from any point. Remote access is idiomatic. | | Ad-hoc files (temp files, locks, polled dirs) | Readers have to poll for new files. Locking is manual; crashes leave a stale lock. Files accumulate. No ordering unless you bake it into filenames. | Readers stream in real time. Writers append concurrently without explicit locks, and messages are ordered. Ring buffer bounds disk usage. | | SQLite as a queue | Readers have to poll. Writers contend. Have to design & migrate schemas. SQLite explicitly discourages network access to the DB file. | Follow & replay without polling. No SQLITE_BUSY . No schema, no migrations, no cleanup, easy remote access. | | OS primitives (pipes, sockets, shm) | Named pipes mean if the reader dies, the writer blocks or gets SIGPIPE. With sockets you have to implement your own framing and reconnection. Shared memory has to be coordinated with semaphores; be careful not to crash while holding a lock. Machine-local only. | Many readers, many writers, crash-safe, persistent across reboots. | | ZeroMQ | Messages vanish when processes restart. The pattern matrix is expressive but hard to get right. Binary protocol means you can't inspect messages with standard tools. | Messages persist. One mental model fits most cases. Plain JSON you can pipe through jq . | Use cases — CI gates, live event streams, duplex chat, system log ring buffers, replay & debug: see the Cookbook. Plasmite is for single-host and host-adjacent messaging. If you need multi-host cluster replication, schema registries, or workflow orchestration, see When Plasmite Isn't the Right Fit. brew install sandover/tap/plasmite Installs the CLI (plasmite + pls ) and the full SDK (libplasmite , C header, pkg-config). Go bindings link against this SDK, so install Homebrew first if using Go. cargo install plasmite # CLI only cargo add plasmite # use as a library in Rust projects uv tool install plasmite # standalone CLI + Python bindings uv add plasmite # add to a uv-managed project PyPI ships pre-built native bindings on macOS and Windows x86_64. On Linux today, prefer Homebrew or a GitHub release tarball for the system SDK; see the distribution docs for the current matrix. npm i -g plasmite Package includes pre-built native bindings. go get github.com/sandover/plasmite/bindings/go/local Bindings only (no CLI). Links against libplasmite via cgo, so first get the SDK via Homebrew on macOS, or from a GitH