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.
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).
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 and this list 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.
You are right of course, but not for your stated reasons. Essentially RoR doesn't scale. RoR scalability is a meme, anything else scales much better. From node to PHP, they all can do much more on much less hardware. To achieve hyperscale with RoR you have to throw absurd hardware with layers upon layers of load balancers in front of it.
But I'd argue that it doesn't matter at all for a startup. Like you said most won't ever reach the point where they need such a thing. But they all benefit quite dearly from the excellent developer velocity provided by RoR.
> most won't ever reach the point where they need such a thing
I considered covering this argument in my gp comment. What if your startup does grow to the scale where it becomes an issue? Do you suspend new user signups until you can do the rewrite? Or do you just let things keep spiraling, like GitHub? Because by choosing RoR you are making an assertion up front: our startup will never scale beyond X users (because you're never going to get buy-in for a rewrite).
I disagree with:
> Because by choosing RoR you are making an assertion up front: our startup will never scale beyond X users (because you're never going to get buy-in for a rewrite).
How can this be true when we know that Shopify, Gitlab, Github and all others are using RoR.
Here is a more concrete scale[1]:
> We served 75.98 Million requests per minute to our commerce platform at peak. That’s 1.27 Million requests per second!
Is that a bit enough limit for you?
Here is more:
> We achieved 99.999+% uptime while averaging 3 Terabytes per minute of egress traffic across our infrastructure [2]
[1] https://twitter.com/shopifyeng/status/1597983926126977024
[2] https://twitter.com/shopifyeng/status/1597983918900510720
By the time you reach this problem, you'll have an army of developers to take care of this.
I've worked for three successful startups that started on PHP that couldn't scale the PHP code bases with their customer growth. All three rebuilt on Rails and are still in business and on Rails today.
Another startup where I'm very close with the founders they are on Node and they say the system is "a complete dumpster fire". They wish they had built on anything else.
The company I'm with now is primarily a giant Rails monolith and we have 100s of thousands of users connected at any given time. Our biggest bottleneck isn't Rails it's Postgres. We are dealing with billions of rows and Postgres isn't really even the problem. The problem is our data model wasn't designed in a way that would allow sharding/partitioning. Even this isn't an intractable problem. We create updated schemas, migrate, backfill. What we don't need to do is leave Rails "because it doesn't scale".
Most companies that moved off of Rails because of scalability either don't actually understand scalability or it was 15 years ago and they were on Rails 2 when it was still immature.
Most battle tested languages and frameworks can be adequately scaled if you have the right devs. I think that a lot of the reason we see system rewrites due to scalability is more because startups tend to hire developers that like to "build new things fast" and those aren't necessarily the same as the developers that have already dealt with 1M+ users at petabyte scale.
Once you become that successful sometimes the solution is to bring in people that have solved these problems of scalability previously. This sometimes results in rewrites in whole or in part because their experience is on a different stack.
In one of the PHP to Rails (for scalability) projects I worked on I was contacted quite early in the process. I am a longtime friend with one of the business owners. The existing developers could not scale the product horizontally and were already on the largest instances available at the time so there was no more ability to scale vertically.
They had hired a new technical lead that had extensive experience scaling Rails, but most of the team only knew PHP. My team did both Rails and PHP consulting at the time and we were hired to speed up the rewrite in Rails while the PHP devs were doing a mix of trying to keep things running and learn Rails so they could support after the rewrite.
The first thing I did was review the existing PHP codebase. I then advised that they not switch to Rails because I firmly believed that in about 3 months the PHP version could be refactored to allow for adequate horizontal scalability. The full rewrite was expected to take a little over a year.
The owner agreed that my assessment was probably right, but he still opted for the rewrite because the new lead was competent at scalability and likely would have quit if they stayed on PHP.
https://github.blog/2023-04-06-building-github-with-ruby-and...
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.
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.
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.
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.
There are new books written, new conferences organised, Hanami 2 is out, new organisation created by companies to support Rails docs and marketing, Phlex is a nice way to work with views, someone started to work again on Camping, someone else is working again on a new portof shoes.rb
More content is created everyday: see for example dev.to starting to have beginner articles. A very good sign.
now regarding your fear, what I can say is act like your fear is real and it will be in some way or another.
Those aren't all gone. But in the grand scheme of things, Ruby, and Rails' have been relatively decimated. There now are about twice as much (web) devs as back when it started but Rails nor Ruby is hardly twice as big. It's been going strong, solid, flatline.
I wrote a longer post, a while ago, with sources and numbers on this. It was featured on HN https://berk.es/2022/03/08/the-waning-of-ruby-and-rails/ (and frankly, it's going faster and is worse than I predicted back then)
From where I am, things don't look the same as you are describing them:
1. https://newsletter.shortruby.com - it is younger than 1 year, but you can find a lot of new content there: new podcasts were released in the last 12 months, new conferences were organized, and new books were announced. When I say new = it means never done before, not new editions.
2. https://rubyandrails.info - while it is not a comprehensive directory, it has a lot of resources. Indeed the youtube courses section is empty, but that is due to my lack of time, not because they are missing
3. Also, take a look at this https://rubyconferences.org
I don't have time to debate everything you wrote in the article, nor do I think I can change your mind.
I also don't know the future. Maybe you are right, maybe you are wrong. I choose to believe that Ruby is not dying and act like it: launch a newsletter, start to write a book, and prepare some more projects.
can you explain this a bit more? it seems to me that test coverage and typing solve different problems.
Give this a watch: https://www.destroyallsoftware.com/talks/ideology
Types do not remove the need for unit tests, but they relieve some pressure from them.
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.
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.
You can literally create a directory called app/my_actual_app and put all your business logic in there, Rails will even autoload it for you.
IMO it’s the sudden change from the “we’ll hold your hand every step of the way and offer tools and workflows for everything” web part (controllers, routing, ORM) to the “go and build your goddamn app” dealing with business logic. So many (especially new) devs try to stay in the cozy zone of having a nice name for everything at all costs, so they try to cram everything into “services” and “decorators” and “interactors” (yuck) and they’ll build business logic out of callbacks on ActiveRecord models and overload the poor things with dozens of “concerns” instead of, you know, going and building a goddamn Ruby app.
This recent article has some alternatives https://blog.appsignal.com/2023/05/10/organize-business-logi...
Their main argument against the first piece is:
> One problem with fat models is that unless you are really disciplined in your code hygiene, they can tend towards an assortment of code smells
And I wholeheartedly agree. With the addition that "code hygiene" if not enforced or encouraged, is always one of the first victims under stress. And every (successful) project will see such stress.
With Rails you have to spend extra effort to keep doing "the right thing", whereas is should cost cost less effort to do that, and extra effort to "do the bad thing".
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.
More here: https://www.artima.com/articles/the-philosophy-of-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.
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.
I consider a concerns to be more complex and unexpected versions of a Module.
I consider "render @foo" to be just an incomprehensible version of the explicit "render_partial("the_name", ...)" And so on.
All of these have bitten me many times, oft in production even. Many of these caused me and my step debugger hours of wading though deep stacks of method-missing or runtime code definitions.
I think this turns people away from Ruby (and is what Ruby people love about Ruby). I'm not a fan of Go, but people say they enjoy writing Go, which looks very different from Ruby.
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.
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.
> 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?)Twitter started with rails and constantly went down. Rails was blamed for the downtime, perhaps unfairly.