It seems that Ruby and Ruby on Rails have some sort of renaissance now. I only know a bit of Ruby, but I hear it a lot that RoR is the best thing for prototyping and startups, even better than Django.
Personally, I write Go professionally and I love the simplicity and the absence of many dependencies. That said, Active Record and Active Job seem to do exactly what I write manually over and over again in Go due to having no frameworks.
Is Rails still that good?
If I was at a startup trying to solve a business problem, the last thing I'd want to do is bruise my knuckles fighting with my tools. Rails provides an opinionated way to structure your codebase as well as many existing modules that just work. It's not exclusive in this space, but it's a safe bet. You can get any dev that's familiar with rails to ramp up pretty quick. If you rolled a custom web framework in a dialect of javascript you may have a more challenging time.
0: https://boringtechnology.club
Some of these are eyebrow raising and certainly not boring!
Many opinionated frameworks are also less reliable because of the layers of abstraction, so I'd also associate opinionated framework = sexy and temporary.
I've never actually used Rails in production, just did some tutorial, so I'm probably wrong about this.
I think of RoR, Laravel, Next.js, and Django etc. like I'm crowdsourcing my apps architecture so I can just worry about building out my business logic.
Even if you don't choose a framework at some point you end up building your own framework and introducing new opinions anyway, what I often see in these homegrown frameworks are.
1. Somewhat conflicting opinions expressed across different layers of abstraction that you build into your app over time.
2. In not having an opinion you try to satisfy many ways of solving problems introducing more edge case problems and serious over engineering.
> Many opinionated frameworks are also less reliable because of the layers of abstraction, so I'd also associate opinionated framework = sexy and temporary.
That's one of the persistent knocks against rails -- the layers of abstraction. I think that's fair, but it's a tradeoff. You either go along with it because it's advantageous or don't. Once you get familiar with the concepts and the theory of it the framework does what you expect, not a lot of surprises.
I'll push back on "temporary" though. It's been around for 20 years. It's old, so by definition it's not sexy.
Personally, I've built a number of apps in Rails that are still in production so it's a solid choice.
Not affiliated with either of those things, but what does this even mean? Basecamp is a business. Jason Fried is a businessman. Basecamp is a product developed by 37 Signals, a company Fried co-founded.
How does any of that create "Musk vibes"? I'm seriously wondering what this is all about.
But the good news is that you can just ignore them and enjoy the framework, like I do.
The Jason Fried and David Hansson Musk/Fascist vibes are real and are a problem. Most of the people in the Ruby community recognize that problem and are taking steps to mitigate that issue. Most of the core Rails committers don't work for 37 signals, and it's not really a thing made just by them.
Definitely use Rails to start a new project. The real hero here is Ruby and the Ruby ecosystem. It's incredibly stable and mature, But also getting faster every year. About 20 years ago Ruby web frameworks agreed on an ad hoc server interface api, Rack, which is one of the secrets that has made Ruby incredibly stable.
The package system, Ruby Gems, is really great. You can find a Gem for just about anything you could ever need or want. With mountains of Open Source projects and code to read to pick up patterns, or to see prior art to solve a unique problem you're encountering.
Anyways, it's a really solid choice.
Why? What "Musk vibes" have they given off?
i know what you mean about abstraction and flexibilty, but I think Rails mostly avoids that and is actually quite flexible. But I don't use the new hotwire JS stuff, that is one area where I share your concern. It's easy to use Rails without it, with the JS of your choice.
There are other great frameworks, but a monolithic rails app serving up an API for a react client and two mobile clients is just so dang easy to work in if you get along with it.
As far as performance is concerned, we will do between 1,000 and 2,000 dynamic requests a second this year with no caching during our peak season. Not crazy traffic, but respectable enough. They aren't trivial requests, depending on the user making the request and how much content their account has in it, and how many connections their content has to other users and content. We also do a significant amount of fitness / geo data processing. We'll probably be ingesting between 1,000,000 and 2,000,000 recorded fitness activities per day at our peak this year. This will comfortably fit on a couple of app servers. My performance worries are all focused at the database layer. About once a year we go in and pick all the low hanging performance fruit for 2-4 weeks, and every few years we buy some new app servers to replace old ones. Scaling has never been a real problem, but we are definitely small potatoes compared to many projects out there tackling real scaling issues.
That being said, I put up a PR against our frontend react repo every once in a while, and I am super jealous of the work they put in on typescript and CI. It puts some huge guardrails on development that are a productivity boost, with of course a decent up front investment in all the tooling and the requisite maintenance.
BTW shoutout to the Loco team, for my favorite new web framework. If you're already working with Rust in general, and your business requires extreme speed and extreme reliability-- beyond simple horizontal scaling CPU/GPU/K8-- then take a look at the stack of Loco + Axum + Tokio + Rust.
Thanks for the shoutouts!
We definitely try our best to match the Rails experience. Being that the experience is not something you can just have as a side effect.
We build stuff into Loco that Rails has, try it out, then decide if it's "Railsy" enough in the experience. If it's not, we delete it and try again.
I'm a Rails superfan personally, however as life turned out to me, I like Rust much more than I like Ruby. So the decision was to go "loco" and implement Rails for Rust.
We're looking for more feedback and people to try out Loco, please feel free to do so :-)
A lot of people say things like "the difficulty with Rails is in the long term". To them I'd say two things:
- In starting a new company, I'd assume failure as the starting point and do everything I can to wrestle success from the jaws of failure. I don't want to waste time worrying about what will happen in the long term, because statistically we won't get to the long term. I'll take every advantage I can get to get over that statistical hump. Rails gives me that advantage on the engineering front.
- I'm currently working in a Rails codebase along with a few hundred other developers and its fine. It isn't great, largely because it was an inherited codebase I was acquired into and the OGs made some (imo) sub-optimal decisions, but it isn't really any different than working on a java project with a few hundred devs. Its fine at scale.
The best thing about Rails is its strong, opinionated defaults for building web applications. It handles HTTP request routing, data marshalling, SQL interactions, authentication/authorization, database migrations, job processing, and more. That means you can focus on business logic instead of wiring up the basics.
Rails isn’t as fast or lightweight as Go, but they solve different problems. For most web apps, the bottleneck is I/O, not CPU. Rails optimizes for developer productivity, not raw performance, and that tradeoff is often worth it, especially when speed of iteration matters more than squeezing out every last cycle.
We just have blog post submission on HN that suggest otherwise. At least for RoR.
Luckily we have YJIT and we are finally understanding may be we are actually CPU bound, which means we could look into it rather than always thinking it is a I/O DB Problems.
It can be hard to recruit for as mentioned, but I've never had an issue with it unless you have constraints (on-site, salary, etc).
Try to stick with the "Rails Way" as long as possible. It's tempting to adopt patterns that have become popularized (services objects, etc), but they can work against you in a Rails app.
It is but;
Coming from Go, you will likely find Ruby and Rails to be relatively slow. Depending your definition of performance that could be acceptable or a no go. However Your development speed may likely be 5 to 10x.
The good thing is that Ruby is not I/O Bound is finally gaining momentum. After years or decades of I/O Bound we have finally come to may be it really is more CPU bound than we admit it to be. And things are improving. YJIT improves real world performance by 20-40%. If you measure only the CPU part and not total response time that is 30-60% or in some cases even more. There are still more optimisation could be done.
Rails and ActiveRecord are also improving. Shopify, a $150B market cap company now has all the incentives to improve Rails. YJIT is work from Shopify.
And throw more hardware at it now makes sense more so than ever. CPU Cost / Core is falling faster than ever. Thanks to competition from AMD EPYC and AWS Graviton / ARM. 2026 we will have 256 Core Zen 6c. We may have 288 Core Darkmount this year. You could quite literally have a single monster server that is enough to serve unless your site is Top 5%.
Database is less of an issue, starting small you could use SQLite which is now well supported by Rails 8.0 and it is enough for most. Planning big just use PlanetScale which uses Rails internally and is being used by other Rails site including Github.
The whole ecosystem is basically ready for you to just work on business logics.
I am hoping we get more defaults, Rails finally get authentication with 8.0. but could do more work. We will hopefully see more improvements coming in Rails 8.1, and so much more to come from Ruby side as well.
Rubbish.
This is just fanboi talk that all rails developers tell each other without a shred of science.
You can easily make a webapp with authentication, authorization, literally everything in just a couple of days/weeks.
This takes years in Go, and you likely will end up with lots of code with questionable quality, as Go libraries for developing a Web App aren't as battle tested as Ruby.
I like using Go for tiny services with a defined purpose.