by dondraper36 on 1/26/25, 5:41 PM with 175 comments
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?
by tra3 on 1/27/25, 5:29 AM
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.
by cullenking on 1/28/25, 10:46 PM
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.
by jph on 1/28/25, 7:01 PM
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.
by noodle on 1/28/25, 10:41 PM
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.
by kenrose on 1/29/25, 1:45 AM
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.
by turtletime on 1/28/25, 9:36 PM
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.
by ksec on 1/29/25, 4:08 AM
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.
by zeroc8 on 1/28/25, 8:21 PM
by fourside on 1/28/25, 7:00 PM
But your post mentioned RoR is having a bit of a renaissance. Its maintainers are still invested in it, and there’s enough of a community that you’ll find support. To me that sort of answers your question.
I’ll also say I’ve learned to take opinions about technologies on HN with a grain of salt. You’ll often find someone gushing about something and then find out, it’s someone in a team of one working on a greenfield project. Their take may not be at all relevant depending on your specific situation.
by matt_s on 1/27/25, 4:03 AM
The tech stack isn’t likely to be the deciding factor for a startup being successful these days. Pick whatever you or the team works best with.
by camillovisini on 1/28/25, 1:18 PM
by vlod on 1/26/25, 7:24 PM
Used RoR back in the day and it's a great way to get stuff out the door. I coded like I was on fire. I've never had that sensation since then doing JS/TS/React blah-blah.
If you're doing a startup, your goal (I presume) is to validate your assumptions and get customers.
If it takes off you could always rewrite the backend in Go (which will buy you lots of time) and think of the frontend at a later date.
Remember 95% (odd) startups fail, so think about failing as fast as possible.
by nauman on 1/28/25, 10:16 AM
When you’re building and iterating quickly, Rails save you from manually wiring up all the plumbing. You get enough convention to move fast, but with the flexibility to make your own decisions when necessary.
by adverbly on 1/28/25, 11:04 PM
I'd probably pick it for any medium complexity low traffic saas that doesn't have any crazy infra or ML or staffing requirements.
It's a nice sweet spot for many companies.
With high complexity you probably want strict types.
With high traffic you probably want better perf like rust or go.
With ML you want python.
With ease of hiring or low complexity backend but high complexity frontend, you probably want Next or node.
But for something like 50% of saas companies, I think rails is probably a really strong choice. A very small team can move super fast. It really is the one man framework <3
by mahmoudimus on 1/28/25, 8:18 PM
I am currently building my next startup with a friend of mine on Ruby and we are using Rails. With cursor/AI-assistance, it's the most productive I have felt in a while. Everything just works. Highly recommend Rails 8+.
by ka8725 on 1/28/25, 1:08 PM
by cweagans on 1/27/25, 5:43 PM
by xutopia on 1/28/25, 10:25 PM
Rails all the way for me!
by gregors on 1/29/25, 1:19 AM
All that being said these days I'd start with Elixir/Phoenix.
by thiago_fm on 1/28/25, 9:19 AM
I've worked in multiple languages, and personally enjoy Go and Rust, but nothing, even Django, comes close to the speed I can address a business/user need by using Rails.
When running a Startup, you want to quickly be able to try new approaches, and if they suck, you just remove the code and start again, or change. Rails is unmatched that way.
It's worth saying that Rails doesn't come with any kind of library for you to abstract business domains and you should avoid callbacks (specifically after_save / after_commit can be really bad in big applications with technical debt), so look for a library for this or write pure Ruby classes.
by nickserv on 1/28/25, 7:50 PM
RoR is great at first but in my experience quickly becomes full of hard to diagnose bugs, its magic metaprogramming seems too tempting for developers to use and leads to all sorts of problems.
There is a lack of good quality, well maintenained 3rd party libraries. No such problem with Python, Node, even PHP to a certain extent.
It's slow, except compared to Python. Ruby 3 is much better but still behind.
If you need to ship decent code fast, I would reach for Django.
If you're doing AI stuff, any Python framework will be best.
If you need to hire a sizeable team quickly, I would reach for Node or PHP.
If you need high performance and high reliability I would use Go.
by babyent on 1/28/25, 6:06 AM
Node is fast enough, easy to develop, deploy, and scale. Anything that is slow can be ported to Go.
It is easy to find solutions to my immediate problems using LLMs.
I’m just using express and my data layer consists of neo4j and qdrant. All code is single responsibility and I use layered architecture. Easy to test and feed in to AI.
I used to work in rails, mostly to port existing code to Go or node. I found it way too messy and complicated, and our codebase was awful. I am in the minority though as I know many love rails.
by iainctduncan on 1/27/25, 4:24 PM
I also, for whatever reason, seem to encounter more companies with "stuck on old version" tech debt on RoR more than on Python or Node. I'm not sure why this is.
by gls2ro on 1/26/25, 7:12 PM
Also it is true that Rails and Ruby are having a renaissance and the technical direction for both seems to me a good bet for the future.
by dewey on 1/28/25, 6:53 PM
by poushkar on 1/28/25, 9:12 PM
I knew what to expect from Rails from my previous experience.
Yet, I wasn't prepared for how freaking fast it is to iterate with Rails and some LLM (I use Cursor atm) when you know what you are doing.
The MVP I expected to take at least 2 months to finish, is going to be done in under 3 weeks, with the current speed, given there are no large blockers.
by mostertoaster on 1/29/25, 7:56 AM
I think rails is quite powerful and great for prototyping. But I’ve noticed lots of rails developers optimize so heavily for making things DRY, they make the most hard to debug monstrosities full of meta programming all so they could write a thing one one line of code instead of 3.
Still for starting out it’s pretty awesome.
If your company grows enough that you have legacy data models that no longer fit the designs demanded by customers - First: congratulations, that is awesome. Second: you are either going to want to be very careful how you add new things to your legacy data models, and how you define your boundaries, OR consider migrating off rails. If you start just slapping things on whatever data model is most convenient, to keep up with demands from product, you are going to be in a world of hurt that will take exponentially longer and longer to get out of.
by nsoseka on 1/28/25, 1:00 PM
by ksjfs on 2/3/25, 4:07 AM
After thinking it over, I decided to give RoR a shot. The framework does a lot for you, which can be frustrating if you’re used to having control over everything. Still, I was surprised by how much I could accomplish in just a few days. The productivity is impressive, especially for startups that need to get things moving quickly.
So if you just want to prove a business idea, your customers don’t care what tools you use. I’d rather pay twice the price to scale in RoR than spend double the time developing a feature. I would earn it back with the additional customers I gain by pushing features faster out the door.
by jmstfv on 1/28/25, 7:50 PM
In fact, I switched to Rails from Django because the latter was lacking.
by procload on 1/28/25, 8:35 PM
by hharen on 2/7/25, 8:31 AM
You may want to watch a talk about Rails and startups: https://youtu.be/-sFYiyFQMU8
by spo81rty on 1/28/25, 2:05 AM
by jondot on 1/29/25, 1:58 PM
Disclaimer: I'm one of the authors of Loco.
by mianos on 1/29/25, 2:31 AM
While Ruby on Rails still offers strong productivity benefits, the hiring landscape has shifted significantly, particularly here in Australia.
Experienced Ruby on Rails developers are increasingly scarce, as many have moved on to JavaScript, Python, or, as you say, Go. The talent pool is also saturated with AI-generated resumes that don’t translate to actual skills when you interview them.
If you struggle to hire Rails engineers now, it will only get harder as fewer new developers adopt the framework, and maintenance will become a challenge as the ecosystem shrinks.
Maybe it's a much larger pool elsewhere or if you can accept 100% remote.
by alessiosantocs on 2/6/25, 7:43 AM
You want something that speeds you up and frees up time to validate your idea, not reinventing the wheel.
Cheers!
by bigwheeler on 1/29/25, 3:54 AM
by pawelkomarnicki on 2/2/25, 10:48 AM
by apetrov on 1/27/25, 6:50 PM
+ added ports and adapters (aka hexagonal architecture, there are many articles on how to do it in ror)
disclaimer: i work with ror since 2006 so i have a strong bias.
by brudgers on 1/26/25, 7:32 PM
It has good documentation.
The code base is stable.
There are mature libraries.
It is practical to learn Rails.
Sure there are very good reasons not to choose Rails, but the current year is not one of them.
And the work of building any new business...let alone a startup is approximately the same no matter which technologies you choose (modulo your expertise).
Time spent researching web frameworks postpones building the potentially money printing mechanism. When your research is done, you still won't have built anything.
If you are lucky enough to grow, you will be constantly rebuilding your systems. Unless you are Telegram. They used Erlang. It has the same features as Rails except for a large pool of practitioners. Good luck.
by aristofun on 1/29/25, 1:24 AM
It’s like rails is an iphone - others are androids at best.
Within its niche of course.
by deesPeek on 2/4/25, 3:15 PM
by andrewstuart on 1/29/25, 10:19 AM
Use whatever makes you happy for front end.
Rails is not magical or vastly better than anything else in any way.
Especially not since AI and Claude.
Any mainstream technology is a great choice for building most things. Python node TypeScript Ruby, Golang C#.
Since you already know Golang you’d be nuts to use anything else unless you’re just wanting fun and learning in which case do whatever you like.
My only very strong recommendation….. use plain old SQL. It’s a superb choice.
by Andugal on 1/29/25, 11:55 AM
I chose Rails 3 years ago when I started coding it at night because it was the stack I knew best. And I don't regret it, quite the opposite.
We now have thousands of customers using it daily and it has been nothing but a joy to create and maintain this app.
by alexdowad on 1/28/25, 10:27 PM
The benefits of using a big framework (which you alluded to in your question) are easy to see in the short term. The pain comes in the long term.
Of course, there's no panacea. Your current "simple and low-dependency" approach has its own challenges, so choose your poison.
by ezekg on 1/29/25, 6:29 PM
by strzibny on 1/29/25, 10:32 AM
by bdcravens on 1/28/25, 7:04 PM
by dzonga on 1/27/25, 9:22 AM
There goes your answer. Golang was made for Google to simply - onboard junior engineers quickly. It wasn't made to make products quickly.
by austin-cheney on 2/1/25, 8:13 AM
1. What I already know if I am the one building the prototype.
2. Cost of training new employees.
3. Execution speed.
Everything else can be ignored.
by klysm on 1/30/25, 6:05 AM
by JodieBenitez on 1/29/25, 5:27 PM
by gcj on 2/2/25, 3:56 AM
I don't really understand people who chooses to MVP a startup writing their own EVERYTHING
by wsintra2022 on 1/27/25, 2:30 PM
by 999900000999 on 1/27/25, 4:18 PM
Do you want to learn Ruby. Then go for it. If not pick a different language. Pick one you know.
You might not even need a full backend server. Firebase or Syperbase might be enough
by uaas on 1/28/25, 9:32 AM
by charlie0 on 1/28/25, 8:54 PM
by phaedryx on 1/28/25, 9:53 PM
I do know Ruby well though.
by Tolexx on 1/28/25, 9:32 PM
by AshTeriyaki on 1/29/25, 8:49 AM
by cardanome on 1/28/25, 7:15 PM
There is no silver bullet that would fit every startup situation.
I think the safest "boring" stack is PHP with Symfony. It is super easy to deploy, has gotten really good support for gradual typing, very battle tested, good package management and easy to find devs for.
Plus you can run your project on a $5 shared hosting and not worry about dev ops and stuff, massively reducing costs.
Now, if you know you want to do anything AI, then using Python is also a great option. Also Flask is amazing for making Microservices. The packaging story sucks but there are ways to cope and you will dockerize everything anyway.
Or if you are planning on something more challenging which could profit from being on BEAM, why not go the Elixir route? They are still working on the gradual typing features but they are getting there and the functional style helps a lot with managing your state.
So yeah, depends what you need. I think golang is excellent for microservices but lacks a good Rails-style framework for cultural reasons. And you shouldn't really go microservice in a startup if you don't have very specific needs.
So well, pick your poison. The great thing about backend is that your customers don't care what you use. Might as well deploy Common Lisp if your hearts tells you to.
by diamondfist25 on 1/29/25, 6:26 AM
by pmdr on 1/31/25, 11:46 AM
by shortrounddev2 on 1/28/25, 8:52 PM
by vic700208 on 1/28/25, 4:40 PM
by gngoo on 1/27/25, 2:16 PM
by mfurg on 1/29/25, 7:49 PM
by arshtech97 on 1/28/25, 9:31 AM
by jkmcf on 1/31/25, 4:49 PM
1. Go with what you and your team already know (unless what you know doesn't apply to the target space)
2. Learn Ruby and especially Ruby on Rails first. Otherwise, you'll end up with a dumpster fire. Make sure you investigate the idioms, and use Rubocop, ruby-lsp, and ruby-lsp-rails -- there are more tools for linting your code that help you learn what not to do.
If you aren't using Rails for the FE, you are losing at least 30% of the benefits, unless your FE is just rendering what Rails is returning and not managing complex state.
by azimkoshoiev on 1/30/25, 9:51 AM
by Lio on 1/27/25, 5:44 PM
Rails 8 just gives you so much out of the box for a small start up that it would be my personal choice.
Having Hotwire for PWAs without having to have a frontend build pipeline or Hotwire Native for iOS and Android allowing you to reuse for your existing web frontend for example.
Or using Kamal for deployments to cheap commodity servers without having to setup K8s or use expensive cloud services.
Even things like ActionText for rich page content are a big win.
I mean you can replace everything later if you grow big enough to need separate mobile, devops and frontend teams but if it's only a few of you why bother when you could be delivering your MVP?
by nejsjsjsbsb on 2/1/25, 12:15 AM
Actually choosing something everyone is comfortable and confident in using is probably a good choice.
You may fail for too many innovation tokens though. If you go off the rails (ha ha ha) on tech stack maybe stick to postgres for storage and AWS for hosting.
by kreutz on 1/29/25, 1:29 AM
by a-priori on 1/28/25, 1:45 PM
It’s a wonderful technology, and it’s still as fresh and relevant as it was when I started. I plan on continuing to use it for the next decade.
My only recommendation is to never listen to a word that DHH says. If you don’t know who I mean by “DHH”, that’s all the better.
by firemelt on 1/29/25, 8:13 AM
Magic's just science that we don't understand yet.
by AutistiCoder on 1/26/25, 5:45 PM
by juancn on 1/28/25, 7:27 PM
Even if it turns out to become tech debt in the future, you won't have to pay for it until you're successful anyway.
by shaunrussell on 1/29/25, 3:27 PM
by devops000 on 1/29/25, 12:54 PM
by Alifatisk on 1/29/25, 5:29 PM
by jonsmostovojs on 1/27/25, 10:13 AM
Ironically, one of the reasons my startup died was using Elixir as if it was Rails[1].
Even aside from type safety considerations: in RoR variable bindings appear out of thin air! Imagine onboarding a new developer – not only do they need to learn the arcane language, but then they need to learn a bunch of non-hygienic macros!
I remember the lightbulb moment when I was patching Ruby's Devise authentication library to add verifiable credentials to it when I realised that a variable used there is not a 0-ary function, but actually something that is just bound in context by magic. Also, even Rails experts have to go on a hunt to understand magic[2] too!
I would personally just use typescript bridged to rust to preserve types ans sqlx for type-safe queries to the database.
Or use something like bubble.io if you want to iterate on ad hoc things until you get there!
[1]: https://memorici.de/posts/pre-mortem/ [2]: https://medium.com/launch-school/params-in-rails-where-do-th...
by kojeovo on 1/27/25, 2:29 PM
by desselbane on 1/28/25, 10:17 PM
Look at the trademark of other tools and you'll see that they are owned and driven by groups of people who share common ground and come to decisions that are in the interest of making technology better - not because one person was convinced of the idea it (look at how TypeScript was ripped out because DHH didn't like it).
I've been working with Ruby on Rails since 2007 and I love where it's at right now and the direction it's going, but I cannot fully trust a framework that is at the whims of one person.
by ribadeo on 1/27/25, 6:37 PM
One is well served to learn Rails for many reasons, but i would not start a green field 2025 project with any framework.
I have been burned by rapid development frameworks in the past, not Rails, but anyway, by now I've been rolling my own stacks for awhile, and it was mainly a question of language ecosystems.
Have a gander at Crystal Lang, BTW, and Amber and Lucky frameworks
by rohan_ on 1/28/25, 8:08 PM
If you build on NextJS you will get the entire tailwinds of the industry behind you. Having Cursor write a full-stack app that leverages server components alongside client components is a 10x velocity unlock that you won't get if you bifurcate your codebase (as is the rails model)
Typescript is going to be the language of AI engineering, (with Python being the language of ML engineering).
Rails is a fundamentally unserious framework:
1. It lacks LSP (any modern language should support this, think "clicking" a function call to go to it's definition)
2. it lacks type-safety (do you really want to write unit tests to enforce contracts and expectations in your code? or just use the type system?)
3. Object-Oriented-Programming is a failed paradigm for modern web development
4. elite engineers will not want to work for you