Why Ruby on Rails still matters

What is HackerNews but a system to stress test everyone's hobby websites?

back in my day kid we used to serve far more users from 40mhz CPUs. The only interesting part is that today you can get pipes fast enough to do this in your house, while back then dialup was all we could afford ($1000/month to get into the 1 megabit/second range, ISDN and DSL came soon after and were nice).

Of course back then we didn't use dynamic anything, a static web page worked.

Now get off my lawn!

That's amazing. Mac Mini is very efficient and is a great little home server. Idles at 3-4w total for the entire machine. Plus, the M4 is a beast of a CPU. It might even be possible to serve a small LLM model like a 3b model on it over the internet.

I see you're serving a GTS certificate. Does GCP allow you to download TLS certificates? I honestly didn't know. I thought just like AWS, you get them only when using their services like load balancers, app runners etc.

I like that you're pointing out application longevity in the linked article. It seems that new SaaS apps appear and disappear daily as cloud hosting isn't cheap (especially for indie hackers). I'd much rather sign up for an app that I knew wouldn't randomly disappear in a couple of months when the cloud bills surpass the profits.

I've been thinking about that article for the past week so much that I've been looking at $250 Ryzen 7 5700U 16/512/2.5G Ace Magician NUCs to move some of my properties to. They're known to be shipping spyware on their Windows machines, but my thought was that I'd get 3 of them, clear them out with Debian, and set them up as a k8s cluster and have enough horsepower to handle postgres at scale.

Presumably CF is doing most of the work if the page doesnt actually change all that much?

the article is AI-generated isn't it ?

This never happens in real life....."rewriting software" is the introverted programmer's wet dream because it gives them relevance and the idea of respect. No serious business "rewrites software in something else" once they start to take off.

The problem with 1 model = 1 rest entity (in my experience) is that designers and users of the applications I have been building for years never want just one model on the screen.

Inevitably, once one update is done, they'll say "oh and we just need to add this one thing here" and that cycle repeats constantly.

If you have a single page front end setup, and a "RESTful" backend, you end up making a dozen or more API calls just to show everything, even if it STARTED out as narrowly focused on one thing.

I've fought the urge to use graphql for years, but I'm starting to think that it might be worth it just to force a separation between the "view" of the API and the entities that back it. The tight coupling between a single controller, model and view ends up pushing the natural complexity to the wrong layer (the frontend) instead of hiding the complexity where it belongs (behind the API).

Rails is set up for that, but it doesn't force you to build like that. You're free to build in other patterns that you design yourself. It's nice to have simple defaults with the freedom to opt into more complexity only if and when you need it.

Yeah, I agree.

Too many degrees of freedom can degrade an experience, if not used properly.

> Why is the ruby/rails community so weird. Half of us just quietly make stuff, but the other half seems to need to sporadically reassure everyone that it's not dead, actually.

Half the net merrily runs on PHP and jQuery. Far more if you index on company profitability.

> Not everything needs to have bloody AI.

Some things are an anti-signal at this point. If a service provider starts talking about AI, what I hear is that I'm going to need to look for a new service provider pretty soon.

Based on what I've seen from job postings in the US, you can't start a company in healthcare right now unless you've got AI featuring prominently.

Sadly, I'm not even talking cool stuff like imaging (though it's there too), but anything to do with clinical notes to insurance is all AI-ified.

Truly, it is the new crypto-web3 hype train, except there'll be a few useful things to come out of it too.

> Not everything needs to have bloody AI.

And even if it did, the Ruby eco-system has AI stuff...

> You have the Python type system, and while it's inferior to TypeScript's in many ways, it's far more ubiquitous than Ruby's Sorbet.

I'm a big fan of Ruby, but God I wish it had good, in-line type hinting. Sorbet annotations are too noisy and the whole thing feels very awkwardly bolted on, while RBS' use of external files make it a non-starter.

Django shouldn't even require gevent - Django's ASGI support has been baking for a few releases now and supports async views which should be well suited to proxying streams from LLMs etc.

Relevant:

- https://fly.io/django-beats/running-tasks-concurrently-in-dj...

- https://blog.pecar.me/django-streaming-responses

(Reminds me I should try that out properly myself.)

Just move to Elixir. Phoenix is Rails-like enough and the platform is excellent for parallelisation, clustering in specific hardware and so on.

Agree. What Rails actually lacks is thousands of ready-made boilerplates that everyone and their grandma can use to spin a chat interface. Any programmer worth his salt should be able to write his own.

I've done all of the above in Hotwire. It really is a fantastic tool.

I'd rate it as about 90%-ish of what react gives you at 5-10% of the development effort. React sites can definitely be nicer, but they are so much more work.

What do you mean "left behind"? Are you saying people will actually gt "left behind" or just that people will _feel_ like they're left behind?

At this poitn you can find tools that can make demos easier to build or get you further in a hackathon, but Rails embodies "Slow is steady and steady is fast." If you're trying to build something that will stick around and can grow (like a startup outside of the latest VC crazes) then Rails will arguably do better at keeping your tools relevant and supported in the long run. That is, assuming you're building something that needs a steady backend for your application.

Heh, maybe us engineers need to be better disciplined about what "greatest" is.

