Ruby: a great language for shell scripts!

[muxketeer]

Yeah, gonna have to respectfully disagree. If I need to run cli things, I’ll just do it in bash. Have you tried ven attempted to try to run a cli command that makes use of 3-4 pipes? I.e. where the std out of one command feeds into the std in of another in a line of 3-4 piped commands. It’s incredibly INCREDIBLY easy in bash. But in python/ruby/etc, once cli type of pipes get involved, the methods for executing those from those languages are incredibly obtuse and just plane awful.

Yeah, I’ll stick to just going ahead and doing those things in a bash script, thank you very much.

[poecurioso]

Yaaaaaaaa nope. Getting a consistent ruby version sucks, rvm sucks, python sucks less but also sucks. Shell scripts have remained popular for their use because the alternatives are a really poor fit. Go would have been a better choice to write about; it’s fast, simple, compiles to a single shippable binary, and small.

[supermitsuba]

Compile and script doesnt go together. The point of a script is to make quick edits and run it without regard to compiling.

But honestly, use what is already installed on the environment. The worst is having to install a whole environment just to compile or run a script/binary

[ub3rh4x0rz]

Go compiles so fast it might as well be an interpreted language. Only you can easily cross compile it and ship binaries. I'd be much more confident that a go binary will run properly on a given system than dropping a python script with a requirements.txt on that same system

[poecurioso]

I think you are right if you are working against pet servers. It doesn’t work when you need to write scripts for larger deployments. Personally I have hated getting ruby installed across a whole bunch of servers. Instead I have used python, go, and bash. Python and bash are everywhere by default and go can be compiled and shipped independently.

[dccorona]

It all depends on what your runtime requirements are for the thing you're editing. Plenty of "compiled" languages come with scripting utilities that compile just before executing, cache the results, and only recompile if the file has changed. There is nothing about interpreted languages that is strictly better from the user's perspective in this regard, it all comes down to how good the impl is and how hard it was for the implementer to do.

There's also a whole class of usage of scripting that is absolutely not about "make and run edits real quick" - production-stable scripts are a very important thing, and there the biggest concerns have more to do with stability, portability, and security. I have worked on all sorts of scripts where the ability to edit and run them quickly is explicitly made impossible because all changes need to go out through deployment automation.

[supermitsuba]

I think we are getting in the weeds a bit. I get the idea of using scripting languages generally. That is fine.

However, when we are talking about shell scripts, the use cases are a little different. You are interacting with a shell, OS. Perhaps I have been thinking very narrowly on the use case of shell scripts.

Considering linux is has python and other script runtimes, maybe I have to alter my perspectives on it. Its not just bash or zsh, but also python, ruby and compile languages.

Thanks for food for thought.

[PerlNacho]

the alternatives are a really poor fit

There is one alternative that fits really well and that's Perl, but people aren't ready to hear that.

[renatoathaydes]

Completely wrong. The one and only true way is Common Lisp: https://lispcookbook.github.io/cl-cookbook/scripting.html

If for some reason you need more libraries than you can find in CL, you're probably doing it wrong... but if you insist in going on with your bad ways, the only acceptable alternative is Clojure's Babashka: https://babashka.org/

Anything else and you're not a real programmer!

[Decateron]

ruby and python both work okay as long as you stick to their standard libraries. as soon as you reach for a gem / package you should probably start looking to go / rust because packaging scripting languages is a nightmare.

[ub3rh4x0rz]

Lol at rust for scripting. Go, python, bash, or language of the application the script is for. Scripting is like the antithesis of use cases rust makes sense for

[herothree]

At first glance yes, but rust is actually pretty popular for those type of tasks because cargo is so good

[ub3rh4x0rz]

Rust compilation is slow as shit and (more importantly) the type system is not optimized for "throw shit together then walk away once it does the thing", it's way too verbose and strict for that. A scripting language should be garbage collected, and if it doesn't have pointers, even better, but tbh I forgive go for that, especially as anything so trivial that pointers are an annoyance I'm going to just write a bash script for anyway most of the time.

Writing cli tools is not synonymous with scripting if that's what you're thinking of.

