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.
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
And docs for people who might want to use (but not author) them https://github.com/heroku/buildpacks.