4 ms·

So this is overkill for many other people, but you can also write scripts in Rust. I’m authoring a Cloud Natuve Buildpack (CNB) and my team picked Rust even tho

So this is overkill for many other people, but you can also write scripts in Rust. I’m authoring a Cloud Natuve Buildpack (CNB) and my team picked Rust even though all prior proprietary-spec Buildpacks save one are written in Bash. Is it actually overkill though? Well, the classic buildpack I maintain is older than 13 years and maintenance is by far the most expensive part. Scripts get kind of ignored but deserve the time, testing, and ecosystem for extension that other “mainstream” languages enjoy. We get that from Rust along with a strong type system, ability to cross compile to different systems, deploy and run self contained binaries (the scripts). It’s not for everyone, but just putting it out there in a chance to find some like minded weirdos, maybe we can help each other. A lot of my (in progress) library work has been trying to improve the ecosystem around these kinds of workflows. Examples: https://crates.io/users/schneems https://crates.io/users/schneems I don’t think rust should replace all scripting (of course) but I really want to stress test just how good of an experience it could be.

HKH2 2y ago
I use rust-script + run_cmd (for external commands). Rust-script recompiles the script when it has been changed, otherwise it just runs it.
- schneems 2y ago
  Awesome! I've seen several command runner variations but haven't looked too closely at them. How do you like `run_cmd`? I've got a crate for running commands that helps with the run ergonomics as well as error formatting but still allows for relatively-"ideomatic" rust usage. I would love to hear your feedback https://docs.rs/fun_run/latest/fun_run/ https://docs.rs/fun_run/latest/fun_run/
  - HKH2 2y ago
    run_cmd uses macros so you can just type shell commands directly, but it does make empty strings disappear (""). I'd rather not split up arguments, but to each their own. Either way, it's great to do some shell things to speed up coding, and Rust things to speed up the program safely.
upon_drumhead 2y ago
Scripts generally refer to interpreted languages. They're useful to just adhoc do something with a low effort cost. Purpose built binaries are extremely useful and should replace a ton of script usage, however, scripts will always have their place.
- schneems 2y ago
  When people say “scripts” many time it’s right after “deploy” which is my target area. I’m not trying to take away from the bash conversation, I’m trying to find allies who care about writing the best possible “scripts” (and script adjacent programs) in one or more languages. One of the most recent things I worked on was a hybrid of bash and rust. So I still write a fair share of bash. > scripts will always have their place 100% agree, hence all the caveats. I resonated with the article in that it was talking about ways to make your code faster, better, etc. It’s my experience that few aim to write a suite of bash scripts that stay in production for a decade+. It just grows that way because it was the lowest cost, lowest effort thing to do. To your point. I think content like this is a really good first step, but what about a second step when it’s no longer enough or you realize this adhoc “temporary fix” utility is now the linchpin of your team? One idea is to rewrite in another language. If not the whole thing, a subsection. I tried Ruby scripting (Ruby dev since 2006) and while I feel it’s better than bash (to maintain) it still has some strong downsides like the need to bootstrap with an interpreter. Which eats into the upsides. Bash and Ruby struggle with sharing or extending functionality. Bash relies on system commands and Ruby relies on gems/libraries. And in a lot of these adhoc weird situations I find myself in I cannot install packages let alone bundle install libraries. Then you mix in interoperability of gnu versus bsd tools and throw some windows in the mix and it can get really unwieldy really fast. On the deploy front here’s the CNB Rust project https://github.com/heroku/libcnb.rs https://github.com/heroku/libcnb.rs And docs for people who might want to use (but not author) them https://github.com/heroku/buildpacks https://github.com/heroku/buildpacks.
rednafi 2y ago
This sounds like slop. Why would anyone want to script in Rust when bash and python exist?
- schneems 2y ago
  I replied to another comment with some details.

HKH2 2y ago

I use rust-script + run_cmd (for external commands). Rust-script recompiles the script when it has been changed, otherwise it just runs it.

schneems 2y ago
Awesome! I've seen several command runner variations but haven't looked too closely at them. How do you like `run_cmd`? I've got a crate for running commands that helps with the run ergonomics as well as error formatting but still allows for relatively-"ideomatic" rust usage. I would love to hear your feedback https://docs.rs/fun_run/latest/fun_run/ https://docs.rs/fun_run/latest/fun_run/
- HKH2 2y ago
  run_cmd uses macros so you can just type shell commands directly, but it does make empty strings disappear (""). I'd rather not split up arguments, but to each their own. Either way, it's great to do some shell things to speed up coding, and Rust things to speed up the program safely.

upon_drumhead 2y ago

Scripts generally refer to interpreted languages. They're useful to just adhoc do something with a low effort cost. Purpose built binaries are extremely useful and should replace a ton of script usage, however, scripts will always have their place.

schneems 2y ago
When people say “scripts” many time it’s right after “deploy” which is my target area. I’m not trying to take away from the bash conversation, I’m trying to find allies who care about writing the best possible “scripts” (and script adjacent programs) in one or more languages. One of the most recent things I worked on was a hybrid of bash and rust. So I still write a fair share of bash. > scripts will always have their place 100% agree, hence all the caveats. I resonated with the article in that it was talking about ways to make your code faster, better, etc. It’s my experience that few aim to write a suite of bash scripts that stay in production for a decade+. It just grows that way because it was the lowest cost, lowest effort thing to do. To your point. I think content like this is a really good first step, but what about a second step when it’s no longer enough or you realize this adhoc “temporary fix” utility is now the linchpin of your team? One idea is to rewrite in another language. If not the whole thing, a subsection. I tried Ruby scripting (Ruby dev since 2006) and while I feel it’s better than bash (to maintain) it still has some strong downsides like the need to bootstrap with an interpreter. Which eats into the upsides. Bash and Ruby struggle with sharing or extending functionality. Bash relies on system commands and Ruby relies on gems/libraries. And in a lot of these adhoc weird situations I find myself in I cannot install packages let alone bundle install libraries. Then you mix in interoperability of gnu versus bsd tools and throw some windows in the mix and it can get really unwieldy really fast. On the deploy front here’s the CNB Rust project https://github.com/heroku/libcnb.rs https://github.com/heroku/libcnb.rs And docs for people who might want to use (but not author) them https://github.com/heroku/buildpacks https://github.com/heroku/buildpacks.

rednafi 2y ago

This sounds like slop. Why would anyone want to script in Rust when bash and python exist?

schneems 2y ago
I replied to another comment with some details.