undefined | Better HN

0 pointssharperguy5y ago0 comments

It seems the new culture around re-writing these tools in rust starts with a few premises:

* Old tools are well established, not looking for major feature additions or changes

* Hard to add new features to old C-based system tools due to mature codebase and being written in C

* Using Rust to reach a low-bug/maintainable state more quickly than a re-write in C or C++

* Adding a bunch of quality of life features that make it worth switching

The big downside with these tools, of course, is that they are re-writes of tools that have been standard Linux/Unix system tools for a long time and can be generally expected to be present on any system for the purpose of shell scripts, services etc. Using any of these tools in a shell script requires the user to install it, along with the whole dependency graph that rust typically comes with (at least when building from source which is typically the case with rust).

0 comments

1 comments · 1 top-level

pdimitar5y ago

I agree with you about the ubiquity of the standard tools but this also has downside: bigger size of the deployment containers.

Nowadays the distroless movement and the general zeal towards minimizing the overhead of a Docker image have the positive side-effect of making us less reliant on the older tools. So we can opt for newer ones (although it's very hard to beat 120KB of a classic old tool to 4MB of a new Golang/Rust tool still).

As for rewriting in Rust, the main point for me is always the memory safety. When it comes to writing programs, there's a ton of very nice languages out there already.

j / k navigate · click thread line to collapse