Every time I share a project I provide two links, one for my vps and another one for GitHub pages. Usually my projects run on the client, so I have never experienced the hug of death myself.
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.
My first company website was served of a 120MHz Pentium that also served as the login server where 5 of us ran our X clients (with the X servers on 486's with 16MB RAM)...
And it wasn't static: We because peoples connections were mostly so slow, we used a CGI that shelled out to ping to estimate connection speed, and return either a static image (if you were on a dialup) or a fancy animated gif if you were on anything faster.
(the ping-test was obviously not reliable - if you were visiting from somewhere with high latency, you'd get the low bandwidth version too, no matter how high your throughput was - but that was rare enough; it worked surprisingly well)
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 took a startup from zero to 100k MRR as of last month over the last 5 years. I can tell you that cloud billing is the least of your concerns if you pay even the cursory attention to writing good queries and adding indexes in the right places. The real issue is the number of developers who never bother to learn how to structure data in a database for their use case. properly done, you can easily support thousands of paying users on a single write server.
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.
Yeah, the mac minis can have up to 64GB of ram which would support some usable models. However, I accidentally got one with 24gb of ram, and my apps already use 12gbs. So, perhaps I'll get a second box just for LLMs!
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.
It does look like the main article isn't actually cached by Cloudflare. But most of the assets are. So it is definitely helping but not taking the entire load.
It's fun to host at home, I run docker on alpine VMs on two proxmox machines. Yeah, different docker machines for each user or use-case look complicated but it works fine and I can mount nfs or samba mounts as needed. Only thing I have on the cloud is a small hetzner server which I mostly use as a nginx proxy and iptables is great for that minecraft VM.
Why did you go for Cloudfare tunnel instead of wireguard?
Cloudflare Tunnel provides you a publicly routable address for free. With wireguard you would still need a VM somewhere, and if you are hosting your own VM, then whats the point?
I've tried to do so with a $9 pocket pc, but ended up frying it by accidently short-circuiting it.
I wrote a visualizer for the traffic that I think people will appreciate [1]. I will post it next month once I add it on github. It was fun to watch an article that went #1 on HN.
Is cloudflare tunnels really this free to support thousands of internet requests?
I run a windows server at my office where we connect to it using RDP from multiple locations. If I could instead buy the hardware and use cloudflare tunnels to let my team RDP to it then it would save me a lot of money. I could recoup my hardware cost in less than a year. Would this be possible?
(I wouldn't mind paying for cloudflare tunnels / zero trust. It just should be much smaller than the monthly payment I make to Microsoft)
Yup. Cloudflare's typical proxy already handles massive amounts of traffic, so I expect that the marginal cost of this reverse proxy isn't that high.
I do think Cloudflare has proven itself to be very developer/indie-friendly. One of the only tech unicorns that really doesn't impose its morality on customers.
I used Cloudflare Tunnels for a project that had hundreds of tunnels did roughly 10GB/day of traffic entirely for free. The project has since moved to Cloudflare Enterprise, where the project pays the opposite of free, but was completely expected as the project grew.
I'm pretty sure Tunnels supports RDP and if you don't use a ton of bandwidth (probably under a 1TB/mo), Cloudflare probably won't bother you.
I wrote a blog post that generated a lot of traffic on HackerNews last year when it briefly was on #1 here. My blog was (and still is) hosted on a 9-year old Dell Latitude E7250 with Intel Core i5-6300U processor. The server held up fine with ~350 concurrent readers at its peak. It was actually my fiber router that had trouble keeping up. But even though things got a bit slow, it held up fine, without Cloudflare or anything fancy.
It's hosting a variety of apps - blog (Ghost), plausible analytics, metabase, and soon 3 Rails apps. It's unfortunately running Postgres, MySQL, and Clickhouse.
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.
Pretty cool. Wouldn't work for me as my ISP is horrendously unreliable (Rogers in Canada, I swear they bounce their network nightly), but I might consider colocating a mac mini at a datacenter.
What kind of Mac mini do you use (cpu and ram)? I’m really interested in making the same thing but I’m not sure if the base M4 mini is enough with just 16gb of ram.
Depends what you're doing. If it's literally just serving up some static web pages though that is hilariously over specified, you're going to be constrained by your internet connection long before that Mac Mini starts breaking a sweat.
Hosting from home is fun, I guess, but it actually was a money-saving exercise before the cloud. I've done it.
Now, however, what is the point? To learn server config? I am running my blog with GitHub pages. A couple of posts made it to the top of HN, and I never had to worry.
Always bewilders me when some sites here go down under load. I mean, where are they hosting it that a static page in 2020s has performance issues?
I really like web apps that are just CRUD forms. It obviously doesn't work for everything, but the "list of X -> form -> updated list of X" user experience works really well for a lot of problem domains, especially ones that interact with the real world. It lets you name your concepts, and gives everything a really sensible place to change it. "Do I have an appointment, let me check the list of appointments".
Contrast that, to more "app-y" patterns, that might have some unifying calendar, or mix things into a dashboard. Those patterns are also useful!! And of course, all buildable in rails as well. But there is something nice about the simplicity of CRUD apps when I end up coming across one.
So even though you can build in any style with whatever technology you want:
Rails feels like it _prefers_ you build "1 model = 1 concept = 1 REST entity"
Next.js (+ many other FE libraries in this react-meta-library group) feels like it _prefers_ you build "1 task/view = mixed concepts to accomplish a task = 1 specific screen"
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).
Why the assumption that an API endpoint should be a 1:1 mapping to a database table? There is no reason we need to force that constraint. It's perfectly legitimate to consider your resource to encompass the business logic for that use case. For example, updating a user profile can involve a single API call that updates multiple data objects - Profile, Address, Email, Phone. The UI should be concerned with "Update Profile" and let the API controller orchestrate all the underlying data relationships and updates.
I have actually had a different experience. I feel like I've run into "we can't just see/edit the thing" more often than "we want another thing here" with users. Naming a report is the kiss of death. "Business Report" ends up having half the data you need, rather than just a filterable list of "transactions" for example.
However, I'm biased. A lot of my jobs have been writing "backoffice" apps, so there's usually models with a really clear identity associated to them, and usually connected to a real piece of paper like a shipment form (logistics), a financial aid application (edtech), or a kitchen ticket (restaurant POS).
Those sorts of applications I find break down with too many "Your school at a glance" sort of pages. Users just want "all the applications so I can filter to just the ones who aren't submitted yet and pester those students".
And like many sibling comments mention, Rails has some good answers for combining rest entities onto the same view in a way that still makes them distinct.
> you end up making a dozen or more API calls just to show everything
This is fine!
> I've fought the urge to use graphql for years
Keep fighting the urge. Or give into it and learn the hard way? Either way you'll end up in the same place.
The UI can make multiple calls to the backend. It's fine.
Or you can make the REST calls return some relations. Also fine.
What you can't do is let the client make arbitrary queries into your database. Because somebody will eventually come along and abuse those APIs. And then you're stuck whitelisting very specific queries... which look exactly like REST.
This is a very common pattern and one that’s been solved in Rails by building specialized controllers applying the CRUD interface to multiple models.
Like the Read for a dashboard could have a controller for each dashboard component to load its data or it could have one controller for the full dashboard querying multiple models - still CRUD.
The tight coupling is one of many approaches and common enough to be made default.
You can separate the view and the backend storage without going graphql. You can build your API around things that make sense on a higher level, like "get latest N posts in my timeline" and let the API endpoint figure out how to serve that
It's seemingly more work than graphql as you need to actually intentionally build your API, but it gets you fewer, more thought-out usage patterns on the backend that are easier to scale.
You should checkout phoenix liveview. you can maintain a stateful process on the server that pushes state changes to the frontend. its a gamechanger if you're building a webapp.
This may be a misunderstanding on my part, but something that’s kept me away from GraphQL is how it makes for a hard dependency on GraphQL client libraries in clients. I find that very unappealing, it’s nicer to be able to e.g. just use platform/language provided networking and JSON decoding (e.g. URLSession + Swift Codable on iOS) and keep the dependency list that much shorter.
> If you have a single page front end setup, and a "RESTful" backend
Rails really doesn't encourage this architecture, quite the opposite in fact.
> designers and users of the applications I have been building for years never want just one model on the screen.
... and this is where Rails excels. When you need to pull in some more data for a screen you just do it. Need to show the most recent reviews of a product in your e-commerce backend? It's probably as simple as:
Graphql is nice but there are all sorts of weird attacks and edge cases because you don't actually control the queries that a client can send. This allows a malicious client to craft really time expensive queries.
So you end up having to put depth and quantity limits, or calculating the cost of every incoming query before allowing it. Another approach I'm aware of is whitelisting but that seems to defeat the entire point.
I use rest for new projects, I wouldn't say never to graphql, but it brings a lot of initial complexity.
> I really like web apps that are just CRUD forms.
I really like easy problems too. Unfortunately, creating database records is hardly a business. With a pure CRUD system you're only one step away from Excel really. The business will be done somewhere else and won't be software driven at all but rather in people's heads and if you're lucky written in "SOP" type documents.
As someone who co-founded one of the most successful Ruby on Rails consultancies in the world: building CRUD apps is a _fantastic_ business.
There are two types of complexity: essential and incidental. Sometimes, a straightforward CRUD app won't work because the product's essential complexity demands it. But at least as often, apps (and architectures, and engineering orgs, and businesses) are really just CRUD apps with a bunch of incidental complexity cluttering up the joint and making everything confusing, painful, and expensive.
I've served dozens of clients over my career, and I can count on one hand the number of times I've found a company whose problem couldn't more or less be solved with "CRUD app plus zero-to-one interesting features." No technologist wants to think they're just building a series of straightforward CRUD apps, so they find ways to complicate it. No businessperson wants to believe their company isn't a unique snowflake, so they find ways to complicate it. No investor wants to pour their money into yet another CRUD app, so they invent a story to complicate it.
IME, >=90% of application developers working today are either building CRUD apps or would be better off if they realized they were building CRUD apps. To a certain extent, we're all just putting spreadsheets on the Internet. I think this—more than anything else—explains Rails' staying power. I remember giving this interview on Changelog ( https://changelog.com/podcast/521 ) and the host Adam asking about the threat Next.js posed to Rails, and—maybe I'd just seen this movie too many times since 2005—it didn't even register as a possible contender.
Any framework that doesn't absolutely nail a batteries-included CRUD feature-set as THE primary concern will inevitably see each app hobbled with so much baggage trying to roundaboutly back into CRUD that it'll fall over on itself.
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.
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.
> Rails has started to show its age amid with the current wave of AI-powered applications.
> 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.
Yes now at doctors offices you have the option to sign an agreement for the doctor to wear a microphone to record the conversation and then AI tool automatically creates a report for the doctor. AI and all aspects of medicine seem to be merging.
A former customer of mine is creating AI apps with Rails. After all what one is those apps need is to call an API and output the results. Rails or any other system are more than capable of doing that.
> Rails has started to show its age amid with the current wave of AI-powered applications. It struggles with LLM text streaming, parallel processing in Ruby
Not at all my experience, actually it was incredibly easy to get this working smoothly with hotwire and no javascript at all (outside the hotwire lib).
We have a Rails app with thousands of users streaming agentic chat interfaces, we've had no issues at all with this aspect of things.
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.
The real problem is programmers that understand how a computer works end-to-end is becoming increasingly rare, and possibly accelerated by the adoption of LLMs.
A lot of them prefer to write Ruby because it is simply the most beautiful language they know of. Technical details are merely a formality expressed in code that borders art.
I was under the impression the industry was collectively moving in that direction, but then bootcamps ushered in a new era of midwit frontend developers hell bent on reinventing the wheel from scratch (poorly).
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.
This has been my experience as well. Hotwire is actually a more pleasant experience than React.
React is a good choice if you’ve got a huge dev team that can split things into components and independently work on things but otherwise React is so full of footguns that it’s almost comical that people choose it for anything other than bloated VC projects.
> Rails has started to show its age amid with the current wave of AI-powered applications. It struggles with LLM text streaming, parallel processing in Ruby, and lacks strong typing for AI coding tools. Despite these constraints, it remains effective.
A plug for Django + gevent in this context! 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. For streaming and any kind of IO-bound parallelism, gevent's monkey-patches cause every blocking operation to become a event-loop yield... so you can stream many concurrent responses at a time, with a simple generator. CPU-bound parallelism doesn't have a great story here, but that's less relevant for web applications - and if you're simultaneously iterating on ML models and a web backend, they'd likely run on separate machines anyways, and you can write both in Python without context-switching as a developer.
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.
then you have to rewrite your whole app to use asyncio keywords and colored ORM methods. A gevent monkey patch, or eventually nogil concurrency makes a lot more practical sense.
And the switch is rather easy. I've been writing elixir for nearly 10 years, rails before that, and have overseen the "conversion" of several engineers from one to the other.
Generally I'd say any senior rails dev, given the right task, can write decent elixir code on their first day. There are a lot fewer foot guns in elixir and Phoenix, and so other than language ergonomics (a simple rule that doesn't stretch far but works at the beginning is use pipe instead of dot), there's minimal barriers
Normally "switch languages" isn't great advice, but in this case I think it's worth considering. I have heard people coming from Django and Rails background describe Elixir as "a love child between python and ruby". Personally I love it
I personally think Elixir is a great language, but the jump from ruby to functional programming is big enough that I'm not sure it's useful general advice.
> 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.
Do you mean Ruby lacks syntactic support for adding type annotations inline in your programs?
I am one of the authors of RDL (https://github.com/tupl-tufts/rdl) a research project that looked at type systems for Ruby before it became mainstream. We went for strings that looked nice, but were parsed into a type signature. Sorbet, on the other hand, uses Ruby values in a DSL to define types. We were of the impression that many of our core ideas were absorbed by other projects and Sorbet and RBS has pretty much mainstream. What is missing to get usable gradual types in Ruby?
I for one really like RBS being external files, it keeps the Ruby side of things uncluttered.
When I do need types inline I believe it is the editor's job to show them dynamically, e.g via facilities like tooltips, autocompletion, or vim inlay hints and virtual text, which can apply to much more than just signatures near method definitions. Types are much more useful where the code is used than where it is defined.
I follow a 1:1 lib/.rb - sig/.rbs convention and have projection+ files to jump from one to the other instantly.
And since the syntax of RBS is so close to Ruby I found myself accidentally writing things type-first then using that as a template to write the actual code.
Of note, if you crawl soutaro's repo (author of steep) you'll find a prototype of inline RBS.
+ used by vim projectionist and vscode projection extension
If you want something more similar to Next.JS but in the python world, now you have https://fastht.ml/, which also has a big performance benefit over Django. Hahaha, same as Next.JS over Rails, because it is much more bare bones. But I would say that fasthtml has the advantage of being super easy to integrate more AI libraries from the python world.
RoR is a beast, it has its place. The issue we have today is that everything is to fast paced, so fast that people feel the need to follow the latest and greatest, or they will be left behind.
This has (in my opinion) lead to a false sense that if something is not hyped as often, then its not used either.
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.
> At this point you can find tools that can make demos easier to build or get you further in a hackathon.
I don't understand this at all. ruby on rails is probably peak technology for getting something up an running fast at a hackathon. its a very streamlined experince with a ton of drop in plugins for getting to the product part of the mvp. Maintaining a ruby app is a nightmare overtime. At least it was 5 years ago the last time I worked fulltime in a startup using ruby on rails.
These days I use elixir. its higher performance and reasonably fast to write in but I woudln't say its as productive as ruby on rails if you're competing in a hackathon.
I don't really know if I would agree on saying that RoR failed, from recent my experiences, it's still a sought after tool for startups.
I do share your opinion on the untyped part, it's a bit of a bummer but there are gems to Ruby that helps with that.
Regarding the monkey patches, it's a concern many have and because of that, there is now a cleaner way of doing it! It's called a refinement. It's like monkey patching but in a more controlled way where you don't affect the global namespace.
The Go community is more framework-averse, preferring to build things around the standard library and generally reduce third-party dependencies. Go also tends to be used more for backends, services and infrastructure and less for fullstack websites than Ruby/Python/PHP/C#.
Or if you want more Next.JS like, but still fullstack framework there is https://leptos.dev/ and https://dioxuslabs.com/. Maybe dioxus being much more ambitious in its scope (not just web).
If you're willing to go the meta programming route, Rust is pretty flexible too. You can literally run python inline using macros.[1]
In my experience as someone that has been using Rust for a few years (and enjoys writing Rust) the biggest issue regarding adoption is that async Rust just isn't there yet when it comes to user experience.[2]
It works fine if you don't deviate from the simple stuff, but once you need to start writing your own Futures or custom locks it gets to a point that you REALLY need to understand Rust and its challenging type system.
Dynamically-typed scripting languages like Ruby and Python are well suited to a lot of the kinds of patterns used by the "easy" web frameworks. Once you get into a statically typed, compiled language, the language itself is oriented towards up-front formality which make various "convention-oriented" patterns awkward and ill-fitting to the language.
Ruby's super power is malleability. Rails isn't just a web framework in Ruby, it actually modifies Ruby to make it a web language.
It's the reason Ruby has been used to create so many DSLs too.
That creates the closest thing I've seen in the wild the Aspect Oriented Programming, as it was explained to me in grad school at least. The ecosystem is pretty incredible because of it.
I'm about as big of an Elixir fanboy as you'll ever meet, but I'm constantly mentally torn between Elixir and Rails as the best options for projects because of this aspect of Ruby.
I'm wondering this too. Lots of rust web promises, but so far all we have are Flask-likes, and statements-of-intent. Give it time?
If you ask about this in rust communities online, they will tell you they don't want something like this, that Actix etc do everything they need. I'm baffled! Maybe they're making microservices, and not web-sites or web apps?
I seem to observe that people drawn to rust are into systems programming and people drawn to rust are into minimal services programming and any attempts at building a batteries-included CRUD framework are so against the grain of the community’s common interest that it never goes anywhere.
Ruby, meanwhile, optimizes for programmer happiness and Rails optimizes for programmer productivity. What other language-framework ecosystem has the same values alignment?
I've heard this criticism a few times – the fear that LLMs will be bad at Rails because there's no types – and I don't think it's accurate.
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.
I think the reason strong types don't matter as much as we might assume is because Rails has very strong conventions. Routing lives in routes.rb, controllers go under app/controllers, most controllers or models will look very similar to other ones, etc.
Type information is something that has to be presented to the LLM at runtime for it to be accurate, but convention-over-configuration is stuff that it will have picked up in training data across thousands of Rails apps that look very similar.
On top of that, the core Rails stuff hasn't drastically changed over time, so there's lots of still-accurate StackOverflow questions to train on. (as opposed to something like Next.js which had a huge upheaval over app router vs pages router, and the confusion that would cause in training data).
In my opinion the future of LLM-aided Rails development seems pretty bright.
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!
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
I think types can help, but I don't think they're "strong" enough to overrule training data.
I just ran into an example of this trying to get it (Windsurf + Claude) to "rewrite this Objective C into Rust using the objc2 crate". It turns out objc2 made some changes and deprecated a bunch of stuff.
It's not figuring stuff out from base principles and reading the types to write this code, it's just going off of all the examples it was trained on that used the old APIs, so there's lots of errors and incorrect types being passed around. Hopefully it'll keep getting better.
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.
Interesting! What sort of stuff goes in the scaffold repo? Like examples of common patterns?
Definitely agree I think Ruby's closeness to natural language is a big win, especially with the culture of naming methods in self-explanatory ways. Maybe even moreso than in most other languages. Swift and Objective C come to mind as maybe also being very good for LLMs, with their very long method names.
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.
Hooray, I can replace accurate auto-complete with imaginary LLM suggestions! I use copilot and static types. Both are useful for auto-complete - traditional auto-complete gives accurate results with documentation popups; copilot gives higher level suggestions that are frequently nonsense (but right enough to be useful still).
In any case static types have many advantages, not just auto-complete. There's:
* refactoring
* finding references
* go to definition
* documentation
* bug prevention
LLMs are a million miles from being able to do any of that stuff automatically.
> Is the remaining 10% of “formal correctness” worth the extra volume of characters on the screen?
Yes, if only just for the ease of large-scale refactorings. And "extra volume of characters" is very limited if you use a modern language. In Haskell you could even not write a single type annotation in all of your code, although that's not recommended.
I doubt most people who like static types only do so because of autocomplete.
> 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?
The last time I tried this it created idiomatic code from scratch. I prompted it in phases though, and I suspect if I had asked it for more at once it might've used a generator.
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.
I haven't seen it run into a ton of issues like this when it can see all of the files, but I did hit issues where it would make guesses about how e.g. the Stripe gem's API worked and they'd be wrong.
Overall with Rails though, testing has always been pretty important partly because of the lack of types. I have noticed Windsurf is pretty good at taking a controller or model and writing tests for it though!
Readit News
https://www.contraption.co/a-mini-data-center/
(The CPU load from this is pretty negligible).
What else am I missing?
Of course back then we didn't use dynamic anything, a static web page worked.
Now get off my lawn!
And it wasn't static: We because peoples connections were mostly so slow, we used a CGI that shelled out to ping to estimate connection speed, and return either a static image (if you were on a dialup) or a fancy animated gif if you were on anything faster.
(the ping-test was obviously not reliable - if you were visiting from somewhere with high latency, you'd get the low bandwidth version too, no matter how high your throughput was - but that was rare enough; it worked surprisingly well)
Thousands and thousands of lines of quality conversation, interaction, humanity.
To be honest, I kind of miss those days.
I love to think that the web of the future is just going to be everyones' mac Mini or whatever.
Big Data™ has always irked me, frankly.
If you're considering k8s, take a look at Kamal (also from DHH): https://kamal-deploy.org/
I think it makes more sense for small clusters.
Why did you go for Cloudfare tunnel instead of wireguard?
I wrote a visualizer for the traffic that I think people will appreciate [1]. I will post it next month once I add it on github. It was fun to watch an article that went #1 on HN.
[1]: https://ibb.co/cXT3VNDR
Render is crazy expensive for blog sites and hobby apps.
https://gist.github.com/philipithomas/ed57890dc2f928658d2c90...
https://vincentwoo.com/3d/sutro_tower/
https://en.wikipedia.org/wiki/Mount_Olympus_(San_Francisco)
I run a windows server at my office where we connect to it using RDP from multiple locations. If I could instead buy the hardware and use cloudflare tunnels to let my team RDP to it then it would save me a lot of money. I could recoup my hardware cost in less than a year. Would this be possible?
(I wouldn't mind paying for cloudflare tunnels / zero trust. It just should be much smaller than the monthly payment I make to Microsoft)
I do think Cloudflare has proven itself to be very developer/indie-friendly. One of the only tech unicorns that really doesn't impose its morality on customers.
I'm pretty sure Tunnels supports RDP and if you don't use a ton of bandwidth (probably under a 1TB/mo), Cloudflare probably won't bother you.
My shorter-term goal is to switch my home internet to Starlink, so that all requests bounce off a satellite before landing at my desk.
I’ve had a number of database-driven sites hosted on $5/month VPS that have been on the front page here with minimal cpu or memory load.
https://developers.cloudflare.com/ssl/reference/certificate-...
The CPU is more powerful than I need. I didn't pass 8% utilization in the last 24 hours as HN slammed the box.
I had 2m35s of downtime due to power outages this week.
Now, however, what is the point? To learn server config? I am running my blog with GitHub pages. A couple of posts made it to the top of HN, and I never had to worry.
Always bewilders me when some sites here go down under load. I mean, where are they hosting it that a static page in 2020s has performance issues?
Contrast that, to more "app-y" patterns, that might have some unifying calendar, or mix things into a dashboard. Those patterns are also useful!! And of course, all buildable in rails as well. But there is something nice about the simplicity of CRUD apps when I end up coming across one.
So even though you can build in any style with whatever technology you want:
Rails feels like it _prefers_ you build "1 model = 1 concept = 1 REST entity"
Next.js (+ many other FE libraries in this react-meta-library group) feels like it _prefers_ you build "1 task/view = mixed concepts to accomplish a task = 1 specific 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).
However, I'm biased. A lot of my jobs have been writing "backoffice" apps, so there's usually models with a really clear identity associated to them, and usually connected to a real piece of paper like a shipment form (logistics), a financial aid application (edtech), or a kitchen ticket (restaurant POS).
Those sorts of applications I find break down with too many "Your school at a glance" sort of pages. Users just want "all the applications so I can filter to just the ones who aren't submitted yet and pester those students".
And like many sibling comments mention, Rails has some good answers for combining rest entities onto the same view in a way that still makes them distinct.
Multiple models managed on a single page, each with their own controllers and isolated views.
This is fine!
> I've fought the urge to use graphql for years
Keep fighting the urge. Or give into it and learn the hard way? Either way you'll end up in the same place.
The UI can make multiple calls to the backend. It's fine.
Or you can make the REST calls return some relations. Also fine.
What you can't do is let the client make arbitrary queries into your database. Because somebody will eventually come along and abuse those APIs. And then you're stuck whitelisting very specific queries... which look exactly like REST.
Like the Read for a dashboard could have a controller for each dashboard component to load its data or it could have one controller for the full dashboard querying multiple models - still CRUD.
The tight coupling is one of many approaches and common enough to be made default.
Separate entities on the backend - a unified update view if that’s what’s desired.
No need for any outside dependencies.
It's seemingly more work than graphql as you need to actually intentionally build your API, but it gets you fewer, more thought-out usage patterns on the backend that are easier to scale.
https://www.youtube.com/watch?v=aOk67eT3fpg&ab_channel=Theo-...
Deleted Comment
Rails really doesn't encourage this architecture, quite the opposite in fact.
> designers and users of the applications I have been building for years never want just one model on the screen.
... and this is where Rails excels. When you need to pull in some more data for a screen you just do it. Need to show the most recent reviews of a product in your e-commerce backend? It's probably as simple as:
Of course this can have the opposite problem of bloated views taking forever to load, but Rails has lots of caching goodies to mitigate that.---
Going back to the GP post
> Rails feels like it _prefers_ you build "1 model = 1 concept = 1 REST entity"
That's definitely the simple path, but there are very few constraints on what you can do.
So you end up having to put depth and quantity limits, or calculating the cost of every incoming query before allowing it. Another approach I'm aware of is whitelisting but that seems to defeat the entire point.
I use rest for new projects, I wouldn't say never to graphql, but it brings a lot of initial complexity.
Dead Comment
I really like easy problems too. Unfortunately, creating database records is hardly a business. With a pure CRUD system you're only one step away from Excel really. The business will be done somewhere else and won't be software driven at all but rather in people's heads and if you're lucky written in "SOP" type documents.
There are two types of complexity: essential and incidental. Sometimes, a straightforward CRUD app won't work because the product's essential complexity demands it. But at least as often, apps (and architectures, and engineering orgs, and businesses) are really just CRUD apps with a bunch of incidental complexity cluttering up the joint and making everything confusing, painful, and expensive.
I've served dozens of clients over my career, and I can count on one hand the number of times I've found a company whose problem couldn't more or less be solved with "CRUD app plus zero-to-one interesting features." No technologist wants to think they're just building a series of straightforward CRUD apps, so they find ways to complicate it. No businessperson wants to believe their company isn't a unique snowflake, so they find ways to complicate it. No investor wants to pour their money into yet another CRUD app, so they invent a story to complicate it.
IME, >=90% of application developers working today are either building CRUD apps or would be better off if they realized they were building CRUD apps. To a certain extent, we're all just putting spreadsheets on the Internet. I think this—more than anything else—explains Rails' staying power. I remember giving this interview on Changelog ( https://changelog.com/podcast/521 ) and the host Adam asking about the threat Next.js posed to Rails, and—maybe I'd just seen this movie too many times since 2005—it didn't even register as a possible contender.
Any framework that doesn't absolutely nail a batteries-included CRUD feature-set as THE primary concern will inevitably see each app hobbled with so much baggage trying to roundaboutly back into CRUD that it'll fall over on itself.
Too many degrees of freedom can degrade an experience, if not used properly.
> Rails has started to show its age amid with the current wave of AI-powered applications.
Not everything needs to have bloody AI.
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.
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.
And even if it did, the Ruby eco-system has AI stuff...
Not at all my experience, actually it was incredibly easy to get this working smoothly with hotwire and no javascript at all (outside the hotwire lib).
We have a Rails app with thousands of users streaming agentic chat interfaces, we've had no issues at all with this aspect of things.
A lot of them prefer to write Ruby because it is simply the most beautiful language they know of. Technical details are merely a formality expressed in code that borders art.
I was under the impression the industry was collectively moving in that direction, but then bootcamps ushered in a new era of midwit frontend developers hell bent on reinventing the wheel from scratch (poorly).
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.
React is a good choice if you’ve got a huge dev team that can split things into components and independently work on things but otherwise React is so full of footguns that it’s almost comical that people choose it for anything other than bloated VC projects.
A plug for Django + gevent in this context! 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. For streaming and any kind of IO-bound parallelism, gevent's monkey-patches cause every blocking operation to become a event-loop yield... so you can stream many concurrent responses at a time, with a simple generator. CPU-bound parallelism doesn't have a great story here, but that's less relevant for web applications - and if you're simultaneously iterating on ML models and a web backend, they'd likely run on separate machines anyways, and you can write both in Python without context-switching as a developer.
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.)
Generally I'd say any senior rails dev, given the right task, can write decent elixir code on their first day. There are a lot fewer foot guns in elixir and Phoenix, and so other than language ergonomics (a simple rule that doesn't stretch far but works at the beginning is use pipe instead of dot), there's minimal barriers
</shamelessselfplug>
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.
I am one of the authors of RDL (https://github.com/tupl-tufts/rdl) a research project that looked at type systems for Ruby before it became mainstream. We went for strings that looked nice, but were parsed into a type signature. Sorbet, on the other hand, uses Ruby values in a DSL to define types. We were of the impression that many of our core ideas were absorbed by other projects and Sorbet and RBS has pretty much mainstream. What is missing to get usable gradual types in Ruby?
When I do need types inline I believe it is the editor's job to show them dynamically, e.g via facilities like tooltips, autocompletion, or vim inlay hints and virtual text, which can apply to much more than just signatures near method definitions. Types are much more useful where the code is used than where it is defined.
I follow a 1:1 lib/.rb - sig/.rbs convention and have projection+ files to jump from one to the other instantly.
And since the syntax of RBS is so close to Ruby I found myself accidentally writing things type-first then using that as a template to write the actual code.
Of note, if you crawl soutaro's repo (author of steep) you'll find a prototype of inline RBS.
+ used by vim projectionist and vscode projection extension
This has (in my opinion) lead to a false sense that if something is not hyped as often, then its not used either.
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.
I don't understand this at all. ruby on rails is probably peak technology for getting something up an running fast at a hackathon. its a very streamlined experince with a ton of drop in plugins for getting to the product part of the mvp. Maintaining a ruby app is a nightmare overtime. At least it was 5 years ago the last time I worked fulltime in a startup using ruby on rails.
These days I use elixir. its higher performance and reasonably fast to write in but I woudln't say its as productive as ruby on rails if you're competing in a hackathon.
Feel.
I’ve started qualifying such statements… “you mean a real engineer or just a software developer?
I do share your opinion on the untyped part, it's a bit of a bummer but there are gems to Ruby that helps with that.
Regarding the monkey patches, it's a concern many have and because of that, there is now a cleaner way of doing it! It's called a refinement. It's like monkey patching but in a more controlled way where you don't affect the global namespace.
https://docs.ruby-lang.org/en/master/syntax/refinements_rdoc...
https://charliereese.ca/y-combinator-top-50-software-startup...
Go and Rust are amazing languages, but why can’t they produce a Rails-like framework?
Is it just a matter of time before Go/Rust create a Rails-like framework, or is something fundamental preventing it?
Perhaps this article by Patrick Li (author of Stanza language) has the answers [1].
[1] Stop Designing Languages. Write Libraries Instead:
https://lbstanza.org/purpose_of_programming_languages.html
The Go community is more framework-averse, preferring to build things around the standard library and generally reduce third-party dependencies. Go also tends to be used more for backends, services and infrastructure and less for fullstack websites than Ruby/Python/PHP/C#.
The key to Rails is the Ruby language, it's very flexible. Someone were able to meta program Ruby code to the point that it was able to run JS code.
In my experience as someone that has been using Rust for a few years (and enjoys writing Rust) the biggest issue regarding adoption is that async Rust just isn't there yet when it comes to user experience.[2]
It works fine if you don't deviate from the simple stuff, but once you need to start writing your own Futures or custom locks it gets to a point that you REALLY need to understand Rust and its challenging type system.
[1] - https://github.com/m-ou-se/inline-python
[2] - https://blog.rust-lang.org/images/2024-02-rust-survey-2023/w... | (Full Survey: https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Surve...)
It's the reason Ruby has been used to create so many DSLs too.
That creates the closest thing I've seen in the wild the Aspect Oriented Programming, as it was explained to me in grad school at least. The ecosystem is pretty incredible because of it.
I'm about as big of an Elixir fanboy as you'll ever meet, but I'm constantly mentally torn between Elixir and Rails as the best options for projects because of this aspect of Ruby.
If you ask about this in rust communities online, they will tell you they don't want something like this, that Actix etc do everything they need. I'm baffled! Maybe they're making microservices, and not web-sites or web apps?
Ruby, meanwhile, optimizes for programmer happiness and Rails optimizes for programmer productivity. What other language-framework ecosystem has the same values alignment?
I've heard this criticism a few times – the fear that LLMs will be bad at Rails because there's no types – and I don't think it's accurate.
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.
I think the reason strong types don't matter as much as we might assume is because Rails has very strong conventions. Routing lives in routes.rb, controllers go under app/controllers, most controllers or models will look very similar to other ones, etc.
Type information is something that has to be presented to the LLM at runtime for it to be accurate, but convention-over-configuration is stuff that it will have picked up in training data across thousands of Rails apps that look very similar.
On top of that, the core Rails stuff hasn't drastically changed over time, so there's lots of still-accurate StackOverflow questions to train on. (as opposed to something like Next.js which had a huge upheaval over app router vs pages router, and the confusion that would cause in training data).
In my opinion the future of LLM-aided Rails development seems pretty bright.
https://hexdocs.pm/instructor/Instructor.html
Someone in Rails land could build similar and voila.
I just ran into an example of this trying to get it (Windsurf + Claude) to "rewrite this Objective C into Rust using the objc2 crate". It turns out objc2 made some changes and deprecated a bunch of stuff.
It's not figuring stuff out from base principles and reading the types to write this code, it's just going off of all the examples it was trained on that used the old APIs, so there's lots of errors and incorrect types being passed around. Hopefully it'll keep getting better.
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.
Definitely agree I think Ruby's closeness to natural language is a big win, especially with the culture of naming methods in self-explanatory ways. Maybe even moreso than in most other languages. Swift and Objective C come to mind as maybe also being very good for LLMs, with their very long method names.
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.
In any case static types have many advantages, not just auto-complete. There's:
* refactoring
* finding references
* go to definition
* documentation
* bug prevention
LLMs are a million miles from being able to do any of that stuff automatically.
Yes, if only just for the ease of large-scale refactorings. And "extra volume of characters" is very limited if you use a modern language. In Haskell you could even not write a single type annotation in all of your code, although that's not recommended.
I doubt most people who like static types only do so because of autocomplete.
Does it suggest using rails generators for this - and/or does it give you idiomatic code?
With Ruby, it doesn't have as much information, so it has to rely on testing or linters for feedback.
Overall with Rails though, testing has always been pretty important partly because of the lack of types. I have noticed Windsurf is pretty good at taking a controller or model and writing tests for it though!