6 ms·

Companies justify using Rails publicly because it makes financial sense. There's this meme that Rails "just doesn't scale" and is "yesterday's software", but n

Companies justify using Rails publicly because it makes financial sense. There's this meme that Rails "just doesn't scale" and is "yesterday's software", but neither are necessarily true. 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. There's things I don't like about both Ruby and Rails, but it's a perfectly viable and productive way to build websites. A very scant number of businesses need to be at the scale of Twitter or The Google, in which case Rails can be a great choice. 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? Someone needs to be interested in working with Rails. Not every business has the money to waste converting their old apps to cool-tech like Elixir or a React frontend with microservices.

dan_quixote 4y ago
> 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.
munificent 4y ago
> 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.
- ydnaclementine 4y ago
  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
  - grimjack00 4y ago
    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.
- ravenstine 4y ago
  If speed was all that mattered then almost no one would be using Python.
  - dijit 4y ago
    Speed of development, so still speed- just across a different axis.
  - munificent 4y ago
    That's why my last sentence starts with "if".
- native_samples 4y ago
  These days TruffleRuby can run Ruby at incredible speeds. It unfortunately can't run really huge apps at the scale of GitLab though.
  - 4y ago
weatherlite 4y ago
> 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.
solatic 4y ago
> 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.
- ravenstine 4y ago
  > 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.
  - bcrosby95 4y ago
    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.
    - solatic 4y ago
      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.
mbesto 4y ago
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/ https://sorbet.org/ - Split heavy throughput services out into things like Go, Java, etc.
- freedomben 4y ago
  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.
michannne 4y ago
> 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.
zumu 4y ago
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.

dan_quixote 4y ago

> 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.

munificent 4y ago

> 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.

ydnaclementine 4y ago
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
- grimjack00 4y ago
  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.
ravenstine 4y ago
If speed was all that mattered then almost no one would be using Python.
- dijit 4y ago
  Speed of development, so still speed- just across a different axis.
- munificent 4y ago
  That's why my last sentence starts with "if".
native_samples 4y ago
These days TruffleRuby can run Ruby at incredible speeds. It unfortunately can't run really huge apps at the scale of GitLab though.
- 4y ago

weatherlite 4y ago

> 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.

solatic 4y ago

> 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.

ravenstine 4y ago
> 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.
- bcrosby95 4y ago
  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.
  - solatic 4y ago
    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.

mbesto 4y ago

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/ https://sorbet.org/ - Split heavy throughput services out into things like Go, Java, etc.

freedomben 4y ago
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.

michannne 4y ago

zumu 4y ago

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.