getrandom VS cargo-xtask

The crypto source in Go is great, no complaints there. Lints like gosec even recommend using it when generating crypto entropy. Go did a good job here, and I expect Rust will do the same sometime after getrandom reaches 1.0 so the API questions are settled, plus whatever makes sense for the future-proofing the standard library needs.

I would wait for the getrandom crate to reach 1.0, which will answer many of the questions around what an API like this can look like, and then maybe the standard library discussion will be on firmer footing because at least we'll know what API we want to immortalize. Rushing that now just to save people importing a small crate does not seem to be the way to go.

I'd caution against using /dev/random directly, and instead recommend using getrandom. It's effectively the same thing on Haiku and Redox, but is cross-platform and will upgrade to better sources on various platforms as available (such as using the getrandom() call on Linux and Android, or getentropy() on macOs, if avaialable).

getrandom

It's a default, but overwritable behavior, see the #[path] attribute. You still have to create N files for each supported platform, but at the top level you will see only one module. On of the crates which uses this approach in practice is getrandom.

IIUC the main problem which prevents from moving HashMap & co to alloc is lack of API to get system entropy which is required for DOS protection. Ideally we would have a #[global_allocator]-like functionality for retrieving system entropy. Relevant issue: https://github.com/rust-random/getrandom/issues/21

💡 Inspired by matklad/cargo-xtask and based on 🏃‍♂️ Write your Rust project scripts in task.rs from the Rust ecosystem.

Using a cargo-xtask task to generate them as a manual step (inlyne currently does this)

As someone else said just is good for that job, or you could implement an xtask helper for these things and setup a suitable development environment with that: https://github.com/matklad/cargo-xtask/

Well tools like cornucopia, prisma-rust-client, protoc-gen-tonic, they don't generate in build.rs, but instead provide either a cli to be called ahead of time, or provide a library that can be called by your own binary (which should generally follow the xtask pattern)

If I understand, this is a tool for when working on the project itself? Akin to a helper script? You could go the cargo install route as already pointed out but there is also the xtask convention.

For simple cli apps for internal use, such as cargo-xtasks, I prefer pico_args due to its fast compile times.

For developer-oriented stuff, there's tools like xshell and cargo-xtask. For operator tasks that need to run in a deployed environment, it's not usually a big lift to add CLI subcommands to your binary. It's certainly more boilerplate and inertia than doing stuff in a live REPL, though, and sometimes difficult to recommend for truly one-off situations.