6 ms·

I always hear good things about Ruby on Rails, yet it remains relatively niche. I first heard about Ruby + Rails in 2013, and ten years later it seems to be jus

I always hear good things about Ruby on Rails, yet it remains relatively niche. I first heard about Ruby + Rails in 2013, and ten years later it seems to be just as niche. Loved by those who use it, but niche. Why does it continue to struggle in this way when more recent languages like Go are booming?

4pkjai 3y ago
I think they lost a lot of growth because of the bad PR from Twitter. Twitter started with rails and constantly went down. Rails was blamed for the downtime, perhaps unfairly.
- CTmystery 3y ago
  That's interesting. I remember having to defend my using ruby to other programmers around that time. I always loved it, and all the hate seemed to be centered around "it's too slow". No one ever brought up twitter being down, explicitly, that I can recall. Perhaps that's what they had in the back of their mind though? It's been a bit of a mystery to me why people passionately hate on ruby and IMO dismiss it out of hand. It's so nice to program with.
xiphias2 3y ago
For me it's quite the opposite. It was the best way to build applications in the past when client side js was hard to use. Many startups took advantage in creating apps fast with RoR. Now that (especially with TypeScript) JS is good enough, browsers and JS engines improved a lot, I start to see less advantages in not using js/ts both for client and server.
whichdan 3y ago
I think Rails is a victim of its own success: many of the hot new Rails codebases from that time are now 10 year old monoliths. And those monoliths need incredible amounts of tests to compensate for the lack of compile-time type checking, Rails version upgrades are multi-month nightmares, and the object-oriented statefulness of the language means that complex load-bearing code can be extremely tricky to untangle. There are certainly new compelling projects like Sorbet to add type checking, and the ecosystem itself is very mature, it's just that the average codebase is not going to live up the experience you might have with a brand new one.
- berkes 3y ago
  That ecosystem is crumbling too, unfortunately. Where, for example, in 2015 any SaaS or API would provide a gem (lib) to interact with it, today it's no longer the case. Modern PSPs, storage, search engines, etc almost all lack an official gem. Often lack even a third party one. And where back in 2015 there were popular systems in Ruby outside of rails, all those are crumbling and/or gone. Jekyll is no longer the go-to static site manager, Chef and Puppet no longer the obvious devops tools. And Ruby is completely absent from emerging technology (AI, blockchain, WASM, data science, etc). I'm afraid Ruby is becoming a legacy language and Rails' will be a legacy framework soon. Where the bulk of the Ruby jobs are to keep old stuff running and maintained. Afraid, because I'm still primarily Ruby developer.
  - tra3 3y ago
    That’s been my experience too. Where is the puck going to be then? JavaScript?
    - berkes 3y ago
      I think it'll be more fragmented. For one, because major language gain more features and such start overlapping more. Making them easier to move between. And secondly because we're now at that pendulum swing, where people realize that "write once run everywhere" has severe downsides, easily overcome by writing software in a language or framework that fits the usecases best. The latter is easily seen in the common practice of splitting out the UI in webdev. And in using microservices. Rails stubbornly goes against this common practice (which isn't a value call, just an observation) and as such, places itself outside of what we commonly are used to . The former is seen in e.g. typing or type hints being added everywhere, languages getting support for functional programming, generics, interfaces, class inheritance etc.
  - chucke 3y ago
    Thx for the FUD salt. Rails never left, and neither did sinatra. In fact, other frameworks came to play, like roda. Ruby is ok. Sure, jekyll is no longer the new hotness, but I don't see a market shift towards a single tool. There's just the usual fragmentation. Hugo, next, none of them is consensual. Ruby was one of the primary targets of wasi. It compiles to WASM since 3.2 officially, but work started more than a year ago. Ruby in the browser is possible. Sure, not everyone is targeting Ruby. But I don't see new products targeting new stuff either. Seems that there are less oficial SDKs nowadays, usually targeting the top 3 tier 1. And that's fine, and means little about Ruby in the end.
madeofpalk 3y ago
I think that the things that Ruby optimises for - mainly that code should be beautiful english prose - just aren't things that developers widely ended valuing. I think that it's syntax, or what "beautiful ruby code" looks like, is significantly different from most other languages, making it more off putting to pick up or switch between.
- nullstyle 3y ago
  You've got the wrong impression of what ruby optimizes for. It's not "mainly that code should be beautiful English prose" -- which I would venture the closest you'll get for that goal is AppleScript -- but rather, quoting Matz "Instead of emphasizing the what, I want to emphasize the how part: how we feel while programming. That's Ruby's main difference from other language designs. I emphasize the feeling, in particular, how I feel using Ruby." More here: https://www.artima.com/articles/the-philosophy-of-ruby https://www.artima.com/articles/the-philosophy-of-ruby
  - berkes 3y ago
    You are right about Ruby. But what DHH does/did with it for Rails is of a different order. There, often, "beauty" is in the way. Hundreds (or thousands) of methods magically appearing from nowhere on a Record, by inflecting a database scheme runtime. Thats neat and all, but I'd very much rather just explicitly write getters and setters. It's not as if (with autocomplete) such things are a time sink.
    - nullstyle 3y ago
      Yes, RoR is a different and larger beast than Ruby. It also does not optimize "mainly that code should be beautiful English prose." You can import the joyful drive of Ruby into your RoR codebases. I've worked on plenty of rails codebases that were a pleasure to work in. Far more than any other web framework I've worked with.
      - berkes 3y ago
nahname 3y ago
It's a great tool for those that want to build CRUD apps quickly and get 99% of the things right. That speed comes from code re-use (mostly gems). Once you get experienced in rails, you primarily glue things together. It's fast, but does not feel rewarding.
- Toutouxc 3y ago
  > speed comes from code re-use (mostly gems) > Once you get experienced in rails, you primarily glue things together Both of these are equally true for most other languages with mature ecosystems. IMO the speed of Rails development reflects the speed of Ruby development in general. The standard library has everything, all kinds of little methods for all kinds of little things. Combine that with ActiveSupport extensions and you can do everything. Date.today + 3.years + 2.days 234.in?(2..235) [1,2,3].all?(&:odd?)
  - nahname 3y ago
    It's Active Record that makes rails code re-use especially unique. I don't know of any other framework where you can 1) be certain of the ORM 2) add database tables from a third party library 3) the whole experience not being cobbled together.
    - winrid 3y ago
      Django?
    - mgkimsal 3y ago
      Laravel? Unsure exactly what you're meaning by #2, but Laravel's Eloquent is an Active Record-style ORM, and can act as a layer on top of most db tables I've used it on.