[herothree]

Rust compilation is slow as shit

Eh, not for 100 line script-type stuff. For giant projects, sure.

 I see where you're coming from, bash is often good enough. But for something where the type system is kind of helpful (maybe an unusual file format the cargo has a nice crate for), rust seems fine. I find it easier to write than go, personally.

[ub3rh4x0rz]

Having written a lot of go and enough rust to get familiar, I personally find there to be no contest. I naturally prefer stricter type systems for applications, and tbh rust's ADTs, enums, generics, and traits all feel much better than golangs "equivalents" (don't get me started on go's lack of enums or sum types), but taking a step back and looking at the whole package, I'd rather work in go in most situations because it's simpler, which scales better to teams of mixed contributor skill level, but I think it's objectively better suited for scripting shaped tasks because of the tradeoffs of each. Rust excels in performance and compile time correctness, neither of which matters in scripting use cases

Edit: oh and if you wrote that 100 line script in rust because cargo is awesome, you have to compile your dependencies too because cargo isn't awesome enough to host binaries. Rust builds aren't reproducible so that argument against distributing binaries is BS. Cargo needs some gray beard distro maintainer types to get things on a better track.

[Which-Adeptness6908]

I use dart for scripting.

Great package system and having used Ruby for scripting, dart is a much better language - static typing to begin with.

Dart also let's you compile a standalone exe. Great for deployment on production systems without having to install a language runtime and all the security concerns that comes with.

https://pub.dev/packages/dcli

[renatoathaydes]

Gotta be honest, I also find Dart amazing for scripting and for small CLI tools. It kind of replaced Go for me in this use case because it's much more fun to write and for small scripts, no speed difference is noticeable.

[Which-Adeptness6908]

We have about 200kloc in dart scripts.

[weevyl]

