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.
Ruby's fine for small to medium-sized projects. It's pretty great for small DSLs.
In my professional experience on medium to large-sized projects, its lack of explicit typing, the habit of Rubyists to use its fairly-substantial metaprogramming capabilities at the drop of a hat, and (for projects that include pieces or all of Rails) the system's implicit library loading make such projects a nightmare to reason about and maintain.
I'm sure these aspects are manageable with a small group, or a very, very disciplined group, but when you have large-sized projects that have been continually worked on for ten, fifteen, more years, you're just not going to be able to guarantee that everyone involved will have the combination of knowledge and discipline require to ensure the thing remains easy to understand, extend, and maintain.
This has been my experience too reading the Gitlab code. It's absolutely impossible to follow - you can't use static typing to follow flow because there isn't any, and you can't even grep for identifiers because half of them are dynamically generated. Every time I've wanted to understand something I've been unable to even find the relevant code.
Contrast that with gitlab-runner (Go) or VSCode (Typescript) both of which I have been able to not only read easily but contribute features to. VSCode is at least as big a codebase as Gitlab.
That experience has made me want to avoid Ruby like the plague!
Years ago, this was almost exactly my experience at my first software job, a large Rails monolith in the Ruby-on-Rails heyday. Obviously I was inexperienced, but aside from that, the application code itself was so hard to understand that I was seriously considering whether I was cut out for professional software development. It was just impossible to tell where things were defined, where data was coming from, when things were actually executing, etc.
It was only after working on other projects in other languages (Clojure, Java, Scala, Nodejs, Elixir, Rust) that I started to realize that maybe not all languages lead to teams writing code that is this difficult to follow.
People always say "oh, you can write terrible code in any language", and while this is true, it's a tautology. It doesn't actually tell you anything useful. I now think there is actually a pretty large spread in what kinds of code the various languages/frameworks encourage people to write. I'm not saying it guarantees what kind of code people will write, but, just for example, there absolutely is a difference between what the average Clojure programmer will write and what the average Java programmer will write.
If all of the various languages and frameworks and libraries all just ended up with the same effort producing the same results, no one would ever make anything new, because it would be pointless to do so.
> [A]side from that, the application code itself was so hard to understand that I was seriously considering whether I was cut out for professional software development. It was just impossible to tell where things were defined, where data was coming from, when things were actually executing, etc.
If the enormous pile of Ruby projects that I and the folks I work with at $DAYJOB had been the things I was required to work on and maintain at my first dayjob, I would have (no joke) left the field to go become a lawyer.
I'm so, so, so glad that I started off with C++ and got to work at a couple of C++ shops which got me to understand in my bones the importance of good tests and comprehensible-to-a-mere-mortal code.
> ...there absolutely is a difference between what the average Clojure programmer will write and what the average Java programmer will write.
Oh yeah, definitely. After being worn down by the many years I've burned at my current position, I've become VERY skeptical of the "Let's use $LANGUAGE_OR_TOOL because it will make it easy to hire!" argument. The quality of the stuff that the average user of that tool produces matters A TON.
Implicit library loading isn’t even the real problem, it’s the global namespace. I think it, more than anything else, makes large projects difficult to manage due to the inability to grok the dependency graph.
> Implicit library loading isn’t even the real problem, it’s the global namespace.
I'm not sure what you mean by this? Ruby gives you pretty much the same namespacing powers that most mainstream languages do.
If your argument is that noone should EVER be able to hoist something into the global namespace, then I'm going to have to pretty strenuously disagree with you. Power tools are good to have for when you need them... but it's very important to have the restraint to only use them when you need them and leave them on the shelf when you don't.
Ruby is unsuitable for large projects for the same reason python is, but it also lacks the huge ecosystem and labor pool that python has. When I'm interviewing and a company tells me ruby is the main language, I end the call.
“X is unsuitable for large projects” when there are many readily discovered existence proofs to the contrary (including but not limited to $1B+ businesses, massive communities, deep thoughtful and disciplined engineering spokespeople, etc.) strikes me as a common trope here on HN.
(Which is not to say X is flawless even at scale or a clear best fit along all axes. That is true for no X that I know of.)
The fact that a language is used for large, successful businesses/projects doesn't mean another language wouldn't be better. It's just terribly difficult to measure such things.
I think JavaScript as a backend language was a mistake, and that Node has single-handedly caused more damage to the entire tech industry than any other aspect.
That hasn’t stopped billions of dollars of revenue from being created with it.
At least Ruby is unpopular enough (compared to Node) that people who know it are probably decent at their job.
Nobody actually follows the LSB as written. But it remains useful as an idea of "stuff that was installed in old distros so usually has some newer version available".
Assuming you can survive all the incompatible interpreter changes for Python etc., the main annoyance with LSB proper is shared library versions.
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
Ubuntu, Debian, Arch, CentOS - none of these, as far as I know, ship with a Ruby interpreter by default. I’d like to be wrong, but I don’t think many do.
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.