Would you still choose Ruby on Rails for a startup in 2025?

… 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. 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. … 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. ... … 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'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. nickserv 9 months ago 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. … 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. 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? … 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! … 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