deleted 3y ago
[deleted]
bdcravens 3y ago
Rails is very opinionated. Weakening these opinions in the interest of growth has always been strongly rejected.
davnicwil 3y ago
I think it might be the proverbial fast boat in a narrow stream, the narrow stream being ruby the language. It's not a mainstream one, and frankly the main reason to learn it in practice is rails. There's a big cold start problem there. You have to convince people to like both the language and the framework at the same moment of decision, in addition to committing to learning both at once. That's just always going to be more difficult than selling only a framework to people who either already know, or see more value in learning, a more mainstream language like JS, Python or Java. I think this is the biggest reason it's remained niche.
joshmn 3y ago
> Why does it continue to struggle in this way when more recent languages like Go are booming? It doesn't struggle. It's just not the hot new kid on the block anymore. It's a 2013 Toyota when the rest of the world is all about EVs. Rails is, as an ecosystem, not lacking much. There's not much room for innovation. It's mature, it's stable, it's scaleable. Personally, I value my sanity, so I stick with an older Toyota. I don't need panel gaps and batteries exploding. I just wanna build stuff.
- deleted 3y ago
  [deleted]
- zamalek 3y ago
  > it's scaleable. That is debatable. Both GitHub and Hackyderm are large-scale Rails deployments, and both share a DevOps engineer (Nóva) who I've heard complaining about Ruby DevOps at least once. Twitter was forced to abandon Rails (being the poster child for Rails at the time).
  - holman 3y ago
    Ruby was never really the issue at GitHub; there were plenty of other concerns that ranked much higher on the list. Ultimately it scaled well.
  - gls2ro 3y ago
    (first, I am biased as I have worked with Ruby since 2007 and still enjoying it) This is not a reply to you, but I decided a long time ago that I will not let this argument about scalability remain with response. If you have already decided not to try Ruby on Rails or any Ruby framework, say so. It is ok to have different preferences. But this thing with Ruby needs to be more scalable is a very weak argument. Here is why: In the tech industry, it is not uncommon to come across companies that opt to rewrite their tech stack in a different language, often citing scalability as a reason. While this argument holds some merit, it's worth noting that scalability is a complex issue that affects all web frameworks, not just Ruby on Rails. Therefore, criticizing Ruby on Rails solely based on scalability may not be a strong argument when you take into consideration the idea that there are very big companies build with it. - Ruby on Rails is scalable for 99.999% of all startups created with it. This 99.999% will die for any other reason but not because of their tech stack. Again the same can be said about any other web framework. Of course the 99.999% is just a made up number based on the fact that there are so few companies failing because of their tech stack scalability. - Twitter and Github are maybe in the top 0.0001% of web apps when thinking about scale or usage. Hope you (the reader of this comment) will create a startup that will be so successful in terms of scale. But the chances are that with 99.999% confidence, you are not them, and the chances to create a product that will be like them are slim. - The problems at scale are not only technological but also organizational. Now open this list https://www.ycombinator.com/topcompanies https://www.ycombinator.com/topcompanies and this list https://www.ycombinator.com/topcompanies/public https://www.ycombinator.com/topcompanies/public and try to check how many of them are using Ruby. There are quite a few in this top. It scales or else there should not be any big company using Ruby there.
