Yes, I would. In fact, I'd use any boring technology [0]. Anything that's been around and battle tested.
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.
Rails (and its ecosystem) is anything but boring with Turbo/Hotwire, StimulusJS, a shift away from queues using Redis to the database w/ Solid Queue, a reexamination of how SQLite can be used as a prod database (when tuned), and a new rich text editor on the way…
Some of these are eyebrow raising and certainly not boring!
Shifting to solid queue, backed by your rdbms, is more boring than using redis. Successfully deploying an app without anything but a database server is pretty powerful. Everything just works. I would say that's pretty boring :)
Is it boring technology? I'm actually reluctant to pick up Rails because it had always been sold by the Basecamp cult and Jason Fried gives off Musk vibes.
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 this depends on the context. I would argue that opinionated frameworks are *more* reliable, with the caveat that you need to know, and agree with those opinions.
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.
For context, I've been in mobile for 10 years and in general it's the opposite - frameworks are rigid, but the layer under it shifts a lot. These frameworks tend to collapse in an earthquake like manner after multiple updates. We usually support iOS up to 2-3 years old, that's how bad it is.
The other approach is to build it on a platform that shifts with the changes, i.e. hybrid and web. But if you crack open the source of Cordova, you find all kinds of tangled, unmaintained, bad practice wiring and rewiring. I spent a few months trying to hack Cordova plugins and we decided to just scrap the entire code and build native; fully rewriting the app into a custom framework took 3 months.
However, it sounds like tools like Rails are built on a very sturdy platform that doesn't introduce breaking changes every year? That's an angle I haven't considered.
I listened to the latest Rails keynote, I never have before. I don't recall the exact details but it was a bit of a weird vibe for me.
> 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.
>it had always been sold by the Basecamp cult and Jason Fried gives off Musk vibes.
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.
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.
>The Jason Fried and David Hansson Musk/Fascist vibes are real and are a problem.
What do you mean by this? Where have Jason Fried or David Hansson supported fascism? Your account is ten years old and this is the first comment you've ever made.
I mean that they give off Fascist vibes, and that it's a problem. Adoration for and support of fascist people and regimes are implicit support of fascism. Not explicit.
Go read their blogs, I'm sure you'll find lots of examples.
It doesn't mean you're not wrong. Is this a personal vendetta?
>I mean that they give off Fascist vibes, and that it's a problem. Adoration for and support of fascist people and regimes are implicit support of fascism.
Where? Link examples where they supported Fascism. "Vibes" are meaningless, I need specific examples of these claims, else they can be tossed outright.
>Go read their blogs, I'm sure you'll find lots of examples.
I'm not interested in prosecuting that David gives off fascist vibes. I don't have to provide proof. Kinda lazy that you're all not out there looking for the proof yourself.
To reorient the discussion around what the original poster talked about, that he gives off Elon Musk Vibes. And that it's a problem. Well it IS a problem. A problem openly, and vigorously discussed in the Ruby community.
Many people have left the Ruby community because of his behavior, and many more have chosen never to come into the community because of it. Because of the perceived strong association between him and the Ruby and Rails community at large.
Anyways, as per my original point, that despite the Fascist vibes from that guy, Ruby and Rails are still really great choices.
The good news is that I can just say: go ahead and Google “DHH blog”, read his most recent few blog posts and form your own opinions.
I’ve had a negative opinion of him for a good five years or so, but at least right now it’s easy to go read those and form your own strong opinion one way or another.
I use and love using rails, but the centrality of influence of the musk-vibes-camp is for me too the biggest downside. Yes in response to a sibling comment, the RailsWorld keynote was super weird culty vibe, agreed. But hey everything's got ups and downs. Rails is great for me to work in. Hopefully it will remain that way. There are other Rails maintainers who are not basecamp-related, some who say that dhh and basecamp's power over Rails is not as great as people think and it really is distributed maintainership and control, hopefully that is true enough and will remain so.
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.
Success because of A and attributing it to B. There's a bit of megalomania too. He has a beef against VC funding. He lost 1/3 of staff once when he implemented a policy of no personal opinions at Basecamp. He is often shared because of his unpopular opinions and his successes are used to fortify those opinions.
I'm not saying Fried or Musk are wrong, and they both have brilliant insights at times. If Musk was crazy and wrong all the time, he wouldn't be a brand name.
But both of them also appeal to susceptible people who seem to think that a few good opinions make them good all the time. Basecamp isn't even a good tool, it's a pretty average one, yet prettier than Jira. But it's down this funnel of people who will buy whatever Fried and DHH sell them.
And what I'm getting at is whether Rails is one of those things that is average but prettier than Node?
>he implemented a policy of no personal opinions at Basecamp
Except he didn't do that, what he implemented was not making personal politics a part of Basecamp's workplace culture, which is a much more moderate thing than what you're accusing him of here.
You might not be aware of this, but it's possible to have a personal opinion about something and not bring societal and political discussions to the company account or forum. Here's the text of the new policy:
"People can take the conversations with willing co-workers to Signal, Whatsapp, or even a personal Basecamp account, but it can't happen where the work happens anymore."
Again, this is not at all the same thing as "no personal opinions [allowed] at Basecamp."
I'm on the pro-VC, anti-bootstrap spectrum and so is Elon Musk. American political spectrum of right vs left, authorarian vs libertarian makes little sense to me.
My political compass tends to be BRICS vs G7, religious vs secular. If you're saying they're both G7-secular, I guess that makes sense too.
edit: Also I was not even aware of Musk and the fascist thing before posting the comment, and I can see how it may have been interpreted differently now, lol.
I am the CTO of http://ridewithgps.com which is a rails monolith that is 18 years old now. We still have original code from 18 years ago in a few spots. I am pretty biased, but I would use it for a new project in a heartbeat. It's just so easy to be incredibly productive in.
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.
Yes Rails 8 is great. However, pick what the team knows best. For example at a startup doing AI/ML where everyone already knows Python and we're doing a lot with Pandas and Jupyter, we're choosing to build our website CMS by using Django & HTMX.
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.
Loco is awesome! Hoping that the openAPI generation comes soon - then I can generate zod schemas from the openAPI doc! It would be really cool to use something like hygen/plop or maybe tera (idk) to automatically generate svelte or react CRUD pages, similar to what loco is already doing for htmx.
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 :-)
I’m the CTO at OpsLevel, where we’ve been running a Rails monolith for ~6 years. We started on Rails 5, upgraded to 7, and are currently moving to 8. Before this, I worked on Rails at PagerDuty (including splitting a monolith into microservices) and on Shopify’s “majestic” monolith.
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.
>For most web apps, the bottleneck is I/O, not CPU.
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.
Yes, no question, assuming Rails matches what the startup is trying to do well enough. I've worked in other frameworks, stacks, etc and nothing beats the raw productivity of Rails for web applications.
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.
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.
I dont think that is even Rails Specific. Laravel or Django would have the same effect compared to starting from scratch with no frameworks, which is what the original questions asked.
I code both in Go and in Rails and that statement is true. Ruby on Rails is 5x/10x the productivity, and that's a very low multiplier, I believe it is higher depending on the kind of application you are building.
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.
I would highly recommend you give it a try. In my ~20 years of doing development professionally, I've never found anything that comes close to the productivity you get out of Rails on a new project (even if you're new to Ruby/Rails).
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.
The biggest risk when going with a long established solution is the potential danger of picking something that is on its way out of the zeitgeist. Not that picking your tech stack should be a popularity contest (and in fact many people make the wrong choice by chasing trends), but picking a component that has been left behind can have some real consequences (e.g. might become increasingly harder to find good talent for it).
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.
> The biggest risk when going with a long established solution is the potential danger of picking something that is on its way out of the zeitgeist.
I long established solutions are likely long established for a reason. And they are also likely protected by the interests of the companies already using them.
I think it's easy to eyeball if an older solution is still actively developed, RoR clearly is. Newer solutions can be very popular and active now, but die within just a few years. Just look at all the JavaScript frameworks we've gained and lost in just the last couple of years.
Alternatively, hire people because of their intrinsic competency and not because they check the "X years of experience in Rails" box. Hire people who can pick up new languages easily
It's always been a non-issue for me. However, when I do want to explore a new stack I generally go as a consultant or in a small startup i.e. not-well-funded. I'm more than willing to pay the price in wage for a few shorter-term engagements.
Ever since I'm a data analyst, I found that career happiness is more important than wages depending where someone is on the career happiness track. Software engineering is just a bit too much for me. Where I work now as a data a data analyst, keeps me sane. It's the diversity and variety of tasks that I like.
Yes, if you like it and use it. No if you prefer something else. Rails has a ton of stuff readily available with a base installation and a large community with deep knowledge. There are some cool new things that also came out recently that provide working defaults which allows a person or team to start working on biz requirements and stop futzing around with tech stacks.
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.
The renaissance is more about server based monoliths.
Suddenly everyone and their uncle realizes what a waste of time, money and brainpower those SPAs talking to a gazillion micro services managed by Kubernetes are for many if not most use cases.
David HH has done a couple great talks about this and he is right.
The concrete technology doesn't really matter and is more of a personal preference.
Once I found Ruby on Rails, I've never looked back. Simply put, no other framework I've worked with (in the Python and JS ecosystems, where I started out years ago), would come close in terms of speed - measured in the number of features as I can ship with Rails. It's just that good, and Ruby is an absolute joy to write.
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.
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
I’ve worked on several projects this past year, some with newer frameworks, others with no-code solutions like Bubble and I keep coming back to Rails. It strikes that perfect balance between speed and clarity, and so many of the features we’d otherwise code from scratch like admin panels, authentication, queuing, mailing are already there for you to pick.
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.
If you had asked me this question 15 years ago, I would've said never use Rails. I am a diehard python developer, with experience in Java, Go and C++.
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+.
People often say Rails is great for startups—perfect for prototyping and moving fast. That’s true, but for me, the real joy comes in maintaining Rails apps. Jumping into the production console, debugging issues, tweaking code on the fly—it’s so satisfying. Yes, it’s risky and you must know what you’re doing. But when done right, support is lightning fast.
I’m currently using Hotwire Native with a rails 8 app building a new project and I’m banging out features faster than anything I’ve used in the past. Furthermore so much can be done on the web side to prototype features on mobile with this setup.
Rails or Laravel, take your pick. Personally, I've been using Laravel + Filament. It's so fast to get up and running with & it doesn't hamstring you when you want to do anything more complex.
I would not. I've used PHP, Python, Go, JS/TS, and Ruby in production with small to medium teams. Teams that I managed on occasion and recruited, to a certain extent.
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.
Agreed that the metaprogramming can lead to some head-scratchers. However, in my experience with Rails/Ruby, that generally seems frowned up on most teams.
Readability is a core tenant in Ruby, but every once in a while someone likes to show how clever they are. No more a problem in Ruby than other languages IMO.
I disagree that there is a lack of good quality, well maintained libraries. Depending on the domain, I think most people would agree that Ruby and Rails has a pretty thriving 3rd party ecosystem. A big part of that is because of how mature both Ruby and Rails are.
> 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.
I think this is true. With Rails you want to be very deliberate about who you hire (there are lots of "Advanced Beginners" out there) and how you vet and manage abstractions outside of the MVC architecture. But if you can stick to those tenets, you'll be rewarded with a very productive engineering org.
> If you're doing AI stuff, any Python framework will be best.
I understand that AI stuff now is mainly Python. But is it possible to connect Rails with some Python program/service, is this one of the purpose of microservices?
Thank you for your reply. In your other comment, you mention that you know Ruby relatively well. Would you recommend learning Ruby along side with Rails (i.e., learning Ruby in/with Rails), if I have some experience with other languages, such as Java, Python, C/C++, Lisp, and so on?
Also are there any Ruby AI libraries that you would recommend? Thanks!
Yes, of course. One of the Ruby shops I worked for did exactly this.
But why add the extra complexity? Ruby and Python are similar enough in terms of productivity and processing time that there's no reason to do this IMHO.
Rails is pretty amazing to get started. Rails is definitely the gold standard when it comes to Get Shit Done fast. I think the Active Record model can lead to some technical debt down the road, but for getting started nothing is faster from a dev perspective.
All that being said these days I'd start with Elixir/Phoenix.
From my experience supporting Rails app longer than a month becoming more complex due to a lot of meta-magic (method_missing and friends, abused by rails itself). Elixir/Phoenix feels exactly like Rails with these issues fixed. Longest living production app is ~8 years now, doesn't feel like legacy at all. Upgrades are easy. Easy to figure out what's exactly happening right there.
Also, resource consumption/optimization. I noticed i need to do something about it on first week of development, which is sad (and spends dev time on non-relevant stuff). Phoenix designed to avoid it (including stupid stuff like N+1 problem)
I use node-ts. Why? I have access to every library I will need from any provider or for any task like phone number validation.
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.
Interesting as I currently work with 15 year old RoR database and a 2 years old Node project and every time I jump into the later I want to kill myself.
And I’m a mainly JS dev. Node is extremely easy to f up, so is the frontend. And with all the generated code today… it’s gonna get only worse.
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.
> 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.
I feel like this is one of the mistakes that many developers make, and it's achieving a kind of wisdom to eventually realize it -- that optimizing for DRY above all else creates a mess.
I've definitely seen this done in many languages, but I've been mostly using ruby so much these days that I can't actually compare. Do any people who do have deep experience on multiple platforms (these people are few and far between) find this problem is worse in ruby than other places? Maybe it's that ruby gives you tools such that when you do optimize for DRY abstraction above all else you create a bigger mess, compared to other platforms?
> 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.
I think that was definitely the case some years ago, but the Ruby community has matured since then. Meta programming is a bit looked down upon, these days.
Oh yeah totally. Our linter definitely discourages it.
I still see a false equivalency in the ruby community that verbosity == complexity, that tends to make super complex abstractions and DSLs in order to make the consumption less verbose, that then say “see how simple this is to use”
Because rails does such a good job in their DSL, I think I understand why that tendency exists. But rails under the hood is quite complex, and most DSLs are no where near as well thought out.
Maybe I have Stockholm syndrome, because I hated ruby coming from a nearly all c style language background at first, but I honestly think it is pretty cool now. I think a lot of issues come from people wanting to do things in ruby like they would in C# or Java.
I am in technical diligence so I talk to companies going from start up to mid stage all the time (ie when they get bought or are getting a big investment). I've been doing it for six years now. My personal anecdotal observation is that companies now tell me it is much harder to hire for Ruby than for Python or Node back ends, for what that's worth.
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.
I've found Rails over the last few versions to be very easy to upgrade.
Where I've had problems it's been 3rd party libraries that try to force alternatives to core behaviour like ActiveModel but then break their own API a year down the line.
cough Looking at you Dry::Validation.
You just do things like sticking to POROs for business logic it's pretty smooth.
I just follow the advice in the Sustainable Rails book.
Yeah, that's why I said I have no idea why that is. I'm sure it's not caused by Rails but rather some kind of secondary associative reason. (ie, rails devs leave and they have a hard time replacing with seniors or something). Coming from a Python background I find it weird. But it's definitely a thing.
It really depends on the project size and amount of dependencies. Ruby is very flexible, so dependencies can make a huge mess. Vanilla Rails doesn’t have those issues.
In my case, I had some epiphany when I started reading essays by Paul Graham and Getting Real by Basecamp (well, this one is special in the context of RoR, of course).
I have always been very protective of Go and its minimalism, no huge frameworks like Django/RoR/Laravel (well, there are a few, but they aren't that popular or mainstream since the Go community favors just using the standard library).
However, the more I read about startups and prototyping, the more I think that spending time on boilerplate, writing custom migration scripts, and implementing database-backed job queues every single time is not what you want to spend your time on when you want to iterate as quickly as possible.
Also, another minor factor in favor of Ruby is the talks on destroyallsoftware such as "Functional core, imperative shell" and "Boundaries" where the author uses and seems to really like the language :)
On top of that, learning a new language/framework is always fun so I have already starting playing around with the official RoR guide.
I've actually just did exactly that a few weeks ago.
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.
Yes, it has everything (+ lots of packages/gems because of Ruby) and you'll likely be able to write a Web App / API much faster than in Go or any other language.
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.
Most definitely! I've been writing a small generative AI application the last few months as a side project and have been consistently impressed with how well it works in this context. Plus since there's so much writing on RoR on the Internet, it makes it really easy to program with Cursor or Github Copilot. Great choice all around. I recently wrote up some examples of how great it works with things like Web Sockets here: https://blog.spellbooks.ai/posts/move-over-spas-rails-is-bro...
I’d be mostly worried about the hiring problems. It’s not in vogue right now and it might be increasingly difficult to locate engineers who are knowledgable or want to work in such a stack.
As a solo founder, I don't think I could have the same velocity without Rails. I can ship features and fixes with less code and in less time than any other framework I've tried. I think the only other competitor to Rails for small teams is Laravel. Both are fantastic, batteries-included frameworks. Rails is boring, and that's good.
Can't be answered with no other information (People available for hire for your area / company in RoR), your previous experience etc. but as another Go developer that jumped on RoR for my side projects a few years ago I can only encourage you. It brings the fun back into getting something running quickly without having to implement every crud operation manually.
It's still good but that does not mean you should choose it.
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.
Absolutely. I’ve been using rails for almost 20 years, and it’s been mostly a joy to watch it evolve. I will say- there was a short period of time (the webpacker era) where it was losing its allure, but that already feels like a distant memory. For the last decade that I’ve been doing freelance/contract development, I’ve always been able to find plenty of Rails/Ruby work, so it still feels like a valuable thing to specialize in as well. And the Ruby community is just incredible. Rails motto should be “come for the productivity, stay for the community”.
If you're like me and moved off from Ruby to Rust as your go-to-everything, try Loco which tries to be a faithful Rails on Rust (loco.rs). It has the magical scaffold, the smooth experience, and the features you'd expect from Rails including authentication built in (like Devise).
Sorry, not answering your question but asking one: Couldn't you add libs to Go to cover what active record and active job do ? Genuine question, as a Django guy lurking around Go for web apps.
Yes, absolutely. I am just working on a new one built on my template Business Class which stays very close to Rails defaults. I really like all the 'small' things that aren't actually small like Action Text, Active Job, Turbo. And I deploy with Kamal too, ofc.
There is a large base of competent Rails practitioners.
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.
I just opened the official starting guide from the official RoR website and am very excited, to be honest.
I mean, the Go way of as few dependencies as possible and no opinionated frameworks is cool, but getting so much done for you is such a nice thing when you want to build fast. Also, switching to a purely REST API with just render json: <blah> is unbelievably fast. Writing the same in Go would include a lot of boilerplate.
Anyway, thanks for your response. I am really happy for Ruby, RoR, and the community.
the Go way of as few dependencies as possible and no opinionated frameworks
That is highly opinionated and the opinion is based on Google’s business model, resources, operational strategies and engineering wherewithal. No startup has anything like any of them.
For most, yes. Startups fail because they run out of money, not because the code runs slower. You need a mix of technology that lets you iterate fast, and cheap. Of course, I feel like there's a number of options that fit into that same bucket, and I'd consider Django among those.
I started a project with it. Just the backend mind.
Reasons, speed to get up and running. Familiarity with its pros and cons.
Also familiar with rspec and actually enjoy writing rspec.
Honestly, and it’s a meme at this point, I think it’s the best choice. Nothing to so with how much I like it. You can just get things done SO quickly. And with the focus on convention, that first attempt is an awful lot better than in other frameworks. You really can get done in a few hours what has previously taken days. I don’t think it’s entirely coincidence that a pretty big proportion of the biggest winners of the 2000-10s internet gold rush either started out with (and a lot still are using) Rails. If you’re more agile with a smaller team, it’s a benefit to any business. The scale argument is overblown, but also fewer devs being more productive is much more important than relatively minor increases in infrastructure cost
Rails is a battle tested choice. Nothing wrong with it.
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.
No. As a Django dev I spend 6 months on a RoR project, and by far it was the least productive time of my 8 year career in web development. I understand why people like it, but coming from Django; u could never imagine being a part of a RoR stack again.
Yes absolutely, although I don't see anything wrong with sticking to Go either if you know and like it.
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?
I’ve built my career on Rails. I first got paid to write Rails code in 2008, then came back to it in 2015 and have worked in it almost nonstop since then.
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.
Sure, whatever you're comfortable with. On a startup, failure risk is high, choose something boring that's easy to hire for and most of all, you're comfortable with.
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.
"Still" implies that one would have chosen it before.
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!
Absolutely not. DHH is problematic and the foundation doesn't seem to really have a voice beyond his. The technology is great, but the community does have a problem with leadership - and not having a leadership team own the branding and communication is problematic long term. Yes, there have been many changes recently but it's only been because DHH approves of it - it's not really consensus driven by different experiences using Ruby on Rails.
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.
No.
However, Rails addresses many items on The List.
Hence, it's worth using it as a checklist.
In reality, things like cache-busting codes are pretty straightforward to write in <language of your choice> and choices about how to represent database entities and validate incoming data require contextual and experiential validation, one size (ActiveRecord) truly doesn't fit all.
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
I'm building a trial balloon in Crystal right now, though not Amber or Lucky. They had their 1.0 release (1.15, even), but it does not feel ready for production. The documentation is not great, the gotchas are unintuitive, and the discussion feels like they're not sure what direction to take the language. The runtime (event loop, fiber scheduler, and garbage collector) dependency means there's plenty of "magic" involved, making it feel significantly more like a framework than a language. Maybe that makes sense if they're targeting the web. If you're on the fence about choosing an established framework like Rails, though, Crystal is not the direction to go yet.
Modern React is a "full-stack" framework - with the current recommended implementation being NextJS.
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
I hate to break this to you, but typescript ain't type-safe. There's a lot I like about typescript, but your runtime is still node, so any "type-safety" is mostly illusory. Not to mention every typescript codebase I've ever looked at includes a copious amount of Any, so...there's that.
Also, typescript has OOP support for a reason -- lots of typescript codebases make copious use of classes. Javascript tried to remain mostly functional for a long time, and people kept trying to make class-based OOP, so, they added it.
Finally, React is not a full-stack framework -- it's a framework for generating UIs. It has recently added support for server-side rendering, and NextJS has added support for that, but Rails and NextJS are very different. Rails is batteries included, NextJS is bring your own [everything] that happens on the server.
YMMV/to each their own/etc etc etc, but referring Rails as "fundamentally unserious" (github, stripe, shopify, i could go on) reflects the opinion of someone who either has an axe to grind with ruby/rails, or is willfully ignorant of it's capability.
It seems that people who use Visual Studio Code expect LSP to exist for every language for some reason, then blame the language itself when it doesn't, as this commenter did. It's strange to me. It isn't that the language doesn't support VSCode, the problem is that VSCode doesn't support the language. VSCode is the bad thing, not the language.
> elite engineers will not want to work for you
Engineers who care more about the specific web technology being used rather than solving the problem don't sound like "elite" engineers.
Your comment is profoundly ignorant. The Language Server Protocol is a standard across all modern editors. It's the reason for the resurgence of Neovim. It is absolutely the responsibility of the language to provide a language server.
> Engineers who care more about the specific web technology being used rather than solving the problem don't sound like "elite" engineers.
Enlighten me, elite engineer. Why does liking NextJS make you elite?
> standard across all modern editors
This is incorrect. It is Microsoft's open standard that _some_ modern editors have chosen to implement. For example, JetBrains IDEs & Sublime text have no native support, only limited support only through extensions/plugins.
> It is absolutely the responsibility of the language to provide a language server.
Again, this is an extremely recent standard, 2016, that services some text editors. This is not something foundational for all language authors.
My main point is: If your editor experience is bad when using Ruby, then your editor is bad for Ruby. Regardless of if your editor uses LSP or something else. The language itself is not at fault.
The statement that Rails is an "unserious" framework is not true. There are many multi-million/billion dollar companies built with Rails: Shopify, GitHub, Chime, Gusto, GitLab, and Basecamp/Hey, to name a few.
> Object-Oriented-Programming is a failed paradigm for modern web development
This seems to me more like an opinion based on personal flavors than an industry statement.
There is no clear winner between OOP and FP. Both are fine and models (thus a bit far away from reality) of an outside world that has a fair part of randomness and increasing complexity. Moreso more languages are implementing properties from the other paradigm.
Also if you think FP is modern you are mistaken. FP is at least as old as OOP if not a bit older. Take a look at when LISP was released and when the first OOP language was released.
Yes, I would. In fact, I'd use any boring technology [0]. Anything that's been around and battle tested.
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
Rails (and its ecosystem) is anything but boring with Turbo/Hotwire, StimulusJS, a shift away from queues using Redis to the database w/ Solid Queue, a reexamination of how SQLite can be used as a prod database (when tuned), and a new rich text editor on the way…
Some of these are eyebrow raising and certainly not boring!
Shifting to solid queue, backed by your rdbms, is more boring than using redis. Successfully deploying an app without anything but a database server is pretty powerful. Everything just works. I would say that's pretty boring :)
> Everything just works.
I long to live in your world where this is the case!
Unfortunately the migration from Sidekiq + Redis → Solid Queue has been anything but boring.
I started fresh from Rails 8, so maybe that's why I didn't deal w/ that migration problem. I'm sorry it was stressful :(
We're about to do this as well, but from resque. Got any tips to share?
TBH we backed out of it as we didn't need to make the change now.
Would love to read about it if you have a write up of the problem you encountered.
He meant that it's been around for a while and is relatively stable. Not that it's literally boring.
I think they are launching a markdown editor, not rich text
Is it boring technology? I'm actually reluctant to pick up Rails because it had always been sold by the Basecamp cult and Jason Fried gives off Musk vibes.
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 this depends on the context. I would argue that opinionated frameworks are *more* reliable, with the caveat that you need to know, and agree with those opinions.
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.
For context, I've been in mobile for 10 years and in general it's the opposite - frameworks are rigid, but the layer under it shifts a lot. These frameworks tend to collapse in an earthquake like manner after multiple updates. We usually support iOS up to 2-3 years old, that's how bad it is.
The other approach is to build it on a platform that shifts with the changes, i.e. hybrid and web. But if you crack open the source of Cordova, you find all kinds of tangled, unmaintained, bad practice wiring and rewiring. I spent a few months trying to hack Cordova plugins and we decided to just scrap the entire code and build native; fully rewriting the app into a custom framework took 3 months.
However, it sounds like tools like Rails are built on a very sturdy platform that doesn't introduce breaking changes every year? That's an angle I haven't considered.
I listened to the latest Rails keynote, I never have before. I don't recall the exact details but it was a bit of a weird vibe for me.
> 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.
>it had always been sold by the Basecamp cult and Jason Fried gives off Musk vibes.
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.
I definitely recommend using Ruby, and Rails.
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.
>The Jason Fried and David Hansson Musk/Fascist vibes are real and are a problem.
What do you mean by this? Where have Jason Fried or David Hansson supported fascism? Your account is ten years old and this is the first comment you've ever made.
It doesn't mean I'm not right.
I mean that they give off Fascist vibes, and that it's a problem. Adoration for and support of fascist people and regimes are implicit support of fascism. Not explicit.
Go read their blogs, I'm sure you'll find lots of examples.
>I mean that they give off Fascist vibes, and that it's a problem
But you've just repeated the accusation and said that you think it's a problem. You haven't provided proof of any actual fascism.
I disagree that DHH is a fascist, I do agree he gives off Musk vibes e.g.
https://world.hey.com/dhh/mega-a0f62cd4 "so pumped up about Trump"
https://world.hey.com/dhh/failed-integration-and-the-fall-of... "multiculturalism is bad"
https://world.hey.com/dhh/the-social-media-censorship-era-is... "hooray for lack of fact checking"
(you may agree with him or not, and he makes better argument than Musk, but it's the same vibe)
>It doesn't mean I'm not right.
It doesn't mean you're not wrong. Is this a personal vendetta?
>I mean that they give off Fascist vibes, and that it's a problem. Adoration for and support of fascist people and regimes are implicit support of fascism.
Where? Link examples where they supported Fascism. "Vibes" are meaningless, I need specific examples of these claims, else they can be tossed outright.
>Go read their blogs, I'm sure you'll find lots of examples.
Didn't find anything about supporting Fascism.
I'm not interested in prosecuting that David gives off fascist vibes. I don't have to provide proof. Kinda lazy that you're all not out there looking for the proof yourself.
To reorient the discussion around what the original poster talked about, that he gives off Elon Musk Vibes. And that it's a problem. Well it IS a problem. A problem openly, and vigorously discussed in the Ruby community.
Many people have left the Ruby community because of his behavior, and many more have chosen never to come into the community because of it. Because of the perceived strong association between him and the Ruby and Rails community at large.
Anyways, as per my original point, that despite the Fascist vibes from that guy, Ruby and Rails are still really great choices.
The worst part about Rails is the 37signals people, in particular DHH.
But the good news is that you can just ignore them and enjoy the framework, like I do.
>The worst part about Rails is the 37signals people, in particular DHH.
Why? What is wrong with DHH?
Some people love him, some hate him.
It's also possible to appreciate the stuff he's done for software whilst not being in love with him as a person.
The good news is that I can just say: go ahead and Google “DHH blog”, read his most recent few blog posts and form your own opinions.
I’ve had a negative opinion of him for a good five years or so, but at least right now it’s easy to go read those and form your own strong opinion one way or another.
I use and love using rails, but the centrality of influence of the musk-vibes-camp is for me too the biggest downside. Yes in response to a sibling comment, the RailsWorld keynote was super weird culty vibe, agreed. But hey everything's got ups and downs. Rails is great for me to work in. Hopefully it will remain that way. There are other Rails maintainers who are not basecamp-related, some who say that dhh and basecamp's power over Rails is not as great as people think and it really is distributed maintainership and control, hopefully that is true enough and will remain so.
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.
>I'm actually reluctant to pick up Rails because it had always been sold by the Basecamp cult and Jason Fried gives off Musk vibes.
Why? What "Musk vibes" have they given off?
Success because of A and attributing it to B. There's a bit of megalomania too. He has a beef against VC funding. He lost 1/3 of staff once when he implemented a policy of no personal opinions at Basecamp. He is often shared because of his unpopular opinions and his successes are used to fortify those opinions.
I'm not saying Fried or Musk are wrong, and they both have brilliant insights at times. If Musk was crazy and wrong all the time, he wouldn't be a brand name.
But both of them also appeal to susceptible people who seem to think that a few good opinions make them good all the time. Basecamp isn't even a good tool, it's a pretty average one, yet prettier than Jira. But it's down this funnel of people who will buy whatever Fried and DHH sell them.
And what I'm getting at is whether Rails is one of those things that is average but prettier than Node?
>he implemented a policy of no personal opinions at Basecamp
Except he didn't do that, what he implemented was not making personal politics a part of Basecamp's workplace culture, which is a much more moderate thing than what you're accusing him of here.
You might not be aware of this, but it's possible to have a personal opinion about something and not bring societal and political discussions to the company account or forum. Here's the text of the new policy:
https://world.hey.com/jason/changes-at-basecamp-7f32afc5
"People can take the conversations with willing co-workers to Signal, Whatsapp, or even a personal Basecamp account, but it can't happen where the work happens anymore."
Again, this is not at all the same thing as "no personal opinions [allowed] at Basecamp."
If you are on certain political spectrum, then opposite political spectrum would certainly gives similar vibes as that spectrum's prominent figure.
I'm on the pro-VC, anti-bootstrap spectrum and so is Elon Musk. American political spectrum of right vs left, authorarian vs libertarian makes little sense to me.
My political compass tends to be BRICS vs G7, religious vs secular. If you're saying they're both G7-secular, I guess that makes sense too.
edit: Also I was not even aware of Musk and the fascist thing before posting the comment, and I can see how it may have been interpreted differently now, lol.
I am the CTO of http://ridewithgps.com which is a rails monolith that is 18 years old now. We still have original code from 18 years ago in a few spots. I am pretty biased, but I would use it for a new project in a heartbeat. It's just so easy to be incredibly productive in.
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.
Yes Rails 8 is great. However, pick what the team knows best. For example at a startup doing AI/ML where everyone already knows Python and we're doing a lot with Pandas and Jupyter, we're choosing to build our website CMS by using Django & HTMX.
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.
Loco is awesome! Hoping that the openAPI generation comes soon - then I can generate zod schemas from the openAPI doc! It would be really cool to use something like hygen/plop or maybe tera (idk) to automatically generate svelte or react CRUD pages, similar to what loco is already doing for htmx.
Loco author here.
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 :-)
I’m the CTO at OpsLevel, where we’ve been running a Rails monolith for ~6 years. We started on Rails 5, upgraded to 7, and are currently moving to 8. Before this, I worked on Rails at PagerDuty (including splitting a monolith into microservices) and on Shopify’s “majestic” monolith.
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.
>For most web apps, the bottleneck is I/O, not CPU.
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.
Yes, no question, assuming Rails matches what the startup is trying to do well enough. I've worked in other frameworks, stacks, etc and nothing beats the raw productivity of Rails for web applications.
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.
>Is Rails still that good?
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.
>> However Your development speed may likely be 5 to 10x.
Rubbish.
This is just fanboi talk that all rails developers tell each other without a shred of science.
I dont think that is even Rails Specific. Laravel or Django would have the same effect compared to starting from scratch with no frameworks, which is what the original questions asked.
Agreed. So much messing around with Go reinventing the basics that these frameworks provide for free. Plus no waiting for compilation.
I code both in Go and in Rails and that statement is true. Ruby on Rails is 5x/10x the productivity, and that's a very low multiplier, I believe it is higher depending on the kind of application you are building.
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.
I would highly recommend you give it a try. In my ~20 years of doing development professionally, I've never found anything that comes close to the productivity you get out of Rails on a new project (even if you're new to Ruby/Rails).
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.
The biggest risk when going with a long established solution is the potential danger of picking something that is on its way out of the zeitgeist. Not that picking your tech stack should be a popularity contest (and in fact many people make the wrong choice by chasing trends), but picking a component that has been left behind can have some real consequences (e.g. might become increasingly harder to find good talent for it).
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.
> The biggest risk when going with a long established solution is the potential danger of picking something that is on its way out of the zeitgeist.
I long established solutions are likely long established for a reason. And they are also likely protected by the interests of the companies already using them.
I think it's easy to eyeball if an older solution is still actively developed, RoR clearly is. Newer solutions can be very popular and active now, but die within just a few years. Just look at all the JavaScript frameworks we've gained and lost in just the last couple of years.
Alternatively, hire people because of their intrinsic competency and not because they check the "X years of experience in Rails" box. Hire people who can pick up new languages easily
Most companies don't do that in my experience. It'd have been easier to get hired over the years if they did.
It's always been a non-issue for me. However, when I do want to explore a new stack I generally go as a consultant or in a small startup i.e. not-well-funded. I'm more than willing to pay the price in wage for a few shorter-term engagements.
Ever since I'm a data analyst, I found that career happiness is more important than wages depending where someone is on the career happiness track. Software engineering is just a bit too much for me. Where I work now as a data a data analyst, keeps me sane. It's the diversity and variety of tasks that I like.
Yes, if you like it and use it. No if you prefer something else. Rails has a ton of stuff readily available with a base installation and a large community with deep knowledge. There are some cool new things that also came out recently that provide working defaults which allows a person or team to start working on biz requirements and stop futzing around with tech stacks.
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.
The renaissance is more about server based monoliths. Suddenly everyone and their uncle realizes what a waste of time, money and brainpower those SPAs talking to a gazillion micro services managed by Kubernetes are for many if not most use cases. David HH has done a couple great talks about this and he is right. The concrete technology doesn't really matter and is more of a personal preference.
Once I found Ruby on Rails, I've never looked back. Simply put, no other framework I've worked with (in the Python and JS ecosystems, where I started out years ago), would come close in terms of speed - measured in the number of features as I can ship with Rails. It's just that good, and Ruby is an absolute joy to write.
Obviously it depends on what you're doing.
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.
It depends.
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
I’ve worked on several projects this past year, some with newer frameworks, others with no-code solutions like Bubble and I keep coming back to Rails. It strikes that perfect balance between speed and clarity, and so many of the features we’d otherwise code from scratch like admin panels, authentication, queuing, mailing are already there for you to pick.
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.
If you had asked me this question 15 years ago, I would've said never use Rails. I am a diehard python developer, with experience in Java, Go and C++.
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+.
People often say Rails is great for startups—perfect for prototyping and moving fast. That’s true, but for me, the real joy comes in maintaining Rails apps. Jumping into the production console, debugging issues, tweaking code on the fly—it’s so satisfying. Yes, it’s risky and you must know what you’re doing. But when done right, support is lightning fast.
Changing production code on the fly? So testing/qa is done on production? Uh, no thank you.
It’s the real joy. Especially when you do those things on Friday’s evening.
I’m currently using Hotwire Native with a rails 8 app building a new project and I’m banging out features faster than anything I’ve used in the past. Furthermore so much can be done on the web side to prototype features on mobile with this setup.
Rails all the way for me!
Rails or Laravel, take your pick. Personally, I've been using Laravel + Filament. It's so fast to get up and running with & it doesn't hamstring you when you want to do anything more complex.
I would not. I've used PHP, Python, Go, JS/TS, and Ruby in production with small to medium teams. Teams that I managed on occasion and recruited, to a certain extent.
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.
Agreed that the metaprogramming can lead to some head-scratchers. However, in my experience with Rails/Ruby, that generally seems frowned up on most teams.
Readability is a core tenant in Ruby, but every once in a while someone likes to show how clever they are. No more a problem in Ruby than other languages IMO.
I disagree that there is a lack of good quality, well maintained libraries. Depending on the domain, I think most people would agree that Ruby and Rails has a pretty thriving 3rd party ecosystem. A big part of that is because of how mature both Ruby and Rails are.
> 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.
I think this is true. With Rails you want to be very deliberate about who you hire (there are lots of "Advanced Beginners" out there) and how you vet and manage abstractions outside of the MVC architecture. But if you can stick to those tenets, you'll be rewarded with a very productive engineering org.
> If you're doing AI stuff, any Python framework will be best.
I understand that AI stuff now is mainly Python. But is it possible to connect Rails with some Python program/service, is this one of the purpose of microservices?
I work for a company that uses Rails. We don't have any Python code, but we use a lot of AI.
Thank you for your reply. In your other comment, you mention that you know Ruby relatively well. Would you recommend learning Ruby along side with Rails (i.e., learning Ruby in/with Rails), if I have some experience with other languages, such as Java, Python, C/C++, Lisp, and so on?
Also are there any Ruby AI libraries that you would recommend? Thanks!
Yes, of course. One of the Ruby shops I worked for did exactly this.
But why add the extra complexity? Ruby and Python are similar enough in terms of productivity and processing time that there's no reason to do this IMHO.
> If you need to hire a sizeable team quickly, I would reach for Node or PHP.
I always wonder about this. Surely the technology you pick influences the size of the team.
There is definitely some link to the technology and developer productivity, and therefore team size.
It's true that statically typed, compiled languages tend to take more time to ship a similar feature, than loosely typed dynamic languages.
But beyond small projects, team size is more dependent on the number of features to ship.
That is to say, as code complexity increases, the choice of language on team size matters less.
shopify, airbnb, github, hulu ....managed to make it work
That's not what I'm saying.
Rails is pretty amazing to get started. Rails is definitely the gold standard when it comes to Get Shit Done fast. I think the Active Record model can lead to some technical debt down the road, but for getting started nothing is faster from a dev perspective.
All that being said these days I'd start with Elixir/Phoenix.
From my experience supporting Rails app longer than a month becoming more complex due to a lot of meta-magic (method_missing and friends, abused by rails itself). Elixir/Phoenix feels exactly like Rails with these issues fixed. Longest living production app is ~8 years now, doesn't feel like legacy at all. Upgrades are easy. Easy to figure out what's exactly happening right there.
Also, resource consumption/optimization. I noticed i need to do something about it on first week of development, which is sad (and spends dev time on non-relevant stuff). Phoenix designed to avoid it (including stupid stuff like N+1 problem)
I use node-ts. Why? I have access to every library I will need from any provider or for any task like phone number validation.
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.
Interesting as I currently work with 15 year old RoR database and a 2 years old Node project and every time I jump into the later I want to kill myself.
And I’m a mainly JS dev. Node is extremely easy to f up, so is the frontend. And with all the generated code today… it’s gonna get only worse.
> I found it way too messy and complicated, and our codebase was awful.
Are you saying that’s because RoR was used? Doesn’t seem plausible. Messy bad code is the fault of the programmer, not the language/framework
I have a love hate relationship with rails.
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.
> 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.
I feel like this is one of the mistakes that many developers make, and it's achieving a kind of wisdom to eventually realize it -- that optimizing for DRY above all else creates a mess.
I've definitely seen this done in many languages, but I've been mostly using ruby so much these days that I can't actually compare. Do any people who do have deep experience on multiple platforms (these people are few and far between) find this problem is worse in ruby than other places? Maybe it's that ruby gives you tools such that when you do optimize for DRY abstraction above all else you create a bigger mess, compared to other platforms?
> 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.
I think that was definitely the case some years ago, but the Ruby community has matured since then. Meta programming is a bit looked down upon, these days.
Oh yeah totally. Our linter definitely discourages it.
I still see a false equivalency in the ruby community that verbosity == complexity, that tends to make super complex abstractions and DSLs in order to make the consumption less verbose, that then say “see how simple this is to use”
Because rails does such a good job in their DSL, I think I understand why that tendency exists. But rails under the hood is quite complex, and most DSLs are no where near as well thought out.
Maybe I have Stockholm syndrome, because I hated ruby coming from a nearly all c style language background at first, but I honestly think it is pretty cool now. I think a lot of issues come from people wanting to do things in ruby like they would in C# or Java.
I am in technical diligence so I talk to companies going from start up to mid stage all the time (ie when they get bought or are getting a big investment). I've been doing it for six years now. My personal anecdotal observation is that companies now tell me it is much harder to hire for Ruby than for Python or Node back ends, for what that's worth.
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.
I've found Rails over the last few versions to be very easy to upgrade.
Where I've had problems it's been 3rd party libraries that try to force alternatives to core behaviour like ActiveModel but then break their own API a year down the line.
cough Looking at you Dry::Validation.
You just do things like sticking to POROs for business logic it's pretty smooth. I just follow the advice in the Sustainable Rails book.
https://sustainable-rails.com/
Yeah, that's why I said I have no idea why that is. I'm sure it's not caused by Rails but rather some kind of secondary associative reason. (ie, rails devs leave and they have a hard time replacing with seniors or something). Coming from a Python background I find it weird. But it's definitely a thing.
It really depends on the project size and amount of dependencies. Ruby is very flexible, so dependencies can make a huge mess. Vanilla Rails doesn’t have those issues.
Yes Rails is still good and IMHO Rails is still an amazing choice for a startup allowing you to do rapid iterations and focus on business logic.
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.
In my case, I had some epiphany when I started reading essays by Paul Graham and Getting Real by Basecamp (well, this one is special in the context of RoR, of course).
I have always been very protective of Go and its minimalism, no huge frameworks like Django/RoR/Laravel (well, there are a few, but they aren't that popular or mainstream since the Go community favors just using the standard library).
However, the more I read about startups and prototyping, the more I think that spending time on boilerplate, writing custom migration scripts, and implementing database-backed job queues every single time is not what you want to spend your time on when you want to iterate as quickly as possible.
Also, another minor factor in favor of Ruby is the talks on destroyallsoftware such as "Functional core, imperative shell" and "Boundaries" where the author uses and seems to really like the language :)
On top of that, learning a new language/framework is always fun so I have already starting playing around with the official RoR guide.
I've actually just did exactly that a few weeks ago.
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.
It's a no brainer for me. I prioritize my happiness above all else right now and Ruby with Rails is just joy.
Yes, it has everything (+ lots of packages/gems because of Ruby) and you'll likely be able to write a Web App / API much faster than in Go or any other language.
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.
Rails is pretty good - built my current business on Rails, building a new one on Rails as well.
In fact, I switched to Rails from Django because the latter was lacking.
What was it lacking?
Most definitely! I've been writing a small generative AI application the last few months as a side project and have been consistently impressed with how well it works in this context. Plus since there's so much writing on RoR on the Internet, it makes it really easy to program with Cursor or Github Copilot. Great choice all around. I recently wrote up some examples of how great it works with things like Web Sockets here: https://blog.spellbooks.ai/posts/move-over-spas-rails-is-bro...
I’d be mostly worried about the hiring problems. It’s not in vogue right now and it might be increasingly difficult to locate engineers who are knowledgable or want to work in such a stack.
I wouldn't because it is difficult to recruit and find developers for it.
As a solo founder, I don't think I could have the same velocity without Rails. I can ship features and fixes with less code and in less time than any other framework I've tried. I think the only other competitor to Rails for small teams is Laravel. Both are fantastic, batteries-included frameworks. Rails is boring, and that's good.
Can't be answered with no other information (People available for hire for your area / company in RoR), your previous experience etc. but as another Go developer that jumped on RoR for my side projects a few years ago I can only encourage you. It brings the fun back into getting something running quickly without having to implement every crud operation manually.
It's still good but that does not mean you should choose it.
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.
I am the CTO of https://www.leexi.ai/ which is powered by a Rails API (Vue/Nuxt in the frontend).
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.
Absolutely. I’ve been using rails for almost 20 years, and it’s been mostly a joy to watch it evolve. I will say- there was a short period of time (the webpacker era) where it was losing its allure, but that already feels like a distant memory. For the last decade that I’ve been doing freelance/contract development, I’ve always been able to find plenty of Rails/Ruby work, so it still feels like a valuable thing to specialize in as well. And the Ruby community is just incredible. Rails motto should be “come for the productivity, stay for the community”.
If you're like me and moved off from Ruby to Rust as your go-to-everything, try Loco which tries to be a faithful Rails on Rust (loco.rs). It has the magical scaffold, the smooth experience, and the features you'd expect from Rails including authentication built in (like Devise).
Disclaimer: I'm one of the authors of Loco.
Rails had always been and still is the best tool for its goal. Nobody comes close (despite a lot of surface level similarities).
It’s like rails is an iphone - others are androids at best.
Within its niche of course.
Sorry, not answering your question but asking one: Couldn't you add libs to Go to cover what active record and active job do ? Genuine question, as a Django guy lurking around Go for web apps.
i would, especially if there is mobile ui on horizon (hotwire)
+ 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.
Yes, absolutely. I am just working on a new one built on my template Business Class which stays very close to Rails defaults. I really like all the 'small' things that aren't actually small like Action Text, Active Job, Turbo. And I deploy with Kamal too, ofc.
There is a large base of competent Rails practitioners.
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.
I just opened the official starting guide from the official RoR website and am very excited, to be honest.
I mean, the Go way of as few dependencies as possible and no opinionated frameworks is cool, but getting so much done for you is such a nice thing when you want to build fast. Also, switching to a purely REST API with just render json: <blah> is unbelievably fast. Writing the same in Go would include a lot of boilerplate.
Anyway, thanks for your response. I am really happy for Ruby, RoR, and the community.
Congratulations on starting!
the Go way of as few dependencies as possible and no opinionated frameworks
That is highly opinionated and the opinion is based on Google’s business model, resources, operational strategies and engineering wherewithal. No startup has anything like any of them.
> Writing the same in Go would include a lot of boilerplate.
Yes, it would be very hard for LLM to write this boilerplate.
It’s so long it would not fit in its limited context brain ;)
still you have to maintain the pile of boilerplate code and whoever does it, has a very narrow context window (aka human)
I've worked on numerous Rails projects since 2010, and it has lots of strengths, but I would really hesitate to base a new project on Rails.
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.
Yes, for startup it is a great choice.
For most, yes. Startups fail because they run out of money, not because the code runs slower. You need a mix of technology that lets you iterate fast, and cheap. Of course, I feel like there's a number of options that fit into that same bucket, and I'd consider Django among those.
> That said, Active Record and Active Job seem to do exactly what I write manually over and over again in Go
There goes your answer. Golang was made for Google to simply - onboard junior engineers quickly. It wasn't made to make products quickly.
I started a project with it. Just the backend mind. Reasons, speed to get up and running. Familiarity with its pros and cons. Also familiar with rspec and actually enjoy writing rspec.
Honestly, and it’s a meme at this point, I think it’s the best choice. Nothing to so with how much I like it. You can just get things done SO quickly. And with the focus on convention, that first attempt is an awful lot better than in other frameworks. You really can get done in a few hours what has previously taken days. I don’t think it’s entirely coincidence that a pretty big proportion of the biggest winners of the 2000-10s internet gold rush either started out with (and a lot still are using) Rails. If you’re more agile with a smaller team, it’s a benefit to any business. The scale argument is overblown, but also fewer devs being more productive is much more important than relatively minor increases in infrastructure cost
What are your actual goals.
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
It depends on the problem the startup is aiming to solve. E.g, I am pretty sure that Go is much better for building infrastructure products than Ruby.
Yes. It does a lot for you and you can add features and explore ideas quickly. The batteries are included.
I do know Ruby well though.
Yes and I would also take a look at Laravel.
Yes Rails is still a very good choice in 2025 and don't listen to anyone telling you it doesn't scale.
Rails is a battle tested choice. Nothing wrong with it.
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.
Most definitely, it is the fastest path to an MVP for a proof of concept.
Sure thing, my fav stack ror api + anything for front end.
No. As a Django dev I spend 6 months on a RoR project, and by far it was the least productive time of my 8 year career in web development. I understand why people like it, but coming from Django; u could never imagine being a part of a RoR stack again.
Yup left my java enterprise job to switch back to ruby on rails
Yes, no doubt. Nothing comes close.
Yes absolutely, although I don't see anything wrong with sticking to Go either if you know and like it.
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?
Yes, absolutely.
of course I will.
Magic's just science that we don't understand yet.
Yes, definitely.
I’ve built my career on Rails. I first got paid to write Rails code in 2008, then came back to it in 2015 and have worked in it almost nonstop since then.
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.
Personally I would use .Net
Yes.
Write go and plain SQL at the back end.
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.
Sure, whatever you're comfortable with. On a startup, failure risk is high, choose something boring that's easy to hire for and most of all, you're comfortable with.
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.
No, I use Next.JS. Never used Ruby on Rails, I don’t see why I would now.
How about rails vs Django, are they similar in stability and performance?
"Still" implies that one would have chosen it before.
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...
Yeah I recently spun up a rails project
Absolutely not. DHH is problematic and the foundation doesn't seem to really have a voice beyond his. The technology is great, but the community does have a problem with leadership - and not having a leadership team own the branding and communication is problematic long term. Yes, there have been many changes recently but it's only been because DHH approves of it - it's not really consensus driven by different experiences using Ruby on Rails.
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.
No. However, Rails addresses many items on The List. Hence, it's worth using it as a checklist. In reality, things like cache-busting codes are pretty straightforward to write in <language of your choice> and choices about how to represent database entities and validate incoming data require contextual and experiential validation, one size (ActiveRecord) truly doesn't fit all.
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
I'm building a trial balloon in Crystal right now, though not Amber or Lucky. They had their 1.0 release (1.15, even), but it does not feel ready for production. The documentation is not great, the gotchas are unintuitive, and the discussion feels like they're not sure what direction to take the language. The runtime (event loop, fiber scheduler, and garbage collector) dependency means there's plenty of "magic" involved, making it feel significantly more like a framework than a language. Maybe that makes sense if they're targeting the web. If you're on the fence about choosing an established framework like Rails, though, Crystal is not the direction to go yet.
Modern React is a "full-stack" framework - with the current recommended implementation being NextJS.
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
I hate to break this to you, but typescript ain't type-safe. There's a lot I like about typescript, but your runtime is still node, so any "type-safety" is mostly illusory. Not to mention every typescript codebase I've ever looked at includes a copious amount of Any, so...there's that.
Also, typescript has OOP support for a reason -- lots of typescript codebases make copious use of classes. Javascript tried to remain mostly functional for a long time, and people kept trying to make class-based OOP, so, they added it.
Finally, React is not a full-stack framework -- it's a framework for generating UIs. It has recently added support for server-side rendering, and NextJS has added support for that, but Rails and NextJS are very different. Rails is batteries included, NextJS is bring your own [everything] that happens on the server.
YMMV/to each their own/etc etc etc, but referring Rails as "fundamentally unserious" (github, stripe, shopify, i could go on) reflects the opinion of someone who either has an axe to grind with ruby/rails, or is willfully ignorant of it's capability.
> any modern language should support this
It seems that people who use Visual Studio Code expect LSP to exist for every language for some reason, then blame the language itself when it doesn't, as this commenter did. It's strange to me. It isn't that the language doesn't support VSCode, the problem is that VSCode doesn't support the language. VSCode is the bad thing, not the language.
> elite engineers will not want to work for you
Engineers who care more about the specific web technology being used rather than solving the problem don't sound like "elite" engineers.
Your comment is profoundly ignorant. The Language Server Protocol is a standard across all modern editors. It's the reason for the resurgence of Neovim. It is absolutely the responsibility of the language to provide a language server.
> Engineers who care more about the specific web technology being used rather than solving the problem don't sound like "elite" engineers.
Naive
Enlighten me, elite engineer. Why does liking NextJS make you elite?
> standard across all modern editors
This is incorrect. It is Microsoft's open standard that _some_ modern editors have chosen to implement. For example, JetBrains IDEs & Sublime text have no native support, only limited support only through extensions/plugins.
> It is absolutely the responsibility of the language to provide a language server.
Actually, it's absolutely the wild west. Most LSP implementations are not made by the language's foundation, including those of the most popular languages: https://microsoft.github.io/language-server-protocol/impleme...
Again, this is an extremely recent standard, 2016, that services some text editors. This is not something foundational for all language authors.
My main point is: If your editor experience is bad when using Ruby, then your editor is bad for Ruby. Regardless of if your editor uses LSP or something else. The language itself is not at fault.
The statement that Rails is an "unserious" framework is not true. There are many multi-million/billion dollar companies built with Rails: Shopify, GitHub, Chime, Gusto, GitLab, and Basecamp/Hey, to name a few.
1. It does: https://github.com/Shopify/ruby-lsp
2. It does have a type system, just not a _static_ type system. You can declare/annotate methods using RBS/Sorbet, just like TypeScript.
3. I don't care what paradigm is being used if it solves my problem and I can be productive in it.
4. I wouldn't want to work with them either.
> Object-Oriented-Programming is a failed paradigm for modern web development
This seems to me more like an opinion based on personal flavors than an industry statement.
There is no clear winner between OOP and FP. Both are fine and models (thus a bit far away from reality) of an outside world that has a fair part of randomness and increasing complexity. Moreso more languages are implementing properties from the other paradigm.
Also if you think FP is modern you are mistaken. FP is at least as old as OOP if not a bit older. Take a look at when LISP was released and when the first OOP language was released.
But there is LSP support? See: https://shopify.github.io/ruby-lsp/#with-vs-code
There's also (the older) solargraph.
Solargraph is like 8+ years old too.
This person clearly has no actual rails experience. Every deal breaker he lists has a well established solution in rails.