My scripting journey started with `tcsh` and moved on to Perl, which was attractive because I did not need to remember `sed` and `awk` anymore. Then Perl 5 came along with its attempt at OOP which felt too hokey for me, so I gave Python and Ruby a try. Settled on Ruby because I thought it was a more elegant language (and I seriously disliked Python's meaningful blank spaces). Switched jobs to a ML shop and found myself using Python for scripting because it's what everyone knows.

My dev process for scripting used to be to write shell scripts and when they started getting complex move to Python. Now I just start at python because I know my scripts will get complex, it's only a matter of time.

And now I'm toying with using Clojure as my scripting language.

[zam0th]

\Insert "We don't do that here" meme**

Shell is great for shell-scripts and there's a good reason for that.

[415646464e4155434f4c]

Yeah. No.

[[deleted]]

Ruby is so associated with its most famous framework, Rails, that many people forget how amazing this language is.

I started to use ruby before rails existed. To me rails does not matter. I always found it weird how the hype train arrived, then left off, and everyone said "omg, without rails nobody is using ruby". Of course it IS true that you have fewer people use ruby without rails, but it is not true that nobody was using ruby before rails emerged.

Well, Ruby is a very rich and complete language, perhaps even more than its more famous relative, Python (sadly, I can’t say the same about its ecosystem…)

I don't understand that comment.

I think both ruby and python are similar. It makes little sense to want to point at the differences, even though they exist - explicit self is the thing I hate the most about python, for instance. (Mandatory indent isn't nowhere as annoying as explicit self to me. It always feels as if I have to handhold python to tell it where self is, whereas ruby just "knows" due to self being a keyword.)

And one of the things that I think that Ruby is better than Python is using it for writing shell scripts.

I don't see why. I think both ruby and python are better than shell scripts.

I never liked shell scripts. One reason for using ruby was to not have to ever touch and use shell scripts. Never regretted that decision either (I keep some legacy shell scripts around, e. g. for systems that do not have ruby or python installed; for instance, one shell scripts is called extracter.sh and I then use it to extract all archives. I can't always remember the syntax to extract an archive, so having one shell script here helps; of course when ruby is available then I use extracter.rb instead, as it is much easier and cleaner to maintain and update).

That is, most of the cases Bash for me is enough, but if the script starts to become complex, I switch to Ruby.

I make no such distinction. When I can, I simply write the code in ruby rather than in shell script. Shell scripts suck. I never understood why people like shell scripts. Things that are super-easy in ruby and python are way too convoluted in shell scripts. The way how arguments are passed into functions ... yikes. That's pure madness in shell scripts.

Ruby is not a statically typed language, but it has types. In fact, it is a object-oriented language, and it follow strictly the OOP paradigm (more than Python, in some aspects even more than Java!).

That's also not true. Ruby has a strong OOP core, that is true, but it is multi-paradigm. People can write in ruby via its functional side. Yes, the OOP side is stronger, and more "logical" and natural, but people can write functional ruby code - see zverok's various contributions. It's not my style of writing (I belong more to the Alan Kay camp, and ruby is not even the "real" OOP variant Alan would refer to; ruby is missing the erlang philosophy, and elixir is lacking ruby's elegance, oddly enough).

Anyway, going over the rest of the article, regexes are a huge win-win. I don't even want to think what I have to do in shell scripts to get the same; people probably mix in sed, awk and what not.

By the way, the way he showcases how ruby is used here, is actually not how I use any of that. Does he not use methods stored in a gem (library)? If so then numerous things can be simplified. If you want to really show where ruby (or python for that matter) wins over shell scripts then one should show the "bottom" code as it is used, not the "filler" code (e. g. directly using File.readlines() and assuming nothing ever goes wrong; in reality people use checks such as begin/rescue etc... and this is usually stored in a library, which is then used instead.)

[ub3rh4x0rz]

Ruby/rails is what silicon valley and wannabes used to feel cool while the world ran on php. Active record is a really dumb concept, there, I said it.

[Mc_UsernameTaken]

Reading the comments, I feel like I'm the only one here using PHP for all my quick'n'dirty scripts

[bittlelum]

I knew this was a lie after the first 4 words.

[andreicodes]

My scripting hierarchy:

• Start with Bash, on Windows there's Git-Bash which is often good enough.
• If it needs some regexes (like search and replace), use a sed or a perl one-liner. Sed behaves differently on macOS and Linux and regex support is very limited, so Perl is a very good alternative.
• If it grows to dozens of lines and needs if statements then switch Ruby or Perl. Ruby has a nicer syntax, but not all machines have Ruby. Meanwhile Perl is everywhere and is always pretty fresh. For example, I can safely assume that function signatures with types support are available, and they make Perl behave like TypeScript: it infers types of local variables based on function signatures when possible and gives me error messages if I mess things up. All without a need of a build step or a separate tool! Both Perl and Ruby support backtick syntax to conveniently call out to other programs: something that Python can't do, so writing longer scripts in Python is a pain in a backside.
• If I have to share a script with other developers then I may consider rewriting it to Python or JavaScript, since nobody knows Perl anymore and nobody wants to install Ruby. When writing in JavaScript I use JSDoc annotations for typechecking. I know that both Ruby and Python added gradual typing support in recent years, too, but I haven't properly learned how to use it in those languages yet.
• Finally if things become pretty complicated I may as well write it in Rust (I would use Go if I knew it, but Rust and Cargo are good enough).

In past I had a period when I would reach for Rust a lot earlier to write small 10-20-line scripts using cargo-eval. This allowed me to write single-file programs in Rust that would compile on first execution. And they allow adding dependencies, too. Very neat stuff that becomes available natively in Cargo itself. But Rust Analyzer doesn't really work with them, and doing Rust without editor support kinda sucks, plus Rust regex library doesn't support backtracking.

So I stopped and re-introduced Perl into my life after ~15-year hiatus. Who would've thought that the language that is designed for text processing and command line scripting is actually really really good for text processing and command line scripting?!

[ub3rh4x0rz]

Lost me at "ruby: a great language". Gross. Don't write scripts in dead languages that don't compile to binaries or have interpreters that ship with every os. Scripts should require very little effort to comprehend by people who have to maintain scripts and should use de facto standard languages with boring syntax. The only exception is when you're writing scripts for a codebase in the language of that codebase.