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.
Ask HN: Would you still choose Ruby on Rails for a startup in 2025?
11–20 of 182 posts
Re: Ask HN: Would you still choose Ruby on Rails for a startup in 2025?
#12There goes your answer. Golang was made for Google to simply - onboard junior engineers quickly. It wasn't made to make products quickly.
Re: Ask HN: Would you still choose Ruby on Rails for a startup in 2025?
#13Ironically, 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...
Re: Ask HN: Would you still choose Ruby on Rails for a startup in 2025?
#14Re: Ask HN: Would you still choose Ruby on Rails for a startup in 2025?
#15Re: Ask HN: Would you still choose Ruby on Rails for a startup in 2025?
#16Re: Ask HN: Would you still choose Ruby on Rails for a startup in 2025?
#17Do 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
Re: Ask HN: Would you still choose Ruby on Rails for a startup in 2025?
#18I 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.
Re: Ask HN: Would you still choose Ruby on Rails for a startup in 2025?
#19There 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). Ti…
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: is unbelievably fast. Writing the same in Go would include a lot of boilerpla…
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 ;)
Re: Ask HN: Would you still choose Ruby on Rails for a startup in 2025?
#20I 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 "s…
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.