Hacker News Reader

> Ruby isn't the fastest language, but it's now competitive enough that the same critics might as well throw Python under the bus while they're at it.

You say that like it's a point in support of Ruby, but, yes, absolutely, Python should be thrown under that same bus. Both languages are dramatically slower than other languages that are available. My little hobby programming language with a bytecode VM I wrote myself in a single C file is faster than Ruby and Python. It would be hard to design a language that isn't easy to make faster than Ruby and Python.

They both pay an incredible runtime performance cost for their deep support for dynamic runtime metaprogramming and mutability. If you don't want those features, I don't think it makes sense to use those languages.

I would argue the eventual "bogged down" feel of a Rails application isn't ruby itself. It's rather the abuse the database takes because ActiveRecord allows you to lazy load records so easily by abstracting SQL calls, so you're hitting the database many times per request and not realizing it until you get bitten. There is an option to disable lazy loading at a project level, but I've run into gems that assume it's enabled.

For comparison, elixir's Ecto doesn't allow lazy loading

In addition, for things that can't be done easily with ActiveRecord, you can write your own SQL, but then you really need to know SQL to get the performance right.

Where I work, our main product is a Rails monolith, over 10 years old at this point. The few serious performance issues we currently have are due to complicated SQL queries written back when the DB was much smaller.

If speed was all that mattered then almost no one would be using Python.

That's why my last sentence starts with "if".

Speed of development, so still speed- just across a different axis.

These days TruffleRuby can run Ruby at incredible speeds. It unfortunately can't run really huge apps at the scale of GitLab though.

> It unfortunately can't run really huge apps at the scale of GitLab though.

Why?

I guess part Hyrum’s law in that big projects depend on implementation details to a degree, related but many C extensions (though Graal can run these as well, but perhaps not all of them), and last I read about it, the JIT compiler is not yet that good at optimizing very big applications — it takes a really long time for some functions to become hot enough.

I think it's just that the very largest codebases are the most likely to end up depending on obscure bugs in Ruby or the surrounding ecosystem itself, or maybe features that basically nothing ever uses except that one file buried deep in that one gem that three real programs use. Ruby apparently has a lot of stuff like that.

> But I imagine Rails is being increasingly dismissed by newbie developers as being obsolete and not-cool. Mature companies may realize it's in their best interest to communicate that their boring-tech works just fine and that they have no plan on changing to cool-tech. If it's true, then someone's got to say it, right?

That's precisely the problem. If engineers were a dime a dozen, then Rails could be a great choice. Boring tech is a great place for businesses to be, in theory. Back here in reality, finding engineers is pretty hard, and the ones who we can find, are all only interested in working with Cool New Shiny Toys. If we posted a Ruby ad, we wouldn't get any bites. It's not used here.

Boring tech is great, until it becomes a noose to hang yourself with.

> If engineers were a dime a dozen, then Rails could be a great choice.

Are they not, though? The narrative is that there's simultaneously too many engineers coming out of school and yet it's extraordinarily difficult to hire engineers. Which is it? Or are most engineers really that bad that they're unhirable?

> Back here in reality, finding engineers is pretty hard, and the ones who we can find, are all only interested in working with Cool New Shiny Toys.

I definitely believe you, but I wonder how much of this is self-fulfilling. Maybe a lot of engineers get into cool-tech because more jobs are demanding it, and their perception is they'll be quickly obsolete if they work with boring-tech. Most newbs seem to look towards startups first, which are going to be using cool-tech a lot of the time, but there seems to actually be a lot of interest on HN in working with boring-tech at either nontech companies or BigCo.

It's not hard to hire an engineer that can take a ruby on rails project and run with it. There's mountains of tutorials and books about it. You don't need the best of the best for this.

Some people have decided that that isn't good enough for their company though.

No language book can genuinely teach you the ecosystem for that language. The ecosystem is many times larger than could ever possibly fit into one book, but the ecosystem is what provides you with the libraries you actually reach for to build things day-to-day.