In an era where everything and their mother is getting rewritten in Rust, surely we should be able to get a proper, fully featured, batteries included web framework out of it too. But it seems like all Rust web frameworks are either extremely low level (so low level that I don't see their value add at all), or extremely unfinished. Last I checked, even things like "named routes" or TLS were exotic features that required manual (and incompatible!) workarounds.

It's kind of fascinating to me that all the frameworks in 'slow', dynamic languages (Rails, Laravel) are feature packed and ready to roll, and everything in 'fast', static languages is so barren by comparison. The two seem almost exactly inversely proportional, in fact.

A batteries-included web framework in Rust with comparable built-in functionality to Rails, and comparable care for ease-of-use, would be game changer.

Laravel for PHP has a similar scope, community and exposure I would say.

Having mostly done agency work my whole life I have seen a lot of frameworks, in a lot of languages. Rails and Laravel are the standouts for just QoL experience, and Getting Shit Done.

They're engineered to get out of the way, and modular or extensible enough to enable deeper modifications easily.

For JVM, Apache Causeway provides similar capabilities (in fact, even more abstracted than RonR). Full disclosure: I'm a committee on that project.

https://causeway.apache.org

Django is exactly that for Python.

> sidenote - is NextJS really the best “convention over configuration” approach for react? I’d love to just use ember, but most of the community has moved to react, but I really enjoy the opinionated approach

You might like Remix [0] (I do).

[0]: https://remix.run

I suspect long-term LLMs spell the end of typed language popularity in most application programming contexts.

I agree with The Grug Brained Developer (https://grugbrain.dev/) that “type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug”.

This already is being heavily replaced by LLMs (e.g. copilot) in many people’s workflows. Co-pilot’s suggestions are already mostly higher level, and more useful, than the static typing auto-complete.

I believe the quality-of-autocomplete gap between typed and untyped languages has already largely converged in 2025. Co-pilot today writing TypeScript just doesn’t produce overwelmingly better auto-complete results than JavaScript. Compare with 4 years ago, where Javascript auto-complete was trash compared with TS. And even then, people argued the merits of untyped: all else being equal, less is more.

What happens when “all else” IS equal? ;-)

Currently, static typing can help the LLM generate its code properly, so it has value in helping the LLM itself. But, once the LLM can basically hold your whole codebase in its context, I don’t see much use for static typing in implementing the “hit dot on keyboard, see list of things you can do” advantage. Essentially, the same way type inference / auto lets languages skip repetitive specification typing, by holding your whole codebase in memory the LLM can mostly infer the type of everything simply by how it is called/used. LLMs take type inference to the next level, to the degree that the type barely needs to be specified to know “press ., see what you can do”

I rarely use the static typing type of auto-completion when programming now, almost everything I accept is a higher level LLM suggestion. Even if that’s not true for you today, it might be tomorrow.

Is the remaining 10% of “formal correctness” worth the extra volume of characters on the screen? I suspect Rust will do well into the distant LLM future (used in contexts where formal correctness is relatively important, say kernels), and I suspect TypeScript will decrease in popularity as a result of LLMs.

I've found LLMs are pretty good at generating basic code for everything except the specs/tests when it comes to Rails. Lot of my work lately has been like 4x more time w/ specs/tests than actually creating the application code because LLM just isn't cutting it for that part.

So we have an LLM code scaffold repo we use in a large (2m loc) production Rails codebase and it works amazingly well.

Rails and especially Ruby lends itself to describing business logic as part of source code closer to natural language than a lot of typed languages imo and that synergizes really well with a lot of different models and neat LLM uses for code creation and maintenance.

You make some good points, but I think as AI continues progressing down the road of "reasoning", any data points that allow it to reason more will be helpful, including (and maybe especially) types. AI could definitely reason about rails too, and perhaps it will quickly get really good at that (especially if it "understands" the rails source code) but it's hard to think of a situation in which less data is more useful than more data

> At least in my experience (using the Windsurf IDE with Claude 3.5 Sonnet) LLMs do a very good job in a Rails codebase for stuff like "I want to create a new page for listing Widgets, and a Create page for those Widgets. And then add pagination.". I've been able to spin up whole new entities with a model/view/controller and database migration and tests, styled with tailwind.

Does it suggest using rails generators for this - and/or does it give you idiomatic code?

I've noticed that, in agent workflows like Cursor, they're able to use built-in type checkers to correct errors.

With Ruby, it doesn't have as much information, so it has to rely on testing or linters for feedback.

In Elixir land we have Instructor. It hits AI endpoints cleanly, and then validates the returned JSON using Ecto Changesets. Very powerful, clean abstraction. Love it!

https://hexdocs.pm/instructor/Instructor.html

Someone in Rails land could build similar and voila.

See also: https://gist.github.com/peterc/214aab5c6d783563acbc2a9425e5e...

Also wanted to mention Django & Python because Python is evidently doing even better in the age of AI and building back-end heavy ML apps with it is much than in Javascript land.

I feel for you. I'm a Rails developer and I recently joined a Django project... Django feels so far behind Rails... But everyone has their own preference and opinion...

This looks fairly lightweight and clean, but you immediately replace a large portion of the Rails ecosystem with React and will constantly need to account for that when deciding how to build your application. By sticking closer to "the Rails way" you get the support of it's massive community.

If Intertia.js development halts, then you're stuck with either a) adopting something else, or b) maintaining the tool for your own use cases. Using something like this would, imo, be closer to building a Rails app in API mode with a separated frontend than adding a new library on top of Rails.

If you just want React+Rails, the rails generator command comes with a bunch of options to set that up for you, including setting up and configuring: React/Vue/etc, a bundler like vite, typescript, tailwind.

It looks like inertia has additional features though.

This looks interesting. I think I'll try it out over the weekend. Thanks for sharing.