is this stuff not pretty easy to do with python?
``` python -c "import base64; print(base64.b64encode('$INPUT_STRING'.encode('utf-8')).decode('utf-8'))" ```
Show HN: ut – Rust based CLI utilities for devs and IT
11–20 of 66 posts
Re: Show HN: ut – Rust based CLI utilities for devs and IT
#12is this stuff not pretty easy to do with python? ``` python -c "import base64; print(base64.b64encode('$INPUT_STRING'.encode('utf-8')).decode('utf-8'))" ```
I love typing python commands that are 10x longer than a shorthand.
Yes it's easy to set up an alias or shell command or whatever, but that's besides the point :p
Re: Show HN: ut – Rust based CLI utilities for devs and IT
#13Slightly 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…
cargo-dist will get you the npm one for free. They've got pypi support planned as well but don't have it yet, though they can also generate standard curl | sh installers and all too.
This looks cool, thanks!
Re: Show HN: ut – Rust based CLI utilities for devs and IT
#14is this stuff not pretty easy to do with python? ``` python -c "import base64; print(base64.b64encode('$INPUT_STRING'.encode('utf-8')).decode('utf-8'))" ```
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 it.
Re: Show HN: ut – Rust based CLI utilities for devs and IT
#15Why 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.
Also, lots of the ut functions already exist as decades old unix tools.
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.
Re: Show HN: ut – Rust based CLI utilities for devs and IT
#16Slightly 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…
Interesting perspective. I mean the issue exists with any ecosystem. See nix who has to wrap down to the lib level everything under the sun to make their package system usable for all kinds of use cases. But they need to do this because of the deterministic nature of the system. Brew on the other hand discouraged packaging tools that are available from other package managers. Don’t know if this is still the case. I feel a bit uncertain about this. It would mean that a tool should not only strive to be included in all major repositories of Linux distributions along with winget, brew and Mac ports etc (which is a tough ask). Now they should also publish to npm, pypy, ruby gems etc as well? I feel something is taking a wrong turn here.
Re: Show HN: ut – Rust based CLI utilities for devs and IT
#17is this stuff not pretty easy to do with python? ``` python -c "import base64; print(base64.b64encode('$INPUT_STRING'.encode('utf-8')).decode('utf-8'))" ```
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
Re: Show HN: ut – Rust based CLI utilities for devs and IT
#18is this stuff not pretty easy to do with python? ``` python -c "import base64; print(base64.b64encode('$INPUT_STRING'.encode('utf-8')).decode('utf-8'))" ```
You can send a heredoc into as in a single line of shell, too.
Re: Show HN: ut – Rust based CLI utilities for devs and IT
#19Earlier quoted context omitted.
Also, lots of the ut functions already exist as decades old unix tools.
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.
Re: Show HN: ut – Rust based CLI utilities for devs and IT
#20Why 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.