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

Some of these are eyebrow raising and certainly not boring!

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.

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 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.

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.

> 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.

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.

But the good news is that you can just ignore them and enjoy the framework, like I do.

Why? What is wrong with DHH?

It's also possible to appreciate the stuff he's done for software whilst not being in love with him as a person.

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.

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.

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.

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.

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)

Only way to avoid being called either a fascist or woke (and I know some who are accused of both!) nowadays is to never say anything.

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.

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.

Oh, so you don't have any proof, got it. Your claims have been dismissed, David is not fascist.

>Kinda lazy that you're all not out there looking for the proof yourself.

There is no proof.

>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.

No proof of this either, so your claim is dismissed outright.

>A problem openly, and vigorously discussed in the Ruby community.

Any proof of this? Who claims it's a problem?

>Many people have left the Ruby community because of his behavior

Looks like a loud minority of leftist activists may have left. That explains how Ruby has only gotten better since.

>many more have chosen never to come into the community because of it.

Many more have chose to join the community now that the activists are gone.

>Anyways, as per my original point, that despite the Fascist vibes from that guy

There are no Fascist vibes as shown above.

Ironically, this attitude is quite Trumpian. I hope you're just pretending to cover the laziness of your argument.

Why? What "Musk vibes" have they given off?

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?

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."

https://news.ycombinator.com/item?id=42593223

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.

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.

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.

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 :-)

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.

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.

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.

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.

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.

Rubbish.

This is just fanboi talk that all rails developers tell each other without a shred of science.

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.

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.

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.

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.

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.

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.

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 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+.

Rails all the way for me!

All that being said these days I'd start with Elixir/Phoenix.

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.

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.

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.

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.

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?

Also are there any Ruby AI libraries that you would recommend? Thanks!

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.

I always wonder about this. Surely the technology you pick influences the size of the team.

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.

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.

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.

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 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.

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/

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.

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 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.

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.

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 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.

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.

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.

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.

In fact, I switched to Rails from Django because the latter was lacking.

You may want to watch a talk about Rails and startups: https://youtu.be/-sFYiyFQMU8

Disclaimer: I'm one of the authors of Loco.

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.

You want something that speeds you up and frees up time to validate your idea, not reinventing the wheel.

Cheers!

+ 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.

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 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.

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 ;)

It’s like rails is an iphone - others are androids at best.

Within its niche of course.

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.

Although if you're going with Go, then sqlc (https://sqlc.dev) is a no-brainer.

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.

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.

There goes your answer. Golang was made for Google to simply - onboard junior engineers quickly. It wasn't made to make products quickly.

1. What I already know if I am the one building the prototype.

2. Cost of training new employees.

3. Execution speed.

Everything else can be ignored.

I don't really understand people who chooses to MVP a startup writing their own EVERYTHING

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

I do know Ruby well though.

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.

1. Go with what you and your team already know (unless what you know doesn't apply to the target space)

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.

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.

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?

Actually choosing something everyone is comfortable and confident in using is probably a good choice.

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.

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.

Magic's just science that we don't understand yet.

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.

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...

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.

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

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

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.

> Engineers who care more about the specific web technology being used rather than solving the problem don't sound like "elite" engineers.

Naive

> 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.

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.

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.

There's also (the older) solargraph.

This person clearly has no actual rails experience. Every deal breaker he lists has a well established solution in rails.