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

Using Rust for 'Scripting'

chriskrycho.com

Post reply on HN
Print view View original

1–10 of 126 posts

Re: Using Rust for 'Scripting'

#2

Post by bajsejohannes »

I found myself doing the same just a few days ago when my local server suddenly had a new ip address. I made a simple script to scan IP addresses in the range: https://gist.github.com/johshoff/bed463ce8a122123e60bbc84bd1...

There are probably faster ways, but none that I could think of a the time.

Re: Using Rust for 'Scripting'

#4

Post by fnovd »

>Writing it in Rust means I can compile it and hand it to him, and he can run it. And that’s it. As wonderful as they are, the fact that languages like Python, Perl, Ruby, JavaScript, etc. require having the runtime bundled up with them makes just shipping a tool a lot harder—especially on systems which aren’t a Unix derivative and don’t have them installed by default.

I'm wondering what part of the twelve step compilation process was found to be easier than simply installing Python on the target machine?

Does the friend have any ability to audit the compiled binary before he runs it? Can he make a small change when he wants to re-use part of the solution?

Re: Using Rust for 'Scripting'

#5

Post by pritambaral »

bajsejohannes wrote: post #2

I found myself doing the same just a few days ago when my local server suddenly had a new ip address. I made a simple script to scan IP addresses in the range: https://gist.github.com/johshoff/bed463ce8a122123e60bbc84bd1... There are probably faster ways, but none that I could think of a the time.

> There are probably faster ways, but none that I could think of a the time

For future reference, `nmap -p22 --open 192.168.1.*` does everything your rust script currently does.

Nmap is THE tool for the job of network scans. IMO, it should be in the toolbelt of every techie that deals with any sort of computer network.

Re: Using Rust for 'Scripting'

#6

Post by itsweller »

This reads less as “Python style scripting in Rust” and more as “I like Rust, also it’s cross-platform.”

Not that this is a bad thing, but it feels like a bit of a far cry from my hacked together workflow of throw code in iPython and write out when I’m happy. I don’t see anything here that makes Rust any more attractive than whatever your multiplatform language of choice is for this use case scenario.

That being said, the code is concise and readable, and the article was a short, pleasant read.

Re: Using Rust for 'Scripting'

#7

Post by kibwen »

I admit, as a longtime Rust user I don't often get around to using Rust for scripting, probably because Python is available on all my personal machines and I'm so accustomed to it. But after reading this article I'm immensely impressed at how far Rust has come in the past few years WRT suitability for scripting, I really need to take a look at the glob and clap crates.

Also, I'm very excited to hear that LLD is apparently usable for linking on Windows! It seems like we've been waiting for LLD since time immemorial. :)

Re: Using Rust for 'Scripting'

#10

Post by officialchicken »

fnovd wrote: post #4

>Writing it in Rust means I can compile it and hand it to him, and he can run it. And that’s it. As wonderful as they are, the fact that languages like Python, Perl, Ruby, JavaScript, etc. require having the runtime bundled up with them makes just shipping a tool a lot harder—especially on systems which aren’t a Unix derivative and don’t have them installed by default. I'm wondering what part of the twelve step compi…

I agree.

Instead the "friend" is taught the bad behavior of running untrusted (and I didn't see any tests, so untested and undocumented too) code in binary format on their machine.

The glob-rename is exactly the sort of problem a script is supposed to solve easily. I feel the author justified the use of Rust and cross-compilation simply to avoid usage of a Windows OS (or VM) for such a trivial task.

If the goal was to avoid installing additional run time/deps on the user's machine it seems that (#1) using powershell would have been the best option followed by (#2) a classic .cmd shell file as second best solution.

Post reply on HN