berkes 3y ago
I've been doing fulltime Rails dev for some 15+ years. Rails (and Ruby) make tradeoffs, or just inherently have downsides that many newer frameworks, libraries and languages solve, or solve differently. For me, the most prominent are Rubys' dynamic typing and Rails' black magic. But my biggest gripe is how Rails lacks a space for business logic. Sure, you can bolt something on yourself. Or just throw it all throughout the http, storage and rendering layer willi-nilli. This has caused so many of the codebases i worked on, to be unmaintainable, untestable and therefore legacy that I can certainly blame it on the framework. I've worked on many go, rust, typescript, php and ruby-no-rails systems to be ever more certain about this. Many frameworks lack this area, and almost all quickly degrade into spaghettis. I've come to like DDD, hexagonal and clean architecture for solving this. Most are perpendicular to Rails. So, i'm certain that contributor to the lack of popularity of Rails is how hard it is to build maintainable, testable, clean projects in it.
- gls2ro 3y ago
  What is an example of a framework that offers a space for business logic?
  - berkes 3y ago
    I'd say it's a gradient. With Rails(ish) on one end, via, Nest.js and Laravel (DI), Hanami to Event Sourcing, CQRS or Hexagonal setups on the other The latter, in my experience, is best. It's a "no framework" setup really. Where you organize code according to a "framework" that's no code, but architecture, conventions, rules, and design patterns. Where code reuse goes via libs, put aside behind abstractions. I consider the question "what framework offers good architecture (for maintainability, DDD or business logic)" a somewhat wrong question because in it lies a strong opinion of what a framework is. And such frameworks are counter to what you want: you don't want these frameworks.
  - amcvitty 3y ago
    Phoenix (web framework for elixir) famously has the meme out there that “Phoenix is not your application”, with various articles etc explaining that the web interface should be a layer on top of the application code. They made a big deal of adding Contexts [1] as part of the scaffold which isn’t much more than a directory to put core app code. [1] https://hexdocs.pm/phoenix/contexts.html https://hexdocs.pm/phoenix/contexts.html

