11–20 of 368 posts
The greatest feature for this is inline deps, something very rare to have built-in (I've only found Deno to have a similar feature): https://bundler.io/guides/bundler_in_a_single_file_ruby_scri...
Language is just a tool, anything and everything works if you love it enough
I sometimes wonder why we don't see ruby used for shell stuff more often. It inherited most of the good stuff for shell scripting from Perl, and Perl took a lot of it's syntax from sh and sed and awk, so almost anything you can do in shell script you can do in ruby, but with an option of making it gradually less terse and more readable, while having sane variables and data handling from the start. Also ruby is great…
The greatest feature for this is inline deps, something very rare to have built-in (I've only found Deno to have a similar feature): https://bundler.io/guides/bundler_in_a_single_file_ruby_scri...
Since that document, Python PEP 723 was approved, see https://peps.python.org/pep-0723/ and https://packaging.python.org/en/latest/specifications/inline...
Similarly, Rust RFC 3502 was approved and an unstable implementation is available, see https://rust-lang.github.io/rfcs/3502-cargo-script.html
These are great points, if you already have Ruby in your stack. For me, when Bash ain't enough I upgrade to the Project language (PHP, Python, JS, etc). For compiled project I reach for LSB language (Perl, Python) before introducing a new dependency.
I sometimes wonder why we don't see ruby used for shell stuff more often. It inherited most of the good stuff for shell scripting from Perl, and Perl took a lot of it's syntax from sh and sed and awk, so almost anything you can do in shell script you can do in ruby, but with an option of making it gradually less terse and more readable, while having sane variables and data handling from the start. Also ruby is great…
I think golang is used because you can easily create a single static binary, which is incredibly easy to distribute. I often find non-trivial CLI tools written in Python cumbersome because of the dependency wrangling necessary.
These are great points, if you already have Ruby in your stack. For me, when Bash ain't enough I upgrade to the Project language (PHP, Python, JS, etc). For compiled project I reach for LSB language (Perl, Python) before introducing a new dependency.
Many distros come with Ruby standard, it's not very big and I think it has a lot to recommend it over Python or Perl when it comes to lightweight scripting for sysadmins and day to day automation. I wouldn't necessarily pull it into an open source project where they weren't already present, but I would definitely choose it for personal use well before Python or Perl
a) put a `binding.irb` (or `binding.pry`) in any rescue block you may have in your script - it'll allow you to jump in and see what went wrong in an interactive way. (You'll need a `require 'irb'` in your script too, ofc)
b) I always use `Pathname` instead of `File` - it's part of the standard library, is a drop in replacement for `File` (and `Dir`) and generally has a much more natural API.
c) Often backticks are all you need, but when you need something a little stronger (e.g. when handling filenames with spaces in them, or potentially hostile user input, etc), Ruby has a plethora of tools in its stdlib to handle any scenario. First step would be `system` which escapes inputs for you (but doesn't return stdout).
d) Threads in Ruby are super easy, but using `Parallel` (not part of the stdlib) can make it even easier! A contrived example: `Parallel.map(url_list) { |url| Benchmark.measure { system('wget', url) }.real }.sum` to download a bunch of files in parallel and get the total time.
MacOS has Ruby 2.6 installed by default which is perfectly serviceable, but it's EOL and there are plenty of features in 3+ that make the jump more than worthwhile.
Too many ways to do the same thing.
Not packaged by default on most Linux.
Monkey patching makes things even harder to debug.