Hearing people still mention "monkey patching" always makes me chuckle... I haven't "monkey patched" anything in Ruby in > 5 years, and I don't see it in any of the popular libraries/gems anymore either.

Especially when the big difference is that Ruby had proper OO system that allowed patching, when necessary, to be done in much saner way...

whereas the origin of monkey patching seems to by Python with its totally broken magical method names and kitbashed object model.

Module#prepend was introduced in Ruby 2.0, in 2013, which was the solution to monkey patching.

Well, that and Module#refine.

You can pin a gem to a specific version, of course.

`gem "mygem"` installs the latest version. `gem "mygem", "~> 4.0.0"` installs >= 4.0.0 but < 4.1.0, which is what you probably want when using Semantic Versioning, which most gems adhere to, to get the latest patch version. `gem "mygem", "4.0.10"` installs exactly that version.

For 99% of use cases (especially when writing shell scripts) it doesn't matter, just pick the one you know better. Both are nicer than Bash though. :)

Can you give an example? I can't think of a single situation where whitespace matters in Ruby (unless of course you forget to put a space between two commands or something silly).

It's not really a problem in practice (and I love Ruby), but it's still wild to me that they made the parser do this:

    $ irb
    irb(main):001:0> def foo(x=70) = x
    => :foo
    irb(main):002:0> i = 2
    => 2
    irb(main):003:0> foo / 5/i
    => 7
    irb(main):004:0> foo /5/i
    => /5/i

if foo is a method then

`foo + bar` and `foo+bar` are `foo()+bar`, but `foo +bar` is `foo(+bar)`

ternary ? : also has some interesting whitespace dependent mixups with symbols, but I cannot remember what. I think that parser has many gotchas like that, but they are really really rare to bite you, because ruby's magic follows human intuition as much as possible.

What do you mean by "broken gems"?

Either dependency issues with other gems, or gems that break due to some sort of library in the OS. If you pin all of your versions, and use it in one place, that's less of an issue, but many scripts are designed to have some level of portability (even if it's to a new instance of the server)

In my experience, Bundler has improved a lot with regard to resolving dependency issues over the years. And OS libs are only really depended on by a few gems, no? 99% of them don't use FFI or call OS libs.

Moreover, how often do you really move a script to a completely different OS, where you don't know which OS libs are installed? And wouldn't those missing OS libs also be a problem when writing the script in Bash or any other language?

> Sadly, 9 out of 10 environments lack a Ruby interpreter out of the box.

Please name those 10 environments you are talking about. In my experience, a reasonably recent Ruby version is present almost everywhere.

> add 5 minutes to your docker build

Why on earth would it take 5 minutes to install anything? If you install Ruby through a package manager (it's present in pretty much all of them: https://www.ruby-lang.org/en/documentation/installation/#pac...) it takes only seconds.

Similar case for me, but I think the author says it well:

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

Even if ChatGPT lets you bang out more complex shell scripts easily, if you have to come back to it later on to fix an error or add a new feature, it's really hard to understand it (if you don't deal with such scripts on a daily basis). If you start with Ruby (or Python or similar) from the beginning, it's much easier to understand and extend later on.

Bundler inline works great for that: https://bundler.io/guides/bundler_in_a_single_file_ruby_scri...

> but it's temperamental and I have trouble getting it working.

> I was trying to set up editor support

Not sure what problems you had exactly, but saying that editor tooling is bad, simply because you can't get it to work, is not fair. I've been using the LSP from Shopify since it came out, it works great, is very stable and updates come in on a regular basis.

> ... the new LSP one from Shopify doesn't want to work for whatever reason.

Sorry, but calling it "a mess" simply because you can't get it to work is quite unfair. I've been using the LSP from Shopify since it came out, it works great, is very stable and updates come in on a regular basis.

Love the Shopify effort on the LSP, I even reported issues. But, no, it's not stable or easy to setup unless you use it on specific scenarios. Also I have very high cpu usage nas crashes every day.

I would say it's quite fair. It's not just me but several coworkers, other people in this thread, and reviews on the actual VSCode extension itself. I sank several hours trying to fix whatever issue it has with my system and continued to run into problems. I'll give it another shot when I'm back on Ruby projects.