It seems that Ruby and Ruby on Rails have some sort of renaissance now. I only know a bit of Ruby, but I hear it a lot that RoR is the best thing for prototyping and startups, even better than Django.<p>Personally, I write Go professionally and I love the simplicity and the absence of many dependencies. That said, Active Record and Active Job seem to do exactly what I write manually over and over again in Go due to having no frameworks.<p>Is Rails still that good?
Yes, I would. In fact, I'd use any boring technology [0]. Anything that's been around and battle tested.<p>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.<p>0: <a href="https://boringtechnology.club" rel="nofollow">https://boringtechnology.club</a>
I am the CTO of <a href="http://ridewithgps.com" rel="nofollow">http://ridewithgps.com</a> 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.<p>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.<p>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.<p>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.<p>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.
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.<p>A lot of people say things like "the difficulty with Rails is in the long term". To them I'd say two things:<p>- 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.<p>- 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.
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.<p>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.<p>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.
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).<p>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).<p>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.
>Is Rails still that good?<p>It is but;<p>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.<p>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.<p>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.<p>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%.<p>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.<p>The whole ecosystem is basically ready for you to just work on business logics.<p>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.
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.
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).<p>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.<p>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.
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.<p>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.
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.<p>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.<p>If you're doing a startup, your goal (I presume) is to validate your assumptions and get customers.<p>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.<p>Remember 95% (odd) startups fail, so think about failing as fast as possible.
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.<p>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.
It depends.<p>I'd probably pick it for any medium complexity low traffic saas that doesn't have any crazy infra or ML or staffing requirements.<p>It's a nice sweet spot for many companies.<p>With high complexity you probably want strict types.<p>With high traffic you probably want better perf like rust or go.<p>With ML you want python.<p>With ease of hiring or low complexity backend but high complexity frontend, you probably want Next or node.<p>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
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++.<p>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.
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’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.<p>Rails all the way for me!
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.<p>All that being said these days I'd start with Elixir/Phoenix.
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.<p>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.<p>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.<p>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.
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.<p>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.<p>There is a lack of good quality, well maintenained 3rd party libraries. No such problem with Python, Node, even PHP to a certain extent.<p>It's slow, except compared to Python. Ruby 3 is much better but still behind.<p>If you need to ship decent code fast, I would reach for Django.<p>If you're doing AI stuff, any Python framework will be best.<p>If you need to hire a sizeable team quickly, I would reach for Node or PHP.<p>If you need high performance and high reliability I would use Go.
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.<p>Node is fast enough, easy to develop, deploy, and scale. Anything that is slow can be ported to Go.<p>It is easy to find solutions to my immediate problems using LLMs.<p>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.<p>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.
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.<p>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.
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.<p>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.
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.
I've actually just did exactly that a few weeks ago.<p>I knew what to expect from Rails from my previous experience.<p>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.<p>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.
I have a love hate relationship with rails.<p>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.<p>Still for starting out it’s pretty awesome.<p>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.
I recently had to choose between Django and Ruby on Rails (RoR). I’ve used Django for smaller projects but had never tried RoR. I picked these two because I think single-page applications (SPAs) are often more than what’s needed. After looking into Next.js, I realized I'd have to learn a lot to use it properly, and I didn’t want to dive into that. I just wanted to get started without dealing with complicated tools.<p>After thinking it over, I decided to give RoR a shot. The framework does a lot for you, which can be frustrating if you’re used to having control over everything. Still, I was surprised by how much I could accomplish in just a few days. The productivity is impressive, especially for startups that need to get things moving quickly.<p>So if you just want to prove a business idea, your customers don’t care what tools you use. I’d rather pay twice the price to scale in RoR than spend double the time developing a feature. I would earn it back with the additional customers I gain by pushing features faster out the door.
Rails is pretty good - built my current business on Rails, building a new one on Rails as well.<p>In fact, I switched to Rails from Django because the latter was 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: <a href="https://blog.spellbooks.ai/posts/move-over-spas-rails-is-broadcasting-ai-straight-to-your-dom/" rel="nofollow">https://blog.spellbooks.ai/posts/move-over-spas-rails-is-bro...</a>
Definitely. The speed Rails gives you is very valuable especially when building a new product. And it’s fun. And way less boilerplate code.<p>You may want to watch a talk about Rails and startups: <a href="https://youtu.be/-sFYiyFQMU8" rel="nofollow">https://youtu.be/-sFYiyFQMU8</a>
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).<p>Disclaimer: I'm one of the authors of Loco.
It's still good but that does not mean you should choose it.<p>While Ruby on Rails still offers strong productivity benefits, the hiring landscape has shifted significantly, particularly here in Australia.<p>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.<p>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.<p>Maybe it's a much larger pool elsewhere or if you can accept 100% remote.
For startups and especially small teams that want to move fast, rails is the top choice.<p>You want something that speeds you up and frees up time to validate your idea, not reinventing the wheel.<p>Cheers!
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”.
Yes I would. I’m running my single product building agency <a href="https://cubitoo.com" rel="nofollow">https://cubitoo.com</a> and it often blows my clients’ minds how easily we can incorporate advanced features with high level work Rails enables. I’m with Rails since v2 and never looked back.
i would, especially if there is mobile ui on horizon (hotwire)<p>+ added ports and adapters (aka hexagonal architecture, there are many articles on how to do it in ror)<p>disclaimer: i work with ror since 2006 so i have a strong bias.
There is a large base of competent Rails practitioners.<p>It has good documentation.<p>The code base is stable.<p>There are mature libraries.<p>It is practical to learn Rails.<p>Sure there are very good reasons not to choose Rails, but the current year is not one of them.<p>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).<p>Time spent researching web frameworks postpones building the potentially money printing mechanism. When your research is done, you still won't have built anything.<p>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.
Rails had always been and still is the best tool for its goal. Nobody comes close (despite a lot of surface level similarities).<p>It’s like rails is an iphone - others are androids at best.<p>Within its niche of course.
What are the best and most up-to-date resources for learning Ruby on Rails? I primarily work with PHP and Laravel, but I keep hearing great things about RoR and would love to learn it.
Write go and plain SQL at the back end.<p>Use whatever makes you happy for front end.<p>Rails is not magical or vastly better than anything else in any way.<p>Especially not since AI and Claude.<p>Any mainstream technology is a great choice for building most things. Python node TypeScript Ruby, Golang C#.<p>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.<p>My only very strong recommendation….. use plain old SQL. It’s a superb choice.
I am the CTO of <a href="https://www.leexi.ai/" rel="nofollow">https://www.leexi.ai/</a> which is powered by a Rails API (Vue/Nuxt in the frontend).<p>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.<p>We now have thousands of customers using it daily and it has been nothing but a joy to create and maintain this app.
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.<p>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.<p>Of course, there's no panacea. Your current "simple and low-dependency" approach has its own challenges, so choose your poison.
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.
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.
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<p>There goes your answer. Golang was made for Google to simply - onboard junior engineers quickly. It wasn't made to make products quickly.
There are only three things I would consider for tech at a start up.<p>1. What I already know if I am the one building the prototype.<p>2. Cost of training new employees.<p>3. Execution speed.<p>Everything else can be ignored.
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.
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 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.
What are your actual goals.<p>Do you want to learn Ruby. Then go for it. If not pick a different language. Pick one you know.<p>You might not even need a full backend server. Firebase or Syperbase might be enough
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.<p>There is no silver bullet that would fit every startup situation.<p>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.<p>Plus you can run your project on a $5 shared hosting and not worry about dev ops and stuff, massively reducing costs.<p>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.<p>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.<p>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.<p>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.
If you don't know Ruby, and you don't know Ruby on Rails, you have 2ish choices:<p>1. Go with what you and your team already know (unless what you know doesn't apply to the target space)<p>2. Learn Ruby and especially Ruby on Rails first. Otherwise, you'll end up with a dumpster fire. Make sure you investigate the idioms, and use Rubocop, ruby-lsp, and ruby-lsp-rails -- there are more tools for linting your code that help you learn what not to do.<p>If you aren't using Rails for the FE, you are losing at least 30% of the benefits, unless your FE is just rendering what Rails is returning and not managing complex state.
Yes absolutely, although I don't see anything wrong with sticking to Go either if you know and like it.<p>Rails 8 just gives you so much out of the box for a small start up that it would be my personal choice.<p>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.<p>Or using Kamal for deployments to cheap commodity servers without having to setup K8s or use expensive cloud services.<p>Even things like ActionText for rich page content are a big win.<p>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?
Choose whatever. Go is fine. Ruby is fine. Next.js is fine. Python with Django is fine. Even Haskell is fine if your initial gang knows it well. You won't fail because of the tech.<p>Actually choosing something everyone is comfortable and confident in using is probably a good choice.<p>You may fail for too many innovation tokens though. If you go off the rails (ha ha ha) on tech stack maybe stick to postgres for storage and AWS for hosting.
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.<p>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.<p>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.<p>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.<p>Ironically, one of the reasons my startup died was using Elixir as if it was Rails[1].<p>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!<p>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!<p>I would personally just use typescript bridged to rust to preserve types ans sqlx for type-safe queries to the database.<p>Or use something like bubble.io if you want to iterate on ad hoc things until you get there!<p>[1]: <a href="https://memorici.de/posts/pre-mortem/" rel="nofollow">https://memorici.de/posts/pre-mortem/</a>
[2]: <a href="https://medium.com/launch-school/params-in-rails-where-do-they-come-from-b172cdb46eb4" rel="nofollow">https://medium.com/launch-school/params-in-rails-where-do-th...</a>
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.<p>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).<p>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.<p>One is well served to learn Rails for many reasons, but i would not start a green field 2025 project with any framework.<p>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.<p>Have a gander at Crystal Lang, BTW, and Amber and Lucky frameworks
Modern React is a "full-stack" framework - with the current recommended implementation being NextJS.<p>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)<p>Typescript is going to be the language of AI engineering, (with Python being the language of ML engineering).<p>Rails is a fundamentally unserious framework:<p>1. It lacks LSP (any modern language should support this, think "clicking" a function call to go to it's definition)<p>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?)<p>3. Object-Oriented-Programming is a failed paradigm for modern web development<p>4. elite engineers will not want to work for you