Another reason I hate Ruby

I’m working in Rails again. I hate it. It kills me. It drains my soul.

But this time it’s an external dependency that’s got my panties in a wad.

This project uses travis for CI. Travis recently auto-updated its Ruby setup to use bundler 2. Bundler 2 doesn’t support older versions of Ruby, but travis still allows you to declare them as test targets.

Okay, fine. Fuck you, Ruby. But that’s all manageable without wasting too much time, right?

Except I do my testing in a docker container to avoid the horrific, painful dependency bullshit Ruby forces on my system. Yes, even with rvm and some of its better plugins. rvm adds its own pain points to any process. Plus, there are more dependencies for this project than just Ruby’s, so rvm only helps so much. When you have to have just the right version of Image Magick and Libre Office… well.

So there I am, with my well-crafted Dockerfile that uses the base Ruby image, and I can’t for the life of me get this fucking Bundler 2 shit to work. Why not? Because Ruby fucking sucks.

The base Ruby image uses bundler 1, and puts it into a location you can’t really remove without basically manually deleting its files. As in, rm -rf /usr/local/lib/ruby/gems/2.5.0/blah/etc. And probably a dozen tertiary locations I’m not about to try and figure out. And, yes, jackasses of the world, I did try a proper gem uninstall, even using the -i flag.

Even after installing a later version in the location defined by the image as the “right” place, bundler 1 is still used. Even directly executing the bundler 2 binary, which lives in /usr/local/bundler, and double-checking that I’m executing the correct one, it won’t work. Even though Bundler is supposed to actually read the Gemfile.lock to see which version of itself to execute, it fucking will not work. It just runs Bundler 1, period.

So I start digging into the binary’s code. Because this is Ruby – these aren’t compiled standalone binaries. And what do you suppose I find? Some crazy-ass bullshittery that is apparently the cool way to do gems. This binary is actually asking the Ruby gem system to decide which version of itself to use. So no matter which version’s binary you call, you’re getting whatever Gem.activate_bin_path returns.

I couldn’t figure out a way to force the issue no matter what I tried. So I rebuilt my Dockerfile using debian as a base. I installed Ruby manually. I installed bundler manually. And you know what? It all works fine.

How the fuck did Ruby get so absurd? Why are there so many goddamn points of failure now? I have an easier time wrangling node dependencies. And I fucking hate node.

And yet somehow, somebody has convinced the library world (as in libraries that have books and put up exhibits online and stuff) that Ruby on Rails is a good idea. All I see is money being thrown away while we debug absurd issues that simply don’t happen in Python, Go, or even node.

At least it’s not PHP….

6 Replies to “Another reason I hate Ruby”

    1. Sad, but true! Not sure how Ruby devs got so bad at programming in general, but it does seem like a major skill issue. Poor bastards don’t even realize how bad they are.

  1. You can compile ruby from source and just use gem, avoiding bundler completely. It’s not difficult – I have been doing so since about 20 years. You seem to have fallen into many pitfalls, including rails. There are people who use ruby without rails.

    Poor bastards don’t even realize how bad they are.

    You make that based on which assumption? You have probably tested only a small portion of the whole ecosystem. I guess your main fault was that you equated ruby with rails – that was already the path to defeat. You can even use web-related stuff without rails. I went from PHP to ruby; all my web-needs I solved via my own custom framework in ruby. (I’d love to do a promo here, but the rubygems maintainers now disallow people to remove their own gems past 100.000 downloads; as I did not accept this hijacking attempt, I am no longer hosting gems on rubygems, only on github, but my github profile is too incomplete – I can only work on it in my limited spare time.)

    1. Well-thought out comment, so I won’t just be a jackass and call you names like I normally would.

      First issue is that on the job, you rarely get to work with any language/platform/whatever the way you want. The platform in this case is one we have no control over. But talking with other devs, they don’t think Rails is the problem anyway. They love it. So even if I had control, I’d still lose. Why? Because Ruby devs are fucking incapable of thinking outside their little world view.

      Sadly, your only real mistake is thinking that I’m going to spend the time to differentiate the 10% of Ruby devs who don’t suck from the other 90% who do. When you’re in an organization where you aren’t a lone-wolf coder, you are beholden to the 90%, because doing things even slightly out of the ordinary becomes expensive for a team. Harder to find documentation, harder to on-board new devs who are used to the standard approach, harder to convince the Ruby lifers that there are other ways to get the job done, etc. Hell, at a previous job I couldn’t even get people on board with a form-backing object, because it was a model that didn’t tie directly to a database table, gasp! (That’s the point of an FBO)

      As for “Poor bastards don’t even realize how bad they are” – that was obvious, I thought. The person said “skill issue”, making fun of me, so I was turning it around on them. That final sentence was driving the point home – the person who says “skill issue” when thinking that I don’t use Ruby well is most likely in that 90% who don’t even know how awful their output has become.

      In some ways I welcome AI taking dev jobs. Most AI output is as good as, or better than, the output I saw from at least half the career devs I’ve ever worked with. Ruby devs just so happen to be among the worst (though PHP devs are pretty awful, too).

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.