[HN Gopher] Ask HN: Would you still choose Ruby on Rails for a s...
___________________________________________________________________
Ask HN: Would you still choose Ruby on Rails for a startup in 2025?
It seems that Ruby and Ruby on Rails have some sort of renaissance
now. I only know a bit of Ruby, but I hear it a lot that RoR is the
best thing for prototyping and startups, even better than Django.
Personally, I write Go professionally and I love the simplicity and
the absence of many dependencies. That said, Active Record and
Active Job seem to do exactly what I write manually over and over
again in Go due to having no frameworks. Is Rails still that good?
Author : dondraper36
Score : 79 points
Date : 2025-01-26 17:41 UTC (2 days ago)
| AutistiCoder wrote:
| No, I use Next.JS. Never used Ruby on Rails, I don't see why I
| would now.
| gls2ro wrote:
| 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.
| dondraper36 wrote:
| 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.
| vlod wrote:
| 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.
| brudgers wrote:
| 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.
| dondraper36 wrote:
| 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.
| brudgers wrote:
| 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.
| nivertech wrote:
| _> 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 ;)
| apetrov wrote:
| still you have to maintain the pile of boilerplate code and
| whoever does it, has a very narrow context window (aka
| human)
| matt_s wrote:
| 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.
| tra3 wrote:
| 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
| muzani wrote:
| 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.
| a-priori wrote:
| 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.
| anonfordays wrote:
| >The worst part about Rails is the 37signals people, in
| particular DHH.
|
| Why? What is wrong with DHH?
| bluerooibos wrote:
| 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.
| tra3 wrote:
| 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.
| crowcroft wrote:
| 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.
| kowfm wrote:
| 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.
| anonfordays wrote:
| >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 comment you've ever made.
| schappim wrote:
| 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!
| mahmoudimus wrote:
| 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 :)
| schappim wrote:
| > 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.
| mahmoudimus wrote:
| 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 :(
| moorow wrote:
| We're about to do this as well, but from resque. Got any
| tips to share?
| dzonga wrote:
| > 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.
| jonsmostovojs wrote:
| "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...
| gngoo wrote:
| 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.
| kojeovo wrote:
| Yeah I recently spun up a rails project
| wsintra2022 wrote:
| 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.
| 999900000999 wrote:
| 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
| iainctduncan wrote:
| 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.
| Lio wrote:
| 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/
| iainctduncan wrote:
| 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.
| whstl wrote:
| 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.
| cweagans wrote:
| 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.
| Lio wrote:
| 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?
| ribadeo wrote:
| 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
| ultrarunner wrote:
| 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.
| apetrov wrote:
| 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.
| spo81rty wrote:
| I wouldn't because it is difficult to recruit and find developers
| for it.
| babyent wrote:
| 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.
| thiago_fm wrote:
| 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.
| arshtech97 wrote:
| Yup left my java enterprise job to switch back to ruby on rails
| uaas wrote:
| 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.
| nauman wrote:
| 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.
| nsoseka wrote:
| It's a no brainer for me. I prioritize my happiness above all
| else right now and Ruby with Rails is just joy.
| ka8725 wrote:
| 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.
| camillovisini wrote:
| 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.
| a-priori wrote:
| 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.
| vic700208 wrote:
| Most definitely, it is the fastest path to an MVP for a proof of
| concept.
| dewey wrote:
| 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.
| fourside wrote:
| 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.
| shortrounddev2 wrote:
| 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
| mettamage wrote:
| Most companies don't do that in my experience. It'd have been
| easier to get hired over the years if they did.
| Levitating wrote:
| > 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.
| jph wrote:
| 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.
| Prosammer wrote:
| 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.
| bdcravens wrote:
| 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.
| cardanome wrote:
| 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.
| juancn wrote:
| 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.
| nickserv wrote:
| 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.
| robertlagrant wrote:
| > 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.
| jdauriemma wrote:
| > 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.
| hedgehog0 wrote:
| > 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?
| phaedryx wrote:
| I work for a company that uses Rails. We don't have any
| Python code, but we use a lot of AI.
| turtletime wrote:
| 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.
| jmstfv wrote:
| 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.
| robertlagrant wrote:
| What was it lacking?
| rohan_ wrote:
| 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
| RadiozRadioz wrote:
| > 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.
| rohan_ wrote:
| 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
| RadiozRadioz wrote:
| 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.
| nona wrote:
| But there is LSP support? See: https://shopify.github.io/ruby-
| lsp/#with-vs-code
|
| There's also (the older) solargraph.
| mahmoudimus wrote:
| 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+.
| zeroc8 wrote:
| 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.
| procload wrote:
| 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...
| shortrounddev2 wrote:
| Personally I would use .Net
| charlie0 wrote:
| Yes and I would also take a look at Laravel.
| poushkar wrote:
| 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.
| Tolexx wrote:
| Yes Rails is still a very good choice in 2025 and don't listen to
| anyone telling you it doesn't scale.
| turtletime wrote:
| 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.
| phaedryx wrote:
| 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.
| desselbane wrote:
| 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.
| xutopia wrote:
| 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!
| alexdowad wrote:
| 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.
| noodle wrote:
| 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.
| cullenking wrote:
| 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.
___________________________________________________________________
(page generated 2025-01-28 23:01 UTC)