4pkjai 3y ago

I think they lost a lot of growth because of the bad PR from Twitter. Twitter started with rails and constantly went down. Rails was blamed for the downtime, perhaps unfairly.

CTmystery 3y ago
That's interesting. I remember having to defend my using ruby to other programmers around that time. I always loved it, and all the hate seemed to be centered around "it's too slow". No one ever brought up twitter being down, explicitly, that I can recall. Perhaps that's what they had in the back of their mind though? It's been a bit of a mystery to me why people passionately hate on ruby and IMO dismiss it out of hand. It's so nice to program with.

xiphias2 3y ago

For me it's quite the opposite. It was the best way to build applications in the past when client side js was hard to use. Many startups took advantage in creating apps fast with RoR. Now that (especially with TypeScript) JS is good enough, browsers and JS engines improved a lot, I start to see less advantages in not using js/ts both for client and server.

whichdan 3y ago

I think Rails is a victim of its own success: many of the hot new Rails codebases from that time are now 10 year old monoliths. And those monoliths need incredible amounts of tests to compensate for the lack of compile-time type checking, Rails version upgrades are multi-month nightmares, and the object-oriented statefulness of the language means that complex load-bearing code can be extremely tricky to untangle. There are certainly new compelling projects like Sorbet to add type checking, and the ecosystem itself is very mature, it's just that the average codebase is not going to live up the experience you might have with a brand new one.

