derodero24

This matters more than it seems for native addons that spawn worker threads or Rayon thread pools based on available_parallelism(). If a Node/Bun process thinks it has 64 cores when the container only has 4, you end up with massive oversubscription and worse tail latencies than running single-threaded. Good to see runtimes catching up to what Go has done for a while.

The single 8MB binary angle is underrated. For dev tools that people set up once and forget, removing the "install these 3 deps first" step makes a real difference in adoption. Also appreciate the honesty about using AI for the dashboard — the wire protocol being hand-rolled is where the actual learning happens anyway.

CJK tokenization is one of those things that looks simple until you actually try it. Japanese alone needs morphological analysis (MeCab etc.) because there are no word boundaries — n-gram fallback works but produces noisy results for short queries. Curious whether pg_textsearch could accept a pluggable tokenizer callback or if it assumes whitespace splitting everywhere.

Oh nice, didn't know winloop got merged in. That's good news — the Windows gap was the main thing keeping me on tokio's runtime directly for cross-platform stuff.

The assert-based optimization surprised me the first time I saw it in the wild. I had a hot path where I added an assert to document a precondition, and the generated code got measurably faster — the optimizer eliminated a downstream branch family it couldn't have known was dead otherwise.

The division UB case is thornier. In Rust you get explicit checked_div/wrapping_div, which makes the programmer's intent visible at the call site. The C approach of "trust that this is never zero" is the same mechanism but with none of the documentation.

Most of my side projects have 0-1 stars and I use them daily. Stars measure sharing appetite, not usefulness.

The more interesting question to me isn't "are AI-assisted repos less starred" but "are people building more stuff that's useful only to themselves." That feels like a good outcome — software that was previously only economically viable to write at scale is now worth writing for an audience of one.

The prefiltering gap has been a real pain point. With standard HNSW and strict WHERE clauses you're basically doing full candidate scans before applying the filter — you get the latency of ANN but none of the selectivity benefit.

Curious about filter selectivity though: does ACORN-1 still help when the filter eliminates, say, 95% of the index? I've seen cases where tight category filters completely undermine graph traversal because the graph structure assumed a uniform distribution over the subspace.

The composable/tree-shakeable direction is the right call. I've been on the consuming end of this — when you only need basic playback, pulling in 300kb of DRM, analytics, and ABR code is painful.

The loose-coupling architecture is harder to get right though. Did you consider lazy-loading the heavier subsystems (DRM, ads), or is the assumption that if you need those you're already bundling anyway?

coherence rules are one of those things that seem annoying until you maintain a library others depend on. orphan rules saved me from some nasty diamond dependency situations. the frustration is real when you just want to impl Display for some foreign type though — end up with a newtype wrapper every time and hate it.

different tool for a different job — Tauri gives you a desktop app shell, napi-rs gives you a Node.js native addon you ship on npm. if the goal is an npm package that works in Node and browsers from one Rust codebase, Tauri doesn't really fit.

ah it's not video-related — it's a text processing library so probably not what you're looking for. but if you want to do the same dual-target thing (native + wasm from one Rust codebase), the napi-rs docs cover it pretty well: https://napi.rs

Biggest lesson from string matching work: layout beats instructions every time. Batch your comparisons into a contiguous buffer so the prefetcher can actually help, and you'll outperform hand-rolled SIMD on random-access data. Compilers handle the arithmetic tricks fine now — they can't fix your cache misses though.

The p99 improvement over raw throughput matches what I've seen with napi-rs too — Rust's predictable memory management helps with tail latencies even when average perf is similar to C implementations. Windows support gap for uvloop is a real pain point in production, so that alone could justify the switch for some teams.

As someone shipping native Node addons, registry telemetry (OS, arch, platform) is one of the few ways I know which build targets to actually prioritize. Without it I'd be guessing whether anyone's even using linux-arm64-musl. I get the instinct to strip it, but for package maintainers it's genuinely useful data.

I do the same thing — Rust core compiled to both native (napi-rs) and WASM from a single codebase, different domain though. The tooling has gotten really solid for this. Curious how the perf splits between WASM compute and WebGPU for the actual video processing — in my experience the WASM overhead is small for pure computation but I/O patterns change things a lot.

I went through a similar journey trying worker threads for CPU-bound work in Node. The serialization cost of passing data between threads ate most of my gains, especially with larger inputs. Ended up going the napi-rs route instead — Rust addon running in the main thread with near-zero FFI overhead. Different tradeoff since you lose the parallelism, but for my workload the raw speed was already enough.

The polyfill treadmill is the one that gets me. I work on native Node addons so the JS layer is basically just a loader and types — no polyfills, no transpilation targets. Really puts into perspective how much of a typical npm package is compatibility layers for environments nobody actually runs anymore. josephg's right that just tracking Node's EOL schedule would kill a huge chunk of this overnight.

Thanks, hadn't heard of ctop. Been doing docker ps | grep like a caveman.

huh, /model opusplan is new to me. Is that a routing mode where it picks models by task type? Will try it.

Didn't know about the AGENTS.md routing — that's exactly what I wanted. Gonna try assigning cheaper models to things like test gen and lint fixes while keeping the main agent on something stronger.

Being able to assign different models to subagents is the feature I've been wanting. I use Claude Code daily and burning the same expensive model on simple file lookups hurts. Any way to set default model routing rules, or is it manual per task?

Can never remember the right lsof incantation for this and end up googling it every time. The Docker container detection is a nice touch — half the time whatever's squatting on port 3000 is some container I forgot to stop two days ago.

Good to know, thanks. Is the fuzzy matching using an existing engine under the hood (Bleve, Tantivy, etc.) or something custom? Wondering how it handles CJK tokenization for multilingual search.

Single-binary deployment is a huge win for adoption. Curious about the fuzzy text matching side — does the full-text search support approximate/typo-tolerant queries out of the box, or is that something you'd layer on top with the vector search path?

Yeah exactly. Go's ~10MB binaries with dead-simple cross-compilation is tough to compete with. I think Bun makes more sense for internal tools where you control the install and care more about the plugin ecosystem than distribution size.

The plugin system and compile-time validation are nice touches. My main concern would be the standalone binary size — 58-109MB is a lot for a CLI tool. Most Go CLIs land around 10-20MB and even that gets complaints. Is there a way to strip unused features, or is this mostly the Bun runtime being bundled?

The infinite canvas approach makes a lot of sense for terminals — I always end up with a pile of numbered tmux windows I can't keep track of. Having spatial layout would actually let muscle memory do the work.

One thing I'm curious about: how would this work with ssh sessions? Being able to spatially arrange and visually group remote sessions on a canvas could be really useful for managing multiple servers.