Expecting engineers to self-teach from a book is practically begging for NIH syndrome and a rewrite in two years.

> The narrative is that there's simultaneously too many engineers coming out of school and yet it's extraordinarily difficult to hire engineers. Which is it?

It's both. You need to be a large company to hire junior talent. The local market is mostly startups without well-developed production guardrails and well-gardened, too long backlogs. The large companies cherry-pick for the relatively few junior positions that open and they aren't using Ruby internally. Thus the Ruby ecosystem hasn't developed here.

> but there seems to actually be a lot of interest on HN in working with boring-tech at either nontech companies or BigCo.

HN trends senior talent which has been around the bloc enough times to know that stacks change and people don't. Most of the labor market comes into interviews and want to impress you with how many languages they know.

I bet you wouldn’t hire me, even though I am a very competent developer with a long resume. The problem is narrow minded hiring. I have never had problem hiring good people.

> That's precisely the problem. If engineers were a dime a dozen, then Rails could be a great choice.

If engineers are hard to find then isn't using a framework that maximises developer productivity the way to go? Rails definitely falls into that category.

Related, we recently advertised for Rails and React engineers. We had about the same number of applicants for each position but the Rails engineer quality was in general higher than the React engineer quality.

> If engineers are hard to find then isn't using a framework that maximises developer productivity the way to go? Rails definitely falls into that category.

Languages are not like cars. You cannot take a professional Rust engineer and drop him into a Ruby environment and expect him to be immediately highly productive, as if you were switching him from a Miata to a Ferrari. Languages need to be learned all over again, their ecosystem needs to be learned, beginner code needs to be reviewed by someone senior who is more familiar with the language. You can't just make an executive decision to go with Ruby because it has a reputation for productivity and expect immediate productivity gains.

We've not had a big problem getting candidate streams of people who want to work with Ruby. In a way I don't mind having an implicit filter against people who only want to work with shiny new things, as we don't really want our platform filled with everyone's favorite shiny technologies any more than we need a shiny language to write a good-sized e-commerce web app.

> Not every business has the money to waste converting their old apps to cool-tech like Elixir or a React frontend with microservices.

I always ask myself (and the team at large) "how much time/effort will it take to reach parity using the new tool-set?". The answer usually settles the debate immediately.

In my experience, scaling RoR is totally doable, but very tricky, as the both language and associated frameworks are very terse, opaque and by default seem to do the thing that does _not_ scale well. Because of all this magic, you have to be somewhat of an expert to avoid all the foot guns.

As a new shop, without a known depth of knowledge and talent, I'd probably avoid Rails if scaling is a concern, but if I'm Gitlab or Shopify or some place with world class Ruby engineers, I'm staying the course.

> Someone needs to be interested in working with Rails.

A lot of us are. I don't think Gitlab is in any shortage of resumes...I tried. Might be the market collapse or whatever reason, didn't even get past the initial HR interview. It's also possible my country of residence isn't high on their list...we are expensive.

> But I imagine Rails is being increasingly dismissed by newbie developers as being obsolete and not-cool. Mature companies may realize it's in their best interest to communicate that their boring-tech works just fine and that they have no plan on changing to cool-tech

I dont think that's the case. I think Ruby is dismissed because it's not a boring language, but has none of the safety of the other "shinier" languages.

IMHO, the only two valid business criticisms at scale are:

- It's loosely typed and most orgs end up putting in some type system since it can get unwieldy

- Performance is poor at scale

Both can be "patched" fairly easily at scale though:

- Start introducing a typing system: https://sorbet.org/

- Split heavy throughput services out into things like Go, Java, etc.

I've worked on some huge rails apps, and I don't agree at all that performance is poor at scale. You might need an extra instance or two to handle the same traffic load, but in every codebase I've seen, the problems of slowness are related to database access, slow/unoptimized calls to other services/APIs, etc.