Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: ut – Rust based CLI utilities for devs and IT

github.com

Post reply on HN
Print view View original

21–30 of 66 posts

Re: Show HN: ut – Rust based CLI utilities for devs and IT

#21

Post by thayne »

guessmyname wrote: post #3

Why is everything in the same binary? Why not multiple binaries, one for each function? That way people can install only the ones they need, a-la Unix tools: do only one thing and do it well. I also have the exact same tools but written in Go. Rust would be a nice upgrade (lower footprint) but to keep them all in the same binary is a bit silly.

Probably for the same reasons that uutils/coreutils uses a single binary. Specifically:

- it reduces the total install size, since common code, including the standard library, is only included once, rather than copied for each executable

- it makes installation easier on some platforms, since you just have to install a single executable, instead of a bunch of executables

Re: Show HN: ut – Rust based CLI utilities for devs and IT

#22

Post by rsyring »

simonw wrote: post #4

Slightly odd suggestion: package it up as both a Python and an NPM module - both just thin wrappers around the combined binary - and then people within those ecosystems will be able to run: uvx ut md5 ... Or: npx ut md5 ... To execute it without having to figure out cargo or how to add a Rust binary to their path. I've seen a few tools do things like this recently, it's a pretty interesting pattern. I believe there's…

If you know you will use it often, uv has `uv tool install ...`. So, after the first `uv tool install ut` you can just run `ut md5 ...` or whatever. Don't need to keep using uvx.

uv also has a couple commands I throw in a systemd unit[1] to keep these tools updated:

  uv self update
  uv tool upgrade --all
1: https://github.com/level12/coppy/blob/main/systemd/mise-uv-u...

Re: Show HN: ut – Rust based CLI utilities for devs and IT

#23

Post by geraldcombs »

rauli_ wrote: post #19
geraldcombs wrote: post #15

Earlier quoted context omitted.

Those tools either don't ship with, or exist in wildly different forms on Windows. It's particularly bad for curl, which might be the real curl.se curl or Microsoft's confusingly-named Powershell alias. I could definitely see using this in a cross-platform build or installation environment.

Windows and *nix systems are often used for very different things so I don't understand why there would be need for some kind of universal superbinary. And thanks to WSL you can already get GNU coretools running in Windows anyways.

I lead a large-ish open source software project. We have developers that need to build on Linux, macOS, and Windows. It's useful to be able to get everyone bootstrapped with as few steps as possible and with as few dependencies as possible. For our uses CMake works well as a universal superbinary, but I'm always on the lookout for tools that can reduce developer friction.

Re: Show HN: ut – Rust based CLI utilities for devs and IT

#24

Post by collinfunk »

westurner wrote: post #17
ksdme9 wrote: post #14

Earlier quoted context omitted.

You don't even have to go that far, `base64` is a coreutil ( https://github.com/coreutils/coreutils/blob/ebfd80083b4fe4ae... ). The point of ut is not to replace or invent new tooling. It is meant to be a set of tools that are simple, self exploratory and work out of the box with sane defaults. So, essentially, something that you don't have to remember syntax for or go through help/man pages everytime you want to use…

uutils/coreutils has a `base64` in Rust which just gained better performance due to the base64-simd crate for SIMD: https://github.com/uutils/coreutils/pull/8578

Note that uutils does not work if the file does not fit into memory.

With GNU coreutils:

   $ base64 /dev/zero | head -c 1 | wc -c
   1
With uutils doing the same would exhaust your systems memory until either it freezes or oomd kills the process.

Re: Show HN: ut – Rust based CLI utilities for devs and IT

#25

Post by zvr »

dgacmu wrote: post #20
guessmyname wrote: post #3

Why is everything in the same binary? Why not multiple binaries, one for each function? That way people can install only the ones they need, a-la Unix tools: do only one thing and do it well. I also have the exact same tools but written in Go. Rust would be a nice upgrade (lower footprint) but to keep them all in the same binary is a bit silly.

Amusingly, if you look historically, it's also a traditional approach to reduce total binary size - a bunch of small utilities were all Sim links to a single binary, which conditioned on argv[0] to figure out what to do.

In The Old Days, it was hard links, no symlinks.

Re: Show HN: ut – Rust based CLI utilities for devs and IT

#29

Post by 01HNNWZ0MV43FF »

nvader wrote: post #2

Very neat. Although philosophically I prefer the unix approach of "do one thing and do it well", I really admire this tool. I think it might be the fact that the one thing this does well is curating a set of functions for a particular profile of developer. My story is someone doing web focused full stack development? It might be worth doing a survey of your users to see what they use ut for and what areas you should…

I think for packaging it's okay to "have" lots of things that individually "do" one thing.

The important part is that the user controls the entry points. It's more Unixy to allow someone to decode audio from one pipe to another than to only allow them to play a file to a speaker.

Consider that Debian "does" lots of things because it has a kernel, hardware abstractions, a userland, a package manager, and often a GUI and web browser. But it also "does" none of those because it's just a convenient and useful wrapper to publish all the other tools, which you can still call upon individually

Re: Show HN: ut – Rust based CLI utilities for devs and IT

#30

Post by xpe »

I can understand why people would find `ut` convenient. That said, I would caution against trying to include too much functionality. What is too much? I don't have a clear idea on this yet.

But I would probably argue that including HTTP functionality is going too far. Why? Because there are already amazing tools dedicated to this already. On the client side, see `xh` [1]. On the server side, see `miniserve` [2]. Both have approximately 7K stars on GitHub.

It seems wiser to let specialized projects focus on a particular functional area; this is better for users and less work for maintainers.

[1]: https://github.com/ducaale/xh

[2]: https://github.com/svenstaro/miniserve

Post reply on HN