I disagree with "bloat" comments. First, the binary will only have stuff you use. Secondly, the fact that you are not writing from scratch code that someone else had more time to write and test - this is a huge plus. I'd use your implementation any day vs. something that someone could put together in C with no dependencies and remarkable pointer math equilibristics.

As long as the use of dependencies remains reasonable, the number of dependencies does not immediately mean that the code is "bloated".

I wonder, have you considered D? Seems almost ideal to me for this kind of small tooling, and it's unlikely to break because of dependency version changes caused by the thirty-seventh party.

Not really. The main reason for choosing Rust was to try it out, because it's the new cool thing. And I do find it really enjoyable. Rust is also trying very hard to keep dependency-related breakage to a minimum, and I think the Cargo ecosystem is doing a great job at that.

Fair enough; "I wanted to try out X" is always a valid reason. It's just that compared to C, things like Unicode support, argument parsing and JSON support are already part of D's standard library so no dependencies should be required for those.

> unlikely to break because of dependency version changes caused by the thirty-seventh party.

With rust you just check in your Cargo.lock file to your VCS and then the versions of your dependencies and their dependencies (etc) are pinned, so if it works now then it will always work. For dependencies on crates.io authors don’t even have the option to remove a version once it’s published.

Upgrading dependencies is an explicit operation, so you only do it when required and run your tests afterwards.

In practice I’ve had far fewer issues with dependency versions using rust than I’ve had using dynamic system libraries in the C/C++ ecosystem

Rust is also unlikely to break because of dependency version changes caused by the thirty-seventh party. Despite similarly large dependency trees, the Rust ecosystem takes backwards compatibility much more seriously than e.g. the JavaScript ecosystem.

Well, I should hope so. Nevertheless every dependency removed completely removes even the possibility of such breakage.

I mean sure, but it means you have to maintain that functionality yourself. Often DIY implementations are not as robust as the versions in battle tested libraries with lots of eyes. So you can easily end up with more problems overall.