berkes 3y ago
That ecosystem is crumbling too, unfortunately. Where, for example, in 2015 any SaaS or API would provide a gem (lib) to interact with it, today it's no longer the case. Modern PSPs, storage, search engines, etc almost all lack an official gem. Often lack even a third party one. And where back in 2015 there were popular systems in Ruby outside of rails, all those are crumbling and/or gone. Jekyll is no longer the go-to static site manager, Chef and Puppet no longer the obvious devops tools. And Ruby is completely absent from emerging technology (AI, blockchain, WASM, data science, etc). I'm afraid Ruby is becoming a legacy language and Rails' will be a legacy framework soon. Where the bulk of the Ruby jobs are to keep old stuff running and maintained. Afraid, because I'm still primarily Ruby developer.
- tra3 3y ago
  That’s been my experience too. Where is the puck going to be then? JavaScript?
  - berkes 3y ago
    I think it'll be more fragmented. For one, because major language gain more features and such start overlapping more. Making them easier to move between. And secondly because we're now at that pendulum swing, where people realize that "write once run everywhere" has severe downsides, easily overcome by writing software in a language or framework that fits the usecases best. The latter is easily seen in the common practice of splitting out the UI in webdev. And in using microservices. Rails stubbornly goes against this common practice (which isn't a value call, just an observation) and as such, places itself outside of what we commonly are used to . The former is seen in e.g. typing or type hints being added everywhere, languages getting support for functional programming, generics, interfaces, class inheritance etc.
- chucke 3y ago
  Thx for the FUD salt. Rails never left, and neither did sinatra. In fact, other frameworks came to play, like roda. Ruby is ok. Sure, jekyll is no longer the new hotness, but I don't see a market shift towards a single tool. There's just the usual fragmentation. Hugo, next, none of them is consensual. Ruby was one of the primary targets of wasi. It compiles to WASM since 3.2 officially, but work started more than a year ago. Ruby in the browser is possible. Sure, not everyone is targeting Ruby. But I don't see new products targeting new stuff either. Seems that there are less oficial SDKs nowadays, usually targeting the top 3 tier 1. And that's fine, and means little about Ruby in the end.

madeofpalk 3y ago

I think that the things that Ruby optimises for - mainly that code should be beautiful english prose - just aren't things that developers widely ended valuing. I think that it's syntax, or what "beautiful ruby code" looks like, is significantly different from most other languages, making it more off putting to pick up or switch between.

nullstyle 3y ago
You've got the wrong impression of what ruby optimizes for. It's not "mainly that code should be beautiful English prose" -- which I would venture the closest you'll get for that goal is AppleScript -- but rather, quoting Matz "Instead of emphasizing the what, I want to emphasize the how part: how we feel while programming. That's Ruby's main difference from other language designs. I emphasize the feeling, in particular, how I feel using Ruby." More here: https://www.artima.com/articles/the-philosophy-of-ruby https://www.artima.com/articles/the-philosophy-of-ruby
- berkes 3y ago
  You are right about Ruby. But what DHH does/did with it for Rails is of a different order. There, often, "beauty" is in the way. Hundreds (or thousands) of methods magically appearing from nowhere on a Record, by inflecting a database scheme runtime. Thats neat and all, but I'd very much rather just explicitly write getters and setters. It's not as if (with autocomplete) such things are a time sink.
  - nullstyle 3y ago
    Yes, RoR is a different and larger beast than Ruby. It also does not optimize "mainly that code should be beautiful English prose." You can import the joyful drive of Ruby into your RoR codebases. I've worked on plenty of rails codebases that were a pleasure to work in. Far more than any other web framework I've worked with.
    - berkes 3y ago

nahname 3y ago

It's a great tool for those that want to build CRUD apps quickly and get 99% of the things right. That speed comes from code re-use (mostly gems). Once you get experienced in rails, you primarily glue things together. It's fast, but does not feel rewarding.

Toutouxc 3y ago
> speed comes from code re-use (mostly gems) > Once you get experienced in rails, you primarily glue things together Both of these are equally true for most other languages with mature ecosystems. IMO the speed of Rails development reflects the speed of Ruby development in general. The standard library has everything, all kinds of little methods for all kinds of little things. Combine that with ActiveSupport extensions and you can do everything. Date.today + 3.years + 2.days 234.in?(2..235) [1,2,3].all?(&:odd?)
- nahname 3y ago
  It's Active Record that makes rails code re-use especially unique. I don't know of any other framework where you can 1) be certain of the ORM 2) add database tables from a third party library 3) the whole experience not being cobbled together.
  - winrid 3y ago
    Django?
  - mgkimsal 3y ago
    Laravel? Unsure exactly what you're meaning by #2, but Laravel's Eloquent is an Active Record-style ORM, and can act as a layer on top of most db tables I've used it on.

deleted 3y ago

[deleted]

bdcravens 3y ago

Rails is very opinionated. Weakening these opinions in the interest of growth has always been strongly rejected.

davnicwil 3y ago

I think it might be the proverbial fast boat in a narrow stream, the narrow stream being ruby the language. It's not a mainstream one, and frankly the main reason to learn it in practice is rails. There's a big cold start problem there. You have to convince people to like both the language and the framework at the same moment of decision, in addition to committing to learning both at once. That's just always going to be more difficult than selling only a framework to people who either already know, or see more value in learning, a more mainstream language like JS, Python or Java. I think this is the biggest reason it's remained niche.

joshmn 3y ago

> Why does it continue to struggle in this way when more recent languages like Go are booming? It doesn't struggle. It's just not the hot new kid on the block anymore. It's a 2013 Toyota when the rest of the world is all about EVs. Rails is, as an ecosystem, not lacking much. There's not much room for innovation. It's mature, it's stable, it's scaleable. Personally, I value my sanity, so I stick with an older Toyota. I don't need panel gaps and batteries exploding. I just wanna build stuff.

deleted 3y ago
[deleted]
zamalek 3y ago
> it's scaleable. That is debatable. Both GitHub and Hackyderm are large-scale Rails deployments, and both share a DevOps engineer (Nóva) who I've heard complaining about Ruby DevOps at least once. Twitter was forced to abandon Rails (being the poster child for Rails at the time).
- holman 3y ago
  Ruby was never really the issue at GitHub; there were plenty of other concerns that ranked much higher on the list. Ultimately it scaled well.
