What this prompt does
This prompt ports a Node.js script to a single-binary Rust CLI that preserves the original interface and behaviour. It frames the model as a senior Rust engineer porting tooling and returns working code, not pseudocode. It asks for six things: a clap CLI matching the original flags and output exactly, anyhow error handling with matching exit codes, tracing-based logging with a --verbose flag, tokio only if the I/O genuinely needs async, a Cargo.toml and release setup producing a single binary, and an honest benchmark comparing Node.js to Rust.
Four variables drive the port. [behaviour] is the behaviour to preserve, like exiting non-zero on any failed file. [io_profile] decides whether async is warranted — if it's not, the port stays synchronous and simple. [distribution] sets the build targets for the single binary. [script] is the Node.js source being converted. The guard against gold-plating is deliberate: stay synchronous unless the I/O demands async, and keep the benchmark honest — if Rust isn't meaningfully faster, that's a real result.
When to use it
- You have a Node.js script that runs constantly and want faster startup
- You want to ship a tool as a single binary with no runtime dependency
- You need the Rust version to match the original flags and output exactly
- You want exit codes that mirror the Node.js behaviour
- You want an honest benchmark to decide if the port is worth it
- You want to avoid over-engineering with async you don't need
Example output
You get a full Cargo.toml, src/main.rs, and benchmark notes. The CLI matches the original's flags, args, and output; errors use anyhow with exit codes mirroring the Node.js script's behaviour; logging runs through tracing with a --verbose flag; tokio appears only if the I/O profile genuinely needs it; the build setup produces a single binary for your distribution targets; and the benchmark compares Node.js versus Rust on representative input with the method stated.
Pro tips
- Keep it synchronous unless
[io_profile]truly demands async; gold-plating with tokio adds complexity for no gain on file-heavy, network-free work - Paste the complete Node.js source into
[script]; the more accurately it sees the original, the closer the behaviour match - Be precise about
[behaviour], especially exit-code semantics like exiting non-zero on any failed file, so the port matches under failure - Make the benchmark honest; if Rust isn't meaningfully faster for your workload, that's a real result, not a failure of the port
- Set
[distribution]to your real targets so the release build produces binaries for the platforms you actually deploy to - Compare the Rust output against the Node.js output on the same input to confirm the interface matches exactly
- State the benchmark method explicitly (input size, machine, warmup) so the Node.js versus Rust comparison is reproducible rather than a one-off anecdote