- gls2ro 3y ago
  (first, I am biased as I have worked with Ruby since 2007 and still enjoying it) This is not a reply to you, but I decided a long time ago that I will not let this argument about scalability remain with response. If you have already decided not to try Ruby on Rails or any Ruby framework, say so. It is ok to have different preferences. But this thing with Ruby needs to be more scalable is a very weak argument. Here is why: In the tech industry, it is not uncommon to come across companies that opt to rewrite their tech stack in a different language, often citing scalability as a reason. While this argument holds some merit, it's worth noting that scalability is a complex issue that affects all web frameworks, not just Ruby on Rails. Therefore, criticizing Ruby on Rails solely based on scalability may not be a strong argument when you take into consideration the idea that there are very big companies build with it. - Ruby on Rails is scalable for 99.999% of all startups created with it. This 99.999% will die for any other reason but not because of their tech stack. Again the same can be said about any other web framework. Of course the 99.999% is just a made up number based on the fact that there are so few companies failing because of their tech stack scalability. - Twitter and Github are maybe in the top 0.0001% of web apps when thinking about scale or usage. Hope you (the reader of this comment) will create a startup that will be so successful in terms of scale. But the chances are that with 99.999% confidence, you are not them, and the chances to create a product that will be like them are slim. - The problems at scale are not only technological but also organizational. Now open this list https://www.ycombinator.com/topcompanies https://www.ycombinator.com/topcompanies and this list https://www.ycombinator.com/topcompanies/public https://www.ycombinator.com/topcompanies/public and try to check how many of them are using Ruby. There are quite a few in this top. It scales or else there should not be any big company using Ruby there.

berkes 3y ago

I've been doing fulltime Rails dev for some 15+ years. Rails (and Ruby) make tradeoffs, or just inherently have downsides that many newer frameworks, libraries and languages solve, or solve differently. For me, the most prominent are Rubys' dynamic typing and Rails' black magic. But my biggest gripe is how Rails lacks a space for business logic. Sure, you can bolt something on yourself. Or just throw it all throughout the http, storage and rendering layer willi-nilli. This has caused so many of the codebases i worked on, to be unmaintainable, untestable and therefore legacy that I can certainly blame it on the framework. I've worked on many go, rust, typescript, php and ruby-no-rails systems to be ever more certain about this. Many frameworks lack this area, and almost all quickly degrade into spaghettis. I've come to like DDD, hexagonal and clean architecture for solving this. Most are perpendicular to Rails. So, i'm certain that contributor to the lack of popularity of Rails is how hard it is to build maintainable, testable, clean projects in it.

gls2ro 3y ago
What is an example of a framework that offers a space for business logic?
- berkes 3y ago
  I'd say it's a gradient. With Rails(ish) on one end, via, Nest.js and Laravel (DI), Hanami to Event Sourcing, CQRS or Hexagonal setups on the other The latter, in my experience, is best. It's a "no framework" setup really. Where you organize code according to a "framework" that's no code, but architecture, conventions, rules, and design patterns. Where code reuse goes via libs, put aside behind abstractions. I consider the question "what framework offers good architecture (for maintainability, DDD or business logic)" a somewhat wrong question because in it lies a strong opinion of what a framework is. And such frameworks are counter to what you want: you don't want these frameworks.
- amcvitty 3y ago
  Phoenix (web framework for elixir) famously has the meme out there that “Phoenix is not your application”, with various articles etc explaining that the web interface should be a layer on top of the application code. They made a big deal of adding Contexts [1] as part of the scaffold which isn’t much more than a directory to put core app code. [1] https://hexdocs.pm/phoenix/contexts.html https://hexdocs.pm/phoenix/contexts.html