_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Why Ruby on Rails still matters
thdhhghgbhy wrote 6 hours 54 min ago:
I miss writing Ruby.
mathgladiator wrote 22 hours 59 min ago:
I've started to use PHP again because AI deals with it nearly perfectly
such that I can focus entirely on the product without trivia deep
dives.
raintrees wrote 23 hours 19 min ago:
"Developers choose Rails today because, 20 years later, it remains the
most simple and abstracted way to build a web application."
Well, then there are those of us who use Django for similar reasons :)
y0ssar1an wrote 1 day ago:
You know a language is dying when you start seeing articles like this.
pgcosta wrote 1 day ago:
"It struggles with LLM text streaming, parallel processing in Ruby[3],
and lacks strong typing for AI coding tools."
What's the struggle specifically?
How these general articles of opinion get to the first page of HN I'll
never understand.
Just random statements without anything to back them up.
stevev wrote 1 day ago:
I love Ruby. However, based on my readings, Rust, rocket, seems like a
compelling choice due to its true parallel processing capabilities,
strong typing, and impressive speed. Perhaps the author has yet to
explore other technologies outside of Rails.
the__alchemist wrote 1 day ago:
Along this vein: I learned programming ~15 years ago. On my own, as a
hobby. Now it's a hobby and day job. Lots of tech churn in this time
period. I've branched out into many domains.
The constant that's been with me from start to end: Django. Because
it's fantastic and versatile. I still am kind of bitter the tutorial I
followed wasted so much time on tangents regarding VirtualBox, Vagrant,
Chef... I program most things in rust, but not web, because there is
nothing there that compares.
Sparkyte wrote 1 day ago:
As someone who directly worked on Ruby on Rails with developers, their
worflows and deployments. It is far too niche to be viable in the
mainstream and provides even less incentive to newer languages.
But it is a fun language.
Also latest Python is faster than the current Ruby let that sink in.
You can go even faster if you do a compiled Python like PuPu.
m11a wrote 1 day ago:
It's still my favourite web framework. I just wish the Ruby language
had better support for type annotations (like Python does). Then it'd
be sorta perfect for me
revskill wrote 1 day ago:
Not adopting SPA architecture is the MAIN mistake of DHH and RoR
committee.
Calamitous wrote 9 hours 40 min ago:
I'd argue it's the main benefit.
teleforce wrote 1 day ago:
It's very interesting to note that you can build and maintain meta web
framework like RoR with Ruby, Django and even D language.
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] Stop Designing Languages. Write Libraries Instead:
URI [1]: https://lbstanza.org/purpose_of_programming_languages.html
brightball wrote 20 hours 49 min ago:
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.
do_anh_tu wrote 23 hours 58 min ago:
I would love to see RoR/Django but in Julia. Performance and easy to
read code.
zzzeek wrote 1 day ago:
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.
the__alchemist wrote 1 day ago:
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?
searls wrote 21 hours 11 min ago:
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?
the__alchemist wrote 19 hours 50 min ago:
Makes sense. My thought is, while Rust shines in a low-level
setting,(Systems programming, embedded, performance-sensitive
scientific computing etc) it has enough niceties that I want to
use it elsewhere. Package management, enums, result and option
types, clear error messages, expressive data structures etc.
These are (to me) not enough to make up for the lack of a
batteries-included web framework.
modernerd wrote 1 day ago:
Loco is worth keeping an eye on for Rust: [1] 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#.
URI [1]: https://loco.rs/
jackbravo wrote 1 day ago:
Or if you want more Next.JS like, but still fullstack framework
there is [1] and [2] . Maybe dioxus being much more ambitious in
its scope (not just web).
URI [1]: https://leptos.dev/
URI [2]: https://dioxuslabs.com/
Alifatisk wrote 1 day ago:
> Is it just a matter of time before Go/Rust create a Rails-like
framework
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.
oparin10 wrote 17 hours 18 min ago:
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. [1] - [1] [2] - [2] | (Full Survey: [3] )
URI [1]: https://github.com/m-ou-se/inline-python
URI [2]: https://blog.rust-lang.org/images/2024-02-rust-survey-2023...
URI [3]: https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Sur...
Alifatisk wrote 6 hours 4 min ago:
> If you're willing to go the meta programming route, Rust is
pretty flexible too. You can literally run python inline using
macros.[1]
I didnât mean like embed another languages runtime, I meant
that they monkey patched Ruby to the point that they where able
to run Javascript syntax as if it was plain javascript code.
It didnât have the js runtime embedded, it was all still Ruby.
The point was to showcase how much you can flex and bend the
language and turn it into whatever DSL you like.
Iâve been trying to find the video but canât find it, I
believe itâs from RubyCon.
matt-p wrote 1 day ago:
"Next.js enabled websites to approach iPhone app quality."
This is a fascinating perspective, because building PWAs with raw js
and very early react I always felt these were as good as iPhone app
quality.
globular-toast wrote 1 day ago:
I haven't actually used RoR, but I've used Django extensively and
understand they are fairly similar. How do people build things that
aren't just CRUD? Django calls itself a "web framework" but I think
that's wrong, it's a CRUD app framework. Is RoR the same?
The main problem I have is the mixing up of low-level logic like web
and database etc with high-level logic (ie. business rules). The easy
path leads to a ball of mud with duplicated business rules across views
and forms etc. How are people dealing with this? Does RoR fit into a
larger application architecture where it does just the CRUD part and
some other systems take over to do the business part?
It always seems to start well, you have your models, and views just
doing CRUD stuff. But then someone says "I don't want to have to create
an author before I create a book, let me enter new author details when
I enter a book", and then the whole thing breaks. You need some logic
somewhere to create authors but only in certain cases and of course the
whole thing needs to be one transaction etc. Then you end up basically
undoing all the simple views you did and essentially fighting the
system to handle logic it was never designed to handle.
In essence, these systems make the easy stuff easy and the hard stuff
even harder.
Tainnor wrote 1 day ago:
You can certainly write complex applications in Rails that go beyond
CRUD. But in my experience (which may be outdated, I haven't written
Rails in years), it requires a lot of discipline and going beyond
what Rails itself offers. Sometimes you may even have to fight some
of Rails's conventions.
There are some people who have tried to abstract such things into yet
another framework on top of Rails, e.g. I recall Trailblazer[0], but
I have no idea if anyone still uses it.
[0]:
URI [1]: https://trailblazer.to/2.1/
neonsunset wrote 1 day ago:
It does not when ASP.NET Core exists. UX just as good or even better,
10x performance.
kilroy123 wrote 1 day ago:
I so wish we had Rails for JavaScript. Many have tried but no
equivalent exists.
DeathArrow wrote 1 day ago:
>It became the foundation for numerous successful companies
And after the MVP phase passed and the company became successful, they
usually rewrote the software in something else.
forgingahead wrote 1 day ago:
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.
procaryote wrote 1 day ago:
You don't do it for fun*, but because the rapid development
duck-typed dynamic language you used to get to MVP quickly is not
the language you need to keep it working under load and a growing
feature set.
It's a terrible and difficult transition that makes you question if
the first language was really such a good choice after all,
although it did get you where you are right now, which is more than
you can say for a bunch of companies trying to do everything future
proof from day 0
(* well, some people do, but they don't tend to survive)
cowsandmilk wrote 1 day ago:
I can point to plenty of companies that have rewritten products at
scale. That said, specifically relevant to the article, I believe
Shopify and GitHub continue to run Ruby on Rails.
willsmith72 wrote 17 hours 12 min ago:
shopify is hugely invested in react and even full stack react
through react router. still rails is great for the backend of
course
thr0waway001 wrote 1 day ago:
I haven't learned PHP nor Ruby but if I had to go with one it would be
PHP. Seems like I'd get the most utility out of it and prospects in my
area.
In fact, I've never seen a RoR job posted in my area. Mostly PHP,
Python and JS.
But you know, you gotta give credit where credit is due. Laravel would
not be a thing if it weren't for RoR. RoR was incredibly influential.
Ok, so maybe I exaggerated, I've dabbled in these languages. Not really
formally learned them. Or at least .... I can't say I've learned them
if I haven't done any paid work with them.
JodieBenitez wrote 1 day ago:
> In fact, I've never seen a RoR job posted in my area. Mostly PHP,
Python and JS.
The trick is to get jobs where people don't care about your tools but
only the results. And then you can use whatever tools you want. Did
that long ago with Django when there was literally no Python jobs in
my area.
cjohnson318 wrote 1 day ago:
I think Rails's big contribution is the idea of convention over
configuration. Maybe this my own myopia, but Django feels like Rails,
and NextJS also borrows from Rails. I've only managed one Rails project
in production, and I had to come up to speed really fast to support it,
but I loved it.
cratermoon wrote 1 day ago:
COBOL still matters, too.
Would I chose to start a new project with it today, in 2025?
Hell naw.
jes5199 wrote 1 day ago:
itâs been quite a few years since Iâve worked in Rails, but I miss
it sometimes. None of the other platforms ever completely replicated
the functionality of a standard Rails environment circa 2009, so we
reinvent the wheel every time. Basic stuff, too: ORM hooks,
validations. Itâs always a relief when I get to work with someone who
has also worked on Rails before, because it means we have a shared
vocabulary - thereâs no equivalent thing among Python programmers, or
JVM programmers, or anywhere else that Iâm aware of
darkhorse13 wrote 1 day ago:
Django is exactly that for Python.
jes5199 wrote 23 hours 15 min ago:
then why do I keep ending up having to support hand-rolled
SqlAlchemy and FastAPI
troad wrote 1 day ago:
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.
simonask wrote 1 day ago:
As a rustacean, I completely agree. A big chunk of the Rust
ecosystem is obsessed with performance, and sees static typing as
the way to achieve that. This approach generates extremely
efficient code, but blows up compile times and creates a messy hell
of generics (and accompanying type check errors).
I think there is a space for a more dynamic and high-level web
framework in Rust, with an appropriate balance between leveraging
the powerful type system and ease of use.
danhaywood wrote 1 day ago:
For JVM, Apache Causeway provides similar capabilities (in fact, even
more abstracted than RonR). Full disclosure: I'm a committee on that
project.
URI [1]: https://causeway.apache.org
ehnto wrote 1 day ago:
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.
pmarreck wrote 1 day ago:
Of course it still matters.
What else would both teach programmers that nice languages exist, and
that OOP leads to a nondeterministic spaghetticode hellscape? ;)
(I once spent an entire month debugging a transient login issue
(session loss bug) on a million-line RoR app. Most of the bug ended up
being something which merged a HashWithIndifferentAccess with a regular
Hash, and key overwrite was nondeterministic. This type of bug is
doubly impossible in something like Elixir- both since it is
data-focused and not inheritance-focused, and because it is immutable.)
Tainnor wrote 1 day ago:
HashWithIndifferentAccess is one of these IMHO stupid design
decisions of Rails that sacrifice maintainability (and consistency
with Ruby, the language) just for the sake of making things slightly
easier to write.
yayitswei wrote 1 day ago:
I wouldn't say Rails is the most simple and abstracted way to build a
web application. More so than Next.js, yes, but there are both older
and newer technologies that keep things simpler.
jrochkind1 wrote 1 day ago:
Such as?
yayitswei wrote 1 day ago:
Simple and abstract are subjective, but for me: PHP, jQuery, htmx,
Electric Clojure.
czhu12 wrote 1 day ago:
Rails makes me really appreciate the dictatorial nature of it (dhh).
Compared to the free for all landscape in javascript, Rails moves a lot
slower, but decisively.
I started using rails in 2014, and I think this is some of the most
exciting days in rails. Hotwire, Turbo, Stimulus + no build JS pushed
the framework into what feels like next generation web development.
While all the same patterns exist in javascript, it seems like there
are 5, 6, 7, 8 ways to do everything. Something as trivial as
authentication has multiple implementations online, with multiple
libraries, which is hugely frustrating.
Sincere6066 wrote 1 day ago:
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.
Not everything needs to have bloody AI.
pmontra wrote 1 day ago:
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.
troad wrote 1 day ago:
> 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.
zdragnar wrote 1 day ago:
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.
GuardianCaveman wrote 1 day ago:
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.
einsteinx2 wrote 1 day ago:
This kind of thing scares me knowing how bad AI meeting and
document summaries are, at least what Iâve used. Missing key
details, misinterpreting information, hallucinating things that
werenât saidâ¦boy I canât wait for my doctor to use an AI
summary of my visit to incorrectly diagnose me!
gddgb wrote 19 hours 41 min ago:
Donât care doctors in the US flat out lie. I would pay
thousands for this services, it would have saved me more.
dismalaf wrote 1 day ago:
> Not everything needs to have bloody AI.
And even if it did, the Ruby eco-system has AI stuff...
philip1209 wrote 1 day ago:
ankane to the rescue, as normal
dismalaf wrote 1 day ago:
True hah. Of course even if they didn't already most AI libs are
actually C++ libs that Python interfaces with, and Ruby has
probably the best FFI of any language.
fijiaarone wrote 1 day ago:
I only read the first sentence, but try running a Next.js app from 2
years ago.
Good luck with that.
mulnz wrote 1 day ago:
No.
henning wrote 1 day ago:
"Another trillion dollars worth of companies is being built on Next.js,
and these web apps are faster and more polished than what could have
been built on Ruby on Rails."
This makes absolutely no sense. HTTP is HTTP. Maybe one framework makes
something more convenient than the other, but more "polished"? What
does that even mean and what exactly is Next.js enabling?
lenerdenator wrote 1 day ago:
RoR is great. Ruby just needs to grow beyond it.
I worked at a company that, when faced with the choice between
rewriting its Django apps in Python 3, and rewriting them in RoR,
decided to go with the latter.
Now, I didn't like that since I was on an undermanned team that had
literally just started a major update of a Django site, and it arguably
wasn't the right way to go business-wise, but a lot of ideas that have
come into Django over the years were ideas that existed in RoR.
I'd like to see that sort of innovation happen in some of the other
spaces that Python is in, if for no other reason than to prevent
monoculture in those areas. There needs to be offerings for Ruby in
other areas, like scientific computing, machine learning/AI, and data
analysis that get the same uptake that Rails does.
Levitating wrote 23 hours 48 min ago:
> I'd like to see that sort of innovation happen in some of the other
spaces that Python is in
I think the language itself is definitely good enough to support the
things Python does. But Ruby lacks in things like documentation and
standards. RDoc isn't great, neither is bundler and there's no
alternative to PEP.
Ruby's ecosystem does have some interesting alternatives to Pythons
ecosystem. Like Numo for numpy, and Jupyter also supports ruby. But
for a matplotlib alternative you have to bind to gnuplot.
I still use Ruby much more than Python anyway, my scripts often don't
need external packages and Ruby as a language is such a delight to
work with.
UncleOxidant wrote 1 day ago:
> It became the foundation for numerous successful companies - Airbnb,
Shopify, Github, Instacart, Gusto, Square, and others. Probably a
trillion dollars worth of businesses run on Ruby on Rails today.
Do those companies still run their businesses on RoR? My impression was
that companies started out with it, but migrated to something more
robust as their traffic grew.
pianoben wrote 1 day ago:
Instacart had an engineer presenting at Rails World 2024 just a few
months ago; they're still heavily invested in the platform.
Levitating wrote 1 day ago:
Airbnb, Shopify and GitHub I can say never migrated away from RoR.
The others I don't know.
Shopify is actually quite active in Ruby development and famously
uses the new JIT compiler.
troad wrote 1 day ago:
Shopify made the new Ruby JIT compiler. [0] They're on the Rails
Foundation, as is 1Password, among others.
Stripe is still in on Ruby too; they're behind the Sorbet gradual
type system, and Ruby is a first-class language for working with
their API.
I always hear the stereotype of companies starting on Rails and
migrating later, and I think it sticks around because it makes some
level of intuitive sense, but it doesn't actually appear to happen
all that often. I guess successful companies don't see the need to
rewrite a successful codebase when they can just put good engineers
to work on optimising it instead.
[0]
URI [1]: https://shopify.engineering/ruby-yjit-is-production-ready
philip1209 wrote 1 day ago:
I know for sure Shopify, Github, and Gusto are big Rails shops.
Amazon was recently hiring for Rails to work on a podcast app they
bought, too.
tate_thurston wrote 1 day ago:
Yep, Iâm at Amazon, now working on said podcasting subsidiary,
ART19. Weâre a rails shop.
There are a few acquisition companies and teams using Rails inside
Amazon.
rednafi wrote 1 day ago:
I feel the same, but for Django, even though I donât write Python as
much these days.
openplatypus wrote 1 day ago:
RoR needs to distance itself from DHH to matter.
dismalaf wrote 1 day ago:
Literally everything interesting about RoR is because of DHH.
Hotwire, Import Maps, Kamal, etc...
werdnapk wrote 1 day ago:
Why? That's like somebody saying Linux has to distance itself from
Linus because they have some sort of grudge against them or they
don't like the authoritarian position they have over the project.
mostlysimilar wrote 1 day ago:
> Rails has started to show its age amid with the current wave of
AI-powered applications.
A feature, not a bug. Rails will continue to be good for building
things long after the AI boom has died down.
krashidov wrote 1 day ago:
> Many of today's most polished products, like Linear and ChatGPT
launched as Next.js applications, and treated mobile apps as secondary
priorities.
Linear was started on next.js? I thought they built a custom sync
engine? [1] I feel like this article is hyping up the importance of
next.js.
URI [1]: https://linear.app/blog/scaling-the-linear-sync-engine
jeremy_k wrote 1 day ago:
The data layer is an orthogonal choice to the frontend framework /
library.
You could use Next.js + any API to create an application.
You could use Next.js + a sync engine to create an application.
You could use React Router + Vite + any API to create an application.
You could use React Router + Vite + a sync engine to create an
application.
krashidov wrote 1 day ago:
Isn't next.js a full stack framework though? Like can't you have it
do server side rendering?
URI [1]: https://nextjs.org/docs/app/building-your-application/data...
matijash wrote 1 day ago:
Full-stack is an overloaded term, but it used to mean "a completr
solution for building a web app."
From the comment above: Next.js is the opposite of a "batteries
included" framework. No abstractions for ORM, background jobs,
sending emails, managing attachments, web socket communication -
all very basic stuff when dealing with a production application.
hombre_fatal wrote 1 day ago:
Next.js solves the hard thing of server rendering + frontend
hydration of JS components.
So if that's the battery that you need, pretty much nothing
else has it except for Next.js.
These days, I tend to want a web framework to do the hard
things for me rather than the tedious/boilerplate but simple
things like email-sending.
krashidov wrote 22 hours 29 min ago:
Right so if you built your own sync engine why would you use
next.js?
matijash wrote 1 day ago:
Ruby on Rails has an amazing DX (e.g. engines). We are trying to
recreate that for JS with Wasp ( [1] )
URI [1]: https://github.com/wasp-lang/wasp
dceddia wrote 1 day ago:
> lacks strong typing for AI coding tools
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.
Glyptodon wrote 1 day ago:
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.
janee wrote 1 day ago:
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.
dceddia wrote 1 day ago:
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.
janee wrote 1 day ago:
it's fairly bespoke, but some examples:
ETL pipelines, we catalogue and link our custom transformers to
bodies of text that describes business cases for it with some
examples, you can then describe your ETL problem in text and it
will scaffold out a pipeline for you.
Fullstack scaffolds that go from models to UI screen, we have
like a set of standard components and how they interact and
communicate through GraphQL to our monolith (e.g. server side
pagination, miller column grouping, sorting, filtering, PDF
export, etc. etc.). So if you make a new model it will scaffold
the CRUD fully for you all the way to the UI (it get's some stuff
wrong but it's still a massive time save for us).
Patterns for various admin controls (we use active admin, so this
thing will scaffold AA resources how we want).
Refactor recipes for certain things we've deprecated or improved.
We generally don't migrate everything at once to a new pattern,
instead we make "recipes" that describe the new pattern and point
it to an example, then run it as we get to that module or lib for
new work.
There are more, but these are some off the top of my head.
I think a really big aspect of this though is the integration of
our scaffolds and recipes in Cursor. We keep these scaffold
documents in markdown files that are loaded as cursor notepads
which reference to real source code.
So we sort of rely heavily on the source code describing itself,
the recipe or pattern or scaffold just provides a bit of extra
context on different usage patterns and links the different
pieces or example together.
You can think of it as giving an LLM "pro tips" around how things
are done in each team and repo which allows for rapid scaffold
creation. A lof of this you can do with code generators and good
documentation, but we've found this usage of Cursor notepads for
scaffolds and architecture is less labour intensive way to keep
it up to date and to evolve a big code base in a consistent
manner.
---
Edit: something to add, this isn't a crutch, we require our devs
to fully understand these patterns. We use it as a tool for
consistency, for rapid scaffold creation and of course for
speeding up things we haven't gotten around to streamlining (like
repetitive bloat)
snickell wrote 1 day ago:
I suspect long-term LLMs spell the end of typed language popularity
in most application programming contexts.
I agree with The Grug Brained Developer ( [1] ) 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.
URI [1]: https://grugbrain.dev/
IshKebab wrote 17 hours 28 min ago:
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.
Tainnor wrote 1 day ago:
> 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.
e12e wrote 1 day ago:
> 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?
dceddia wrote 1 day ago:
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.
Kerrick wrote 1 day ago:
See also:
URI [1]: https://gist.github.com/peterc/214aab5c6d783563acbc2a9425e5e...
sergiotapia wrote 1 day ago:
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! [1] Someone in Rails land could
build similar and voila.
URI [1]: https://hexdocs.pm/instructor/Instructor.html
freedomben wrote 1 day ago:
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
dceddia wrote 1 day ago:
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.
philip1209 wrote 1 day ago:
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.
dceddia wrote 1 day ago:
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!
xpe wrote 1 day ago:
To go in the other direction, static site generators (SSGs) also have a
place on the menu. Build locally. Host them on your favorite CDN. I
personally really like Zola (Rust), inspired by Hugo (Go).
hombre_fatal wrote 1 day ago:
Fwiw, Next.js has a solution for that:
URI [1]: https://nextjs.org/docs/pages/building-your-application/rend...
aosaigh wrote 1 day ago:
Is Next.js really that popular? What else are people building back-end
applications with? Are they just NOT building back-end applications and
moving to services like Next.js with function-based hybrid backends?
saltcod wrote 22 hours 1 min ago:
Yes and yes.
ram_rar wrote 1 day ago:
Starting today in what scenario would RoR would be a better option than
Next.js for building web app? Assuming one has to start from 0 -> 1 .
moojacob wrote 21 hours 55 min ago:
Iâve worked two summers on a Next.js app and Rails for a side
project that Iâve spent 300 hours on. I would choose Rails if the
interactivity could be made only with forms. Rails is simpler,
opinionated, but a lot less powerful. But I was making a whiteboard
which is super interactive Iâd choose next.js. The con with Next.js
is itâs just more complicated, some of my coworkers often shot
themselves in the foot by not putting code inside useEffect
prh8 wrote 1 day ago:
Almost all scenarios
taormina wrote 1 day ago:
I mean, any scenario? I'm not trying to be snarky but server-side
Javascript has always been a weird code smell from first premise.
Now, when to use RoR vs a lighter-weight framework like Sinatra is a
more interesting question, but it's about what you need out of the
box.
verisimilidude wrote 1 day ago:
Server-side JS is fine, and actually very nice in some contexts.
The language and runtime(s) have come a long way.
But anyone who tries it without really understanding JS is
eventually going to have a bad time. Itâs important to know how
to work with the event loop, how to properly use promises, etc.
Server-side JS is a lot more unforgiving than front-end JS when it
comes to these concepts.
Glyptodon wrote 1 day ago:
I don't hate NextJS or anything, but I've never met a JS backend that
I loved a whole lot compared to a conventional Rails one. They always
turn out to be missing little details and trying to fill them in
always like round hole square peg misalignment that just never quite
ends.
philip1209 wrote 1 day ago:
I outline two in the article:
1. One-person software project
2. Complex enterprise app with lots of tables, like a vendor
management system.
usernamed7 wrote 1 day ago:
After all these years, rails is still my favorite framework to build
with. Although I have become increasingly bored/frustrated with the
front-end development in rails, which lacks a solid rails-way.
caseyohara wrote 1 day ago:
> front-end development in rails, which lacks a solid rails-way.
Hotwire/Turbo/Stimulus with import maps is the prescribed way.
Tailwind is emerging as the preferred CSS lib.
philip1209 wrote 1 day ago:
Have you checked out Hotwired? [1] This book has a good intro with
more advanced patterns:
URI [1]: https://hotwired.dev
URI [2]: https://railsandhotwirecodex.com/
mati365 wrote 1 day ago:
One of the biggest issues is that newer tools often lack Rails
integrations. I recently built one for CKEditor - happy to share
details if anyone's interested.
URI [1]: https://github.com/Mati365/ckeditor5-rails?tab=readme-ov-file
philip1209 wrote 1 day ago:
This Youtube series was doing some cool things integrating TipTap,
but never finished:
URI [1]: https://www.youtube.com/watch?v=XWfyffFWbDI
canadiantim wrote 1 day ago:
Does Django still matter too?
JodieBenitez wrote 1 day ago:
Yes.
pphysch wrote 1 day ago:
I think anything that applies to RoR applies equally to Django.
RoR got there first, but Python is a more relevant PL with broad
ecosystem.
I would always recommend learning Django over RoR, unless you
specifically want to learn a niche language.
btown wrote 1 day ago:
> 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.
jackbravo wrote 1 day ago:
If you want something more similar to Next.JS but in the python
world, now you have [1] , 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.
URI [1]: https://fastht.ml/
zzzeek wrote 1 day ago:
now that was a crazy rabbit hole
troad wrote 1 day ago:
> 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.
lloeki wrote 1 day ago:
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
sankha93 wrote 1 day ago:
Do you mean Ruby lacks syntactic support for adding type
annotations inline in your programs?
I am one of the authors of RDL ( [1] ) 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?
URI [1]: https://github.com/tupl-tufts/rdl
pmontra wrote 1 day ago:
None of my customers ever asked for type definitions in Ruby (nor
in Python.) I'm pretty happy of the choice of hiding types under
the carpet of a separate file. I think they made it deliberately
because Ruby's core team didn't like type definitions but had to
cave to the recent fashion. It will swing back but I think that
this is a slow pendulum. Talking about myself I picked Ruby 20
years ago exactly because I didn't have to type types so I'm not
a fan of the projects you are working at, but I don't even oppose
them. I just wish I'm never forced to define types.
troad wrote 1 day ago:
My point isn't technical per se, my point is more about the UX of
actually trying to use gradual typing in a flesh and blood Ruby
project.
Sorbet type annotations are noisy, verbose, and are much less
easy to parse at a glance than an equivalent typesig in other
languages. Sorbet itself feels... hefty. Incorporating Sorbet in
an existing project seems like a substantial investment. RBS
files are nuts from a DRY perspective, and generating them from
e.g. RDoc is a second rate experience.
More broadly, the extensive use of runtime metaprogramming in
Ruby gems severely limits static analysis in practice, and there
seems to be a strong cultural resistance to gradual typing even
where it would be possible and make sense, which I would - at
least in part - attribute to the cumbersome UX of RBS/Sorbet, cf.
something like Python's gradual typing.
Gradual typing isn't technically impossible in Ruby, it just
feels... unwelcome.
cess11 wrote 1 day ago:
Just move to Elixir. Phoenix is Rails-like enough and the platform is
excellent for parallelisation, clustering in specific hardware and so
on.
paradox460 wrote 1 day ago:
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
troad wrote 1 day ago:
Honest question from someone working on a non-negligible Rails
codebase: what would be my gains, were I to switch to Elixir?
I've watched Elixir with much interest from afar, I even recently
cracked open the book on it, but I feel like my biggest pain
points with Ruby are performance and lack of gradual typing (and
consequent lack of static analysis, painful refactoring, etc),
and it doesn't really seem like Elixir has much to offer on
those. What does Elixir solve, that Ruby struggles on?
paradox460 wrote 17 hours 13 min ago:
Performance is a complex story. Elixir is very good at massive
amounts of parallel computing, and uses this to handle each
request (or socket) in it's own contained manner, which nets
you some simplicity in designing systems and scaling. However
it's not very good at single threaded off-the-block performance
(but neither is Ruby)
Typing is coming, some is already here, and if you're impatient
you can use dialyzer to get half way there. But in my
experience you need it less than you'd think. Elixir primitives
are rather expressive, and due to the functional nature there
really isn't any "new" data structure that isn't easy to dive
into. And with each function head being easy to pattern match
in, you can dictate the shape of data flow through your
application much as you'd do in a typed language.
The ide story isn't great, but it's getting better. There are a
few LSPs out there, and an official one coming soon. And I'd
say all of them beat solargraph handily
But most of all I'd say that, since it's a bit more strict,
elixir saves you and your coworkers from yourselves and each
other. There are still several ways to do something, like Ruby,
but going out of your way to write very cutesy code that the
next programmer will loathe is more difficult. Not impossible,
but harder. And with the rock stable concurrency systems in
place, a lot of the impetus to come up with clever solutions
isn't there
arrowsmith wrote 8 hours 44 min ago:
I have the same experience with typing in Elixir. It's hard
to explain without experiencing it yourself, but the dynamic
typing just doesn't feel like as big of a deal as it might in
other languages. Elixir's guardrails (such as pattern
matching in function heads, which you mentioned) get you most
of the benefits - and you still get the convenience and
simplicity of a dynamic language. It's a great balance.
I'm looking forward to the upcoming gradual type system - it
can only be an improvement - but I would still encourage
people to try Elixir now, and let go of their preconceptions
about static typing.
Wrote about it more here:
URI [1]: https://arrowsmithlabs.com/blog/you-might-not-need-g...
troad wrote 15 hours 21 min ago:
Many thanks, I very much appreciate your thoughtful answer.
I've added some of the context for my question here: [1] Re
types, I think what I really want is just comprehensive
static analysis. Coming from Rust, where I can immediately
pull up every single call site for a given function (or use
of a struct, etc.), I find refactoring Ruby/Rails code to be
comparatively very painful. It is several orders of magnitude
more laborious and time-consuming than it should be, and I
just don't find the justification for that cost convincing -
I'd trade every last bit of Rails' constant runtime
metaprogramming cleverness for more static analysis.
What I like about Rails is its batteries-included nature, but
I honestly could do without those batteries materialising via
auto-magic includes and intercepted method calls. I
appreciate that that's just the culture of Ruby though, so I
don't expect Rails to ever change.
The lack of cutesiness in Elixir sounds lovely. I don't know
if functional approaches could make up for a lack of typing
for me; I think I'd need to try it. I've used and enjoyed
Haskell, but of course that's very strongly typed.
URI [1]: https://news.ycombinator.com/item?id=43144841
paradox460 wrote 15 hours 9 min ago:
Elixir has had some static analysis for a long time, you
can use a command to see all call sites of a module and
function. It's useful, and most of the LSPs use (or used to
use) it. The newer versions also are adding various hooks
to the compiler, to allow for better tooling
As for magic, elixir can have what looks like magic, but
upon closer look it's nothing more than macros, which are
generally pretty easy to decipher and follow. It has
minimal automatic code generation, what it has is mostly
the form of generators you'd run once to add things like
migrations
ricketycricket wrote 1 day ago:
Performance of what, exactly? Hard to beat the concurrency
model and performance under load of elixir.
Elixir is gaining set theoretic type system, so you are showing
up at the right time.
URI [1]: https://hexdocs.pm/elixir/main/gradual-set-theoretic-t...
troad wrote 1 day ago:
> Performance of what, exactly? Hard to beat the concurrency
model and performance under load of elixir.
The performance of my crummy web apps. My understanding is
that even something like ASP.NET or Spring is significantly
more performant than either Rails or Phoenix, but I'd be very
happy to be corrected if this isn't the case.
I appreciate the BEAM and its actor model are well adapted to
be resilient under load, which is awesome. But if that load
is substantially greater than it would be with an alternative
stack, that seems like it mitigates the concurrency
advantage. I genuinely don't know, though, which is why I'm
asking.
> Elixir is gaining set theoretic type system, so you are
showing up at the right time. [1] ...
Neat! Seems clever. Looks like it's very early days, though.
URI [1]: https://hexdocs.pm/elixir/main/gradual-set-theoretic...
pythonaut_16 wrote 1 day ago:
Some of the big performance wins donât come from the raw
compute speed of Erlang/Elixir.
Phoenix has significantly faster templates than Rails by
compiling templates and leveraging Erlang's IO Lists. So
you will basically never think about caching a template in
Phoenix.
Most of the Phoenix âmagicâ is just code/configuration
in your app and gets resolved at compile time, unlike Rails
with layers and layers of objects to resolve at every call.
Generally Phoenix requires way less RAM than Rails and can
serve like orders of magnitude more users on the same
hardware compared to rails.
The core Elixir and Phoenix libraries are polished and
quite good, but the ecosystem overall is pretty far behind
Rails in terms of maturity. Itâs manageable but youâll
end up doing more things yourself. For things like API
wrappers that can actually be an advantage but others
itâs just annoying.
ASP.NET and Springboot seem to only have theoretical
performance, Iâm not sure Iâve ever seen it in
practice. Rust and Go are better contenders IMO.
My general experience is Phoenix is way faster than Rails
and most similar backends and has good to great developer
experience. (But not quite excellent yet)
Go might be another option worth considering if youâre
open to Java and C#
troad wrote 16 hours 36 min ago:
Thank you, I really, really appreciate the thoughtful
answer.
I've written APIs in Rust, they were performant but the
dev experience is needlessly painful, even after years of
experience using the language. I'm now using Rails for a
major user-facing project, and while the dev experience
is all sunshine and flowers, I can't shake the feeling
that every line I write is instant tech debt. Refactoring
the simplest Rails-favoured Ruby code is a thousand times
more painful than refactoring even the most sophisticated
system in Rust. I yearn for some kind of sensible
mid-point.
Elixir seems extremely neat, but I've been blocked from
seriously exploring it by (a) a sense that it may not be
more any more performant than Ruby, so why give up the
convenience of the latter, and (b) not having seen any
obvious improvement on Ruby's hostility to gradual typing
/ overuse of runtime metaprogramming, which is by far my
biggest pain point. I'm chuffed to hear that the
performance is indeed better, that the magic in Phoenix
happens at compile time, and that gradual types are being
taken seriously by the language leadership.
I guess I'll have to take Phoenix for a spin.
goosejuice wrote 1 day ago:
There's three reasons to choose elixir or perhaps any
technology
The community and it's values, because you enjoy it,
because the technology fits your use case. Most web apps
fit. 1 and 2 are personal and I'd take a 25% pay cut to not
spend my days in ASP or Spring, no offense to those who
enjoy it.
seneca wrote 1 day ago:
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.
vlunkr wrote 1 day ago:
Also, the size of the elixir community and the libraries
available is completely dwarfed by rails. Elixir, Phoenix, all
the core stuff is really high quality, but in many cases you
might doing more work that you could have just pulled from a gem
in Ruby. It's unfortunate IMO. It's an underrated language.
arrowsmith wrote 8 hours 41 min ago:
This is true, but AI is closing the gap.
"Take this Ruby gem and write the equivalent functionality in
Elixir" is something that LLMs are very good at.
pythonaut_16 wrote 1 day ago:
Very much this.
I think the community tends to overestimate the ecosystemâs
maturity which is one of the big things holding it back, both
because it blinds the community to areas that need improvement
and leads to bigger shocks when newcomers do unexpectedly run
into the rough edges.
arrowsmith wrote 1 day ago:
And if you want to make the move, I know a great resource:
URI [1]: http://PhoenixOnRails.com
freedomben wrote 1 day ago:
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
aragilar wrote 1 day ago:
But does Elixir come with a whole scientific computing ecosystem?
grncdr wrote 1 day ago:
To add to what others mentioned, thereâs also [1] which
embeds a Python interpreter into your elixir program.
URI [1]: https://github.com/livebook-dev/pythonx
goosejuice wrote 1 day ago:
Must your statistical computing ecosystem comingle with your
web interface?
aragilar wrote 1 day ago:
You can split it off and have your Python code be an API you
call, but now you have at least two languages involved
(Python+Elixir, plus JS somewhere, plus the possible mix of
C/C++/Fortran/Rust(maybe?)). Given Ruby on Rails was
mentioned, just using Django seems similarly like the least
risky thing to do (this all assumes you are doing numerical
stuff, not just a standard CRUD app).
the_gastropod wrote 1 day ago:
I'm not super tuned into the scientific computing ecosystem, so
not sure if this is what you mean. But maybe? Elixir's
Numerical Elixir projects seem very relevant for scientific
computing. Check 'em out: [1] Edit: Hah! aloha2436 beat me to
the answer. Sorry for the repetition.
URI [1]: https://github.com/elixir-nx
aloha2436 wrote 1 day ago:
Not to the same degree that Python does (then again no other
general-purpose language does!), but it does have the start of
one and it's fairly cohesive.
URI [1]: https://github.com/elixir-nx
aragilar wrote 1 day ago:
Fortran? R? C? C++? Even Java may occasionally make a good
showing here (depending on what you are doing).
Having seen... things... unless it's written by people with
the right skillset (and with funding and the right
environment), that it exists doesn't mean you should use it
(and the phrase "it's a trap" comes to mind sadly). [1]
applies (and note I still wouldn't call Julia mainstream
yet), so while I'm not saying people shouldn't try, the
phrase "don't roll your own crypto" applies just as much to
the numeric and scientific computing fields.
URI [1]: https://scicomp.stackexchange.com/a/10923/1437
simonw wrote 1 day ago:
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:
- [1] - [2] (Reminds me I should try that out properly myself.)
URI [1]: https://fly.io/django-beats/running-tasks-concurrently-in-dj...
URI [2]: https://blog.pecar.me/django-streaming-responses
pphysch wrote 1 day ago:
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.
simonw wrote 1 day ago:
You don't have to rewrite your whole app - you can continue using
the regular stuff in synchronous view functions, then have a few
small async views for your LLM streaming pieces.
I've never quite gotten comfortable with gevent patches, but
that's more because I don't personally understand them or what
their edge cases might be than a commentary on their reliability.
btown wrote 20 hours 17 min ago:
Gevent IMO is more of a having-discipline footgun than a
fundamental one: it makes itself so easy to use, without
sprinkling asyncs in your day-to-day code, that you can forget
that it has the same problem as explicit Python asyncioâ¦
namely, that if you burn CPU in a tight loop without any IO or
logging or anything else, youâll never yield to the event
loop, and will block all concurrency until youâre done.
Detecting this might require external health checks and the
like. And runaway regexes can trigger this too, not just tight
loops. But those are also problems that asyncio has!
The only other one is that youâll want to think about forking
models with servers like gunicorn, and patch at the right time
- but this is a one-time thing to figure out per project, and
documentation is quite good now.
pphysch wrote 23 hours 49 min ago:
Last time I checked, simply running Django through the ASGI
interface dealt you a baseline perf hit.
simonw wrote 23 hours 28 min ago:
It's pretty minimal: [1] > When running in a mode that does
not match the view (e.g. an async view under WSGI, or a
traditional sync view under ASGI), Django must emulate the
other call style to allow your code to run. This
context-switch causes a small performance penalty of around a
millisecond.
URI [1]: https://docs.djangoproject.com/en/5.1/topics/async/#...
cjk wrote 1 day ago:
In an era of microservices-and-k8s-all-the-things, Rails monoliths are
a breath of fresh air. For stuff that's really performance- or
latency-sensitive, tacking on a satellite service in Go or Rust works
great.
mbell wrote 1 day ago:
> 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.
x0x0 wrote 1 day ago:
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.
jkestner wrote 1 day ago:
I wonder how it compares to Svelte for people. I weighed both but
Svelte didnât require me to learn Ruby (as much as Iâm sure
Iâd enjoy it).
theonething wrote 1 day ago:
> but Svelte didnât require me to learn Ruby
You can use HotWire with any language/framework you want.
adamtaylor_13 wrote 1 day ago:
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.
pmdr wrote 1 day ago:
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.
infamouscow wrote 1 day ago:
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).
Capricorn2481 wrote 22 hours 45 min ago:
This makes it sound like new devs entering the work force are
learning Ruby, which doesn't really make sense. I mean, look at
the article title. Ruby's audience seem to be people that have
been using it for 8+ years.
The commenter you're replying to, in fact, is saying lack of
fundamentals is the reason people AREN'T using Ruby
Glyptodon wrote 1 day ago:
TBH I've started to like the GraphQL ruby layer in Rails projects as it
creates a pretty clean boundary that works well with boilerplate and is
more standardized than REST APIs.
And I find that the "convention based" approach lends itself well to
having AI write stuff for you.
gatinsama wrote 1 day ago:
I am using Django and I do understand the sentiment.
But everything old is new again.
Today there is better tooling than ever for these tools. I am using
Django with htmx + alpine.js and sending HTML instead of JSON. Breaking
free from JSON REST APIs is a huge productivity boost.
Mystery-Machine wrote 1 day ago:
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...
lgvld wrote 17 hours 52 min ago:
What is missing from Django in your opinion?
gatinsama wrote 1 day ago:
What in particular? Never tried Rails so I want to know what I'm
missing.
rubenvanwyk wrote 1 day ago:
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.
luketheobscure wrote 1 day ago:
This is an unfortunate comparison. I actually chose Next.js because of
its similarity to Rails - it's a batteries included, opinionated
framework that favors convention over configuration (though it's not
sold that way since these are not the currently trending buzzwords).
There's absolutely nothing preventing you from using both tools. Rails
works great as an API supporting a Next.js UI.
pier25 wrote 1 day ago:
Next is definitely not "batteries included". It solves close to
nothing on the backend (like all fullstack JS frameworks).
rglover wrote 1 day ago:
Well, not all of them [1].
DB access (drivers are automatically started, connected, and wired
for use), queues, cron jobs, websockets, uploads, API helpers,
simple routing, caches, indexes...
It gets ignored, but there are (sane) options. I'm quite proud of
the APIs, too. Easy to learn, tidy, and everything just works.
URI [1]: https://cheatcode.co/joystick
pier25 wrote 1 day ago:
Ok, you're right.
I was referring to the usual ones (Next, Nuxt, SvelteKit, Remix,
etc).
Joytick looks cool. Besides this there's also NestJS
URI [1]: https://nestjs.com/
rohan_ wrote 1 day ago:
wouldn't using the nextjs backend / server components be far simpler
and and streamlined
caiohsramos wrote 1 day ago:
I'd say Next.js is the opposite of a "batteries included" framework.
No abstractions for ORM, background jobs, sending emails, managing
attachments, web socket communication - all very basic stuff when
dealing with a production application.
luketheobscure wrote 1 day ago:
It is a batteries included _front end_ framework. You don't need to
worry about compiling, routing, code splitting, etc. Most of the
things you described should be handled by the back end service
kelvinjps10 wrote 1 day ago:
The back-end service being vercel, and its propietary offerings
Mystery-Machine wrote 1 day ago:
Next.js doesn't even have authorization. What does it have?
Server-side rendering? Cool.
whstl wrote 1 day ago:
Hey, let's be fair here: Rails also doesn't have built-in
authorization. You need something like Pundit or CanCanCan if
you don't want to built it yourself.
Also Rails only recently got authentication. For more than a
decade you needed Devise or something else.
pcthrowaway wrote 1 day ago:
I mean it has a router (2 actually), and NextAuth seems to be
becoming something of a standard for many Next devs.
Meanwhile.. last I checked you still had to choose how you were
going to roll your own auth in rails. Are people not often just
installing bcrypt and adding a users table with their password
hash? Or is there a generator for all that now?
Anyway, I disagree with the idea that Next is Rails-like.
Adonis is probably still the closest in the JS/node ecosystem,
though Redwood might also serve a similar niche for the types
of apps it works for.
Next and the other "frontend metaframeworks" (as they're called
now), are certainly much closer than the most popular choices 7
or 8 years ago (often cobbling together React and Express and
an ORM like Prisma, making a bunch of other decisions, and then
doing a bunch of the integration work by hand)
heidarb wrote 1 day ago:
Devise has made it easy to add auth to rails apps for many
years now. More recently there is also the built in auth
generator.
pcthrowaway wrote 1 day ago:
Right, so Devise seems like for rails it's what NextAuth is
for Next? Though I don't know if there's anything
equivalent to rails' code generation yet.
caiohsramos wrote 1 day ago:
>It is a batteries included _front end_ framework.
From the first page of Next.js docs: "Next.js is a React
framework for building full-stack web applications"
> You don't need to worry about compiling, routing, code
splitting, etc
IMO that's the least you'd expect from a web framework.
Onavo wrote 1 day ago:
All these features are stateful or realtime. In a cloud/serverless
world, they are all separate managed services ("compute/storage
separation"). That's the trade-off of Next.js, greater productivity
by standing on top of more hosted dependencies. Theoretically
unlimited (within datacenter limits) scaling, bottlenecked only by
your credit card.
sankumsek wrote 1 day ago:
Do you have a suggestion for a more Rails-esque framework (maybe
Django)?
Lio wrote 1 day ago:
By all means use Django if you specifically want to work in
python but otherwise if you really want a Rails-esque framework
why not just use full stack Rails?
You get much out of the box with Rails 8 now like deployment,
caching, job queue, Hotwire, Turbo Frames and mobile.
graypegg wrote 1 day ago:
If we were keeping in the JS ecosystem, thereâs Redwood [0]
which has been around a while*.
[0] [1] * not comparable to Rails or Djangoâs definition of
âa whileâ but itâs quite mature.
URI [1]: https://redwoodjs.com/
amazingamazing wrote 1 day ago:
Itâs interesting to see how convention over configuration had its
hay-day in the 2010s. Angular, EmberJS, Django, and Rails were very,
very popular. Now, the new type of modern stack, e.g. React/NextJS with
bespoke backends consisting of things like NodeJS spaghetti with
express seem to have a lot of traction.
I base the above assertion mainly on looking at Whoâs Hiring posts
btw.
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
jay-barronville wrote 1 day ago:
> 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]:
URI [1]: https://remix.run
Alifatisk wrote 1 day ago:
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.
artursapek wrote 1 day ago:
Nah, RoR failed because nobody wants to write code in an untyped,
monkey-patch-friendly language anymore.
user432678 wrote 21 hours 38 min ago:
Failed or not, but at least for 2020 Y-Combinator Ruby-based
startups valuation was more than other programming languages based
startups combined.
URI [1]: https://charliereese.ca/y-combinator-top-50-software-start...
artursapek wrote 20 hours 4 min ago:
"Initial back-end language(s)"
Lmao you really think Stripe is still running primarily on Ruby?
Yeah it's good for prototyping because it's fast to write in, but
unmaintainable as hell for a real business.
user432678 wrote 6 hours 31 min ago:
Nobody said they still run on Ruby, but itâs far from âRoR
failedâ. Other example would be GitHub, still runs on Rails.
Shopify, still runs on Rails. I agree, less people doing coding
in Ruby, I myself written last line of Ruby a decade ago, but
saying âRoR has failedâ is just not true.
Update: found a thread here on HN: [1] I doubt theyâve
rewritten everything to Java for the last three years.
URI [1]: https://news.ycombinator.com/item?id=29834840
Alifatisk wrote 1 day ago:
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.
URI [1]: https://docs.ruby-lang.org/en/master/syntax/refinements_rd...
quest88 wrote 1 day ago:
Heh, maybe us engineers need to be better disciplined about what
"greatest" is.
aryehof wrote 1 day ago:
> maybe us engineers
Iâve started qualifying such statements⦠âyou mean a real
engineer or just a software developer?
Alifatisk wrote 1 day ago:
You mean that CSS engineers is not a true title!?
inanepenguin wrote 1 day ago:
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.
cultofmetatron wrote 1 day ago:
> 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.
sosborn wrote 1 day ago:
Maintenance nightmares are a product of organizational culture,
not any particular framework.
nickserv wrote 1 day ago:
The language encourages metaprogramming, and disencourages
typing. This makes maintenance much more complicated when
compared to other languages such as Python, typescript or PHP.
procaryote wrote 1 day ago:
Any language can get you a maintenance nightmare, but a lack of
types and a monolith will get you there faster.
Nothing in ruby forces you to make it a monolith of course, but
the lack of types hurts
Alifatisk wrote 1 day ago:
> What do you mean "left behind"? Are you saying people will
actually get "left behind" or just that people will _feel_ like
they're left behind?
Feel.
hrdwdmrbl wrote 1 day ago:
Just because of job availability, I've been a JS (Node, React, Next,
etc.) dev for almost a decade now. I still feel much more productive
with Rails.
Rails isn't the right tool for every job, but I find that it's the
right tool more often than not.
Rails is architected really well. Many decisions don't need to be made
at all, and everything has a place. Plus, it's very friendly to
extensibility and has a healthy ecosystem. It's mostly about the code
that I don't need to write. It's really years beyond most other
frameworks. Next will get there, but it will take it another 5 years.
No shade on others, but Rails is just well built software with many
years of learning and improving.
For highly reactive or "dynamic" systems, it probably isn't the right
tool. Building a Figma or Notion. As @graypegg said in their comment,
most websites work best as "CRUD forms". Though I would have said the
same about email, but Hey.com exists so YMMV...
Axsuul wrote 1 day ago:
Any thoughts on Inertia.js, which seems like a good solution for React
+ Rails? Feels like you can have your cake and eat it too.
URI [1]: https://github.com/inertiajs/inertia-rails
phaedryx wrote 1 day ago:
This looks interesting. I think I'll try it out over the weekend.
Thanks for sharing.
inanepenguin wrote 1 day ago:
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.
choxi wrote 1 day ago:
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.
winterbloom wrote 1 day ago:
im not aware of the generator supporting all that
here's what I get
`Possible values: importmap, bun, webpack, esbuild, rollup`
x0x0 wrote 1 day ago:
inertia, I think, avoids writing an api to bridge rails/react
andrewstuart wrote 1 day ago:
âYour grandpas vinyl recordsâ as analogy for Ruby on Rails.
Love it.
philip1209 wrote 1 day ago:
For the hundreds of people reading this article right now - you might
be amused to know that you're accessing it from a mac mini on my desk:
[1] (The CPU load from this is pretty negligible).
URI [1]: https://www.contraption.co/a-mini-data-center/
cl0ckt0wer wrote 19 hours 31 min ago:
Do mac minis have ECC ram?
firefoxd wrote 23 hours 25 min ago:
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.
[1]
URI [1]: https://ibb.co/cXT3VNDR
raitom wrote 1 day ago:
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.
philip1209 wrote 23 hours 28 min ago:
I have the m4 pro with 24gb of ram. I wish I had increased the ram
to 64gb - I'm at 50% utilization already.
The CPU is more powerful than I need. I didn't pass 8% utilization
in the last 24 hours as HN slammed the box.
jon-wood wrote 23 hours 32 min ago:
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.
mattgreenrocks wrote 1 day ago:
Love all the projects you have going. Do you use a template for the
landing pages? Or DIY? They look great!
philip1209 wrote 23 hours 31 min ago:
Thanks! Postcard was made with some help of TailwindUI.com.
Booklet's homepage is based on a Webflow template:
URI [1]: https://webflow.com/templates/html/gather-saas-website-tem...
renegade-otter wrote 1 day ago:
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?
dakiol wrote 1 day ago:
How much does it cost to keep the mac mini on for a month? Iâve
been thinking doing the same.
philip1209 wrote 20 hours 27 min ago:
Not sure - I could hook up an energy monitor and run some math.
But, I don't think the marginal internet cost or electricity cost
are really much.
psnehanshu wrote 1 day ago:
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.
yla92 wrote 1 day ago:
Not OP but the site sits behind Cloudflare and Cloudflare uses
Google Trust GTS and LetsEncrypt for Edge certificates.
URI [1]: https://developers.cloudflare.com/ssl/reference/certificat...
fsndz wrote 1 day ago:
the article is AI-generated isn't it ?
philip1209 wrote 1 day ago:
Nope
fsndz wrote 1 day ago:
Lol, by just reading I knew it was. Then I used an AI detection
tool and it says 100% sure it is AI-generated. You know how hard
it is to get 100% sure it is AI-generated ?
tim333 wrote 1 day ago:
You can kind of tell it's not AI when it gets beyond the
generic stuff and on to say
>Today I'm working on Chroma Cloud, designed for exploring and
managing large datasets, and Next.js powers its advanced
interactions and data loading requirements.
which is unlikely to have been written by an LLM.
fsndz wrote 1 day ago:
you can inject personal stuff to make it feel original, but
huge chunks are still AI-generated. Just get the first 4/5
paragraphs and paste in gptzero
tim333 wrote 1 day ago:
Well on the one hand you have gptzero saying it's in the
style of AI which I don't count as reliable and on the
other you have the author saying it's not which I weight
higher.
And it mostly makes too much sense apart from "most drivers
don't know how many gears their car has" which has me
thinking huh? It's usually written on the shifter.
philip1209 wrote 20 hours 25 min ago:
I stand by that statement :-)
berdario wrote 1 day ago:
Most "AI detection tools" are just the equivalent of a Magic 8
ball.
In fact, most of them are just implemented by feeding an LLM
the text, and asking "is it AI generated?". You cannot trust
that answer any more than any other LLM hallucination. LLMs
don't have a magic ability to recognise their own output.
Even if your "detection tool" was using exactly the same model,
at the same exact version... unless the generation was done
with 0 temperature, you just wouldn't be able to confirm that
the tool would actually generate the same text that you suspect
of being LLM-generated. And even then, you'd need to know
exactly the input tokens (including the prompt) used.
Currently, the only solution is watermarking, like what
Deepmind created: [1] but even that, it requires cooperation
from all the LLM vendors. There's always going to be one (maybe
self-hosted) LLM out there which won't play ball.
If you're going to accuse someone of pushing LLM-generated
content, don't hide behind "computer said so", not without
clearly qualifying what kind of detection technique and which
"detection tool" you used.
URI [1]: https://deepmind.google/discover/blog/watermarking-ai-...
fsndz wrote 1 day ago:
I am starting to believe this is a lie spread by AI companies
because if AI-slop starts to be detected at scale, it kills
their primary use case.
True, AI detection tools are not perfect, like any
classification algo, they don't have a 100% accuracy. But it
does not mean they are useless. They give useful
probabilities. If AI detectors are so wrong, how do you
explain that passing AI generated text on gptzero and it gets
it all the time, same when I pass human written content it
recognises it as such almost 99% of the time.
berdario wrote 34 min ago:
> They give useful probabilities
Yes, compared to an all-or-nothing approach, it's better to
be upfront about the uncertainty, especially if the tool
surfaces the probability by-sentence.
But how are those probabilities computed? You mention
gptzero, but [1] doesn't clarify at all how it works. They
link papers using GPTZero (i.e. from other researchers),
e.g. [2] And these very same papers highlight how
everything is still unknown
> Despite their wide use and support
of non-English languages, the extent of their zero-
shot multilingual and cross-lingual proficiency in
detecting MGT remains unknown. The training
methodologies, weight parameters, and the spe-
cific data used for these detectors remain undis-
closed.
GPTZero seems to be better than some of the alternatives,
but other discussions here on HN when it was launched
highlight all of the false positives and false negatives it
yielded: [3] [4] But all of that is pretty old, there have
been a couple of posts in the last year about it, but both
are about the business, rather than the quality of the tool
itself. [5] So, to check if now it's any better I tried it
myself: I got it to yield a false negative (50% human and
50% AI rating, for a text which was wholly AI-generated),
and I haven't got it to yield a false positive.
But all of this is just anecdotal evidence, I haven't run a
rigorous study.
For sure, if some competent people believe that the tool
won't generate false positives, I'll be mindful of it and
(In the rare cases in which I write a long posts/blog
articles, etc.) I'll check that it doesn't erroneously flag
what I write.
It's bittersweet: if a tool that can be relied upon really
exist, that would be good news. But if that tool is closed
source (just like ChatGPT, Gemini, etc.) that doesn't
inspire confidence. What if the closed source detection
tool will suddenly start erroneously flagging a subset of
human texts which it didn't before?
At least, even with the closed source LLMs, we have a bunch
of papers that explain their mechanism. I hope that GPTZero
will be more forthcoming about the way it works.
URI [1]: https://gptzero.me/technology
URI [2]: https://arxiv.org/pdf/2310.13606
URI [3]: https://news.ycombinator.com/item?id=34556681
URI [4]: https://news.ycombinator.com/item?id=34859348
URI [5]: https://hn.algolia.com/?dateRange=pastYear&page=0&...
titmouse wrote 1 day ago:
It's the false positives that make it useless. Even if
it's generally very good at detecting AI, the fact that it
can and does throw false positives (and pretty frequently)
means that nothing it says means anything.
fsndz wrote 19 hours 35 min ago:
lol with that kind of reasoning, nobody should use
statistics or any kind of machine learning model...
foldr wrote 6 hours 16 min ago:
Thatâs actually not a bad rule of thumb!
AlchemistCamp wrote 1 day ago:
A mac mini is pretty beefy for hosting a blog!
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.
philip1209 wrote 1 day ago:
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.
adamtaylor_13 wrote 1 day ago:
I actually read that blog post too last week (or the week before?)
and Iâm genuinely considering this.
Render is crazy expensive for blog sites and hobby apps.
shadowangel wrote 1 day ago:
I was using an old Samsung s8, with a USBc ethernet adaptor it was
more then capable serving allot of requests.
philip1209 wrote 1 day ago:
Here's the core scripts I use for the mac mini. They're a bit raw,
but hopefully useful:
URI [1]: https://gist.github.com/philipithomas/ed57890dc2f928658d2c...
aurareturn wrote 1 day ago:
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.
philip1209 wrote 1 day ago:
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!
aurareturn wrote 1 day ago:
A small model like 1B or 3B should be ok with 16GB. I was
thinking in the name of savings, you can just use the same
machine.
It's a cool project. I might do it too. I have an M4 Mini sitting
on my desk that I got for $550.
boogieup wrote 1 day ago:
That makes sense, because serving a web page to a few hundred people
is not a computationally expensive problem. :3
philip1209 wrote 1 day ago:
I self-host analytics on the box (Plausible), which is using more
resources than the website. There are a few apps on there, too.
ekianjo wrote 1 day ago:
Plausible is hardy compute intensive
your_challenger wrote 1 day ago:
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)
philip1209 wrote 1 day ago:
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.
nemothekid wrote 1 day ago:
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.
bmelton wrote 1 day ago:
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.
ww520 wrote 1 day ago:
Get NUC, or one of those refurbished Dell or HP mini PCs. They
have plenty of CPU power, consume very little idle power, and
friendly to Linux.
xp84 wrote 1 day ago:
I have been wildly happy with my EliteDesk mini pcs. Mine are the
âG5â generation which cost like $60-150 on eBay with varying
specs, obviously newer generations have better specs but for my
âhomelabâ needs these have been great. I even put a discrete
GPU ($60) in my AMD one for a great little Minecraft machine for
playing with the kid.
beAbU wrote 1 day ago:
I have a g5 elitedesk small form factor (about the size of a
largr cereal box, not a book) pc, thats been runnimg my by
media server and torrent download services for years now. It
has a plucky little 10th gen i3 or something, and it has been
more than enough. Can real time transcode 4K movies! Dead quiet
and sips electricity. Uptime is on average about 8-10 months.
philip1209 wrote 1 day ago:
Glad it resonated with you!
If you're considering k8s, take a look at Kamal (also from DHH):
[1] I think it makes more sense for small clusters.
URI [1]: https://kamal-deploy.org/
bmelton wrote 1 day ago:
It probably does! Kamal/MRSK has been on the roadmap for awhile.
I have deliberately endeavored to keep the existing k8s setup as
minimal as possible, and it's still grown to almost unruly. That
said, it works well enough across the (surprisingly power
efficient) Dell C1100s in the basement, so it'd take a migration
to justify, which is of course the last thing you can justify
this with.
antonvs wrote 21 hours 41 min ago:
Which k8s distribution are you using? Iâve been using k3s on
everything from individual home machines or cloud VMs, to small
on-premise customer clusters for customers who donât already
have their own k8s clusters.
I donât find it approaching unruliness, quite the opposite
really.
bmelton wrote 56 min ago:
Vanilla, CNCF. K3S is tempting.
peterhunt wrote 1 day ago:
Now do it without Cloudflare :)
mmcnl wrote 1 day ago:
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.
dingi wrote 1 day ago:
Been using a setup following this for quite a while. Nginx reverse
proxy on a cheap VPS with a wireguard tunnel to home.
Eikon wrote 1 day ago:
Trivial, even for a high traffic website to be served from a fiber
connection.
alabastervlog wrote 1 day ago:
Computers are stupid good at serving files over http.
Iâve served (much) greater-than-HN traffic from a machine
probably weaker than that mini. A good bit of it dynamic. You
just gotta let actual web servers (apache2 in that case) serve
real files as much as possible, and use memory cache to keep db
load under control.
Iâm not even that good. Sites fall over largely because nobody
even tried to make them efficient.
xp84 wrote 1 day ago:
Iâm reminded of a site I was called in to help rescue during
the pandemic. It was a site that was getting a lot higher
traffic (maybe 2-3x) than they were used to, a Rails app on
Heroku. These guys were forced to upgrade to the highest
postgres that Heroku offered - which was either $5k or $10k a
month, I forget - for not that many concurrent users. Turns out
that just hitting a random piece of content page (a GET)
triggered so many writes that it was just overwhelming the DB
when they got that much traffic. They were smart developers
too, just nobody ever told them that a very cacheable GET on a
resource shouldnât have blocking activities other than
whatâs needed, or trigger any high-priority DB writes.
boogieup wrote 1 day ago:
And nobody knows how stuff works at the web server level
anymore... The C10K problem was solved a long time ago. Now
it's just embarrassing.
philip1209 wrote 1 day ago:
If only my part of SF had fiber service. #1 city for tech, but I
still have to rely on Comcast.
Eikon wrote 1 day ago:
Sounds weird to read that from Western Europe where even the
most rural places have fiber!
I understand that the USA is big, but no fiber in SF?
deaddodo wrote 1 day ago:
In the US, itâs not about money or demand. The more
entrenched cities (especially in California, for some
historic reasons/legislation) tend to have a much more
difficult time getting fiber installed. It all comes down to
bureaucracy and NIMBYism.
bcoates wrote 14 hours 35 min ago:
It's just SF, there's fiber-to-the-pole or better in most
of the LA area, even if the only last-foot service is DSL
or cable
xp84 wrote 1 day ago:
SF is mostly served by AT&T, who abandoned any pretense of
upgrading their decrepit copper 20 years ago, and Comcast,
whose motto is âwhatcha gonna do, go get DSL?â
AT&T has put fiber out in little patches, but only in deals
with a guaranteed immediate ROI, so it would mean brand new
buildings, where they know everyone will sign up, or deals
like my old apartment, where they got their service included
in the HOA fee, so 100% adoption rate guaranteed! AT&T loves
not competing for business.
Sure, others have been able to painstakingly roll out fiber
in some places, but it costs millions of dollars to string
fiber on each street and to get it to buildings.
unclebucknasty wrote 1 day ago:
Lived in an older neighborhood in Georgia a couple years
back. A new neighborhood across the street had it (AT&T),
but we didn't.
Caught an AT&T tech in the field one day, and he claimed
that if 8 (or 10âmemory's a little fuzzy) people in the
neighborhood requested it, they'd bring it in.
I never did test it, but thought it interesting that they'd
do it for that low a number. Of course, it may have been
because it was already in the area.
Still, may be worth the ask for those who don't already
have it.
ekianjo wrote 1 day ago:
> where even the most rural places have fiber!
No need for the hyperbole. I know for a fact that you don't
get fiber in the remote countryside of France
fragmede wrote 1 day ago:
[1] has a detailed map, by provider, if you wanna dig into
the gory details, but there is fiber, just not everywhere.
URI [1]: https://bestneighborhood.org/fiber-tv-and-internet-s...
jnathsf wrote 1 day ago:
we have fiber in half of SF via Sonic - where there are
overhead wires. The other half of SF has its utilities
underground making economics more difficult.
philip1209 wrote 1 day ago:
Not where I am
philip1209 wrote 1 day ago:
Perhaps some day.
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.
nofunsir wrote 1 day ago:
Except Starlink uses CGNAT, which means you need some external
SSHD port forwarding at least.
nemothekid wrote 1 day ago:
He could keep using Cloudflare Tunnel, but then he's still
using Cloudflare
asdfman123 wrote 1 day ago:
What is HackerNews but a system to stress test everyone's hobby
websites?
mey wrote 1 day ago:
Before this Digg, before that Slashdot.
What else am I missing?
no_wizard wrote 20 hours 26 min ago:
There was a time where Reddit was good for discovery as well
entropie wrote 1 day ago:
del.icio.us
anyone?
mannycalavera42 wrote 19 hours 24 min ago:
yup!!! I've replaced it with [1] now but it's not the same
URI [1]: https://pinboard.in/popular/
besus wrote 1 day ago:
Fark
stevekemp wrote 1 day ago:
Kuro5hin was pretty big, back in the day. But /. was the biggie,
along with need to know. We get the term slashdotted from there,
after all.
tomhoward wrote 14 hours 53 min ago:
Oh man, the most helpful article Iâve ever read about
depression and burnout was on Kuro5hin. Luckily itâs been
preserved on Wikibooks: [1] Still holds up well two decades
later.
URI [1]: https://en.wikibooks.org/wiki/Demystifying_Depression
f4stjack wrote 1 day ago:
Holy⦠I still miss kuro5hin. Wonder what is rusty doing
nowadays.
durkie wrote 1 day ago:
URI [1]: https://www.todayintabs.com
f4stjack wrote 1 day ago:
thank you!
DeathArrow wrote 1 day ago:
>Before this Digg, before that Slashdot.
>What else am I missing?
You are missing Reddit.
vram22 wrote 1 day ago:
/u/seddit
pjmlp wrote 1 day ago:
Before we were all on USENET, some lucky ones were on Compuserve
and AOL, and BBSs were limited by phone lines, not really
anything to test loads.
ash-ali wrote 1 day ago:
I absolutely love this comment <3
atum47 wrote 1 day ago:
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.
jonwinstanley wrote 1 day ago:
Weirdly, that tower in the photo is also on the front page of HN
right now
URI [1]: https://vincentwoo.com/3d/sutro_tower/
philip1209 wrote 1 day ago:
Ah - I took that photo on the way to Mount Olympus Park, which is
one of my favorite little parks in SF. It has an interesting
history:
URI [1]: https://en.wikipedia.org/wiki/Mount_Olympus_(San_Francisco...
jonwinstanley wrote 1 day ago:
Nice!
TomK32 wrote 1 day ago:
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?
nemothekid wrote 1 day ago:
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?
TomK32 wrote 1 day ago:
It's a small cost of $4.50/month and allows me a lot more
control. In regards to wireguard, that one VM I pay for is the
central wireguard node for all sorts of devices that I use,
allowing me to securely access home services when I'm not at
home. There are services you don't want to expose directly via a
Cloudfare Tunnel.
boogieup wrote 1 day ago:
Not making Cloudflare more of a central point of failure for the
internet? We hosted web pages before they MITM'd the entire web.
miyuru wrote 1 day ago:
Public IPv4 address exhausted and NAT happened.
Even having IPv6 is not a proper solution because of laggy
ISPs(currently reaching ~50%) and the even the ISPs who deploy,
do not deploy it properly. (dynamic prefixes or inbound blocked
IPv6)
Add to the mix that lot of people does not understand IPv6,
internet became more centralized and will keep doing so for the
foreseeable future.
giantrobot wrote 1 day ago:
> We hosted web pages before they MITM'd the entire web.
We also hosted web pages before the average script kiddie could
run tens of Gbps DDoS on sites for the lolz. And before ISPs
used CGNAT making direct inbound connections impossible.
october8140 wrote 1 day ago:
I like how they have amazing great free services and people are
upset so many people use it.
adamrezich wrote 1 day ago:
That's what we all said about various Google products many
years ago, too.
dingi wrote 1 day ago:
But you are using someone elseâs VM. You just donât pay for
it.
trinix912 wrote 1 day ago:
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.
cultofmetatron wrote 1 day ago:
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.
nlitened wrote 1 day ago:
> 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.
I read this as "in building your startup, you should be paranoid
about team members never making mistakes". I really try to read
otherwise, but can't.
DeathArrow wrote 1 day ago:
I use CQRS with /dev/null for writes and /dev/random for reads.
It's web scale, it's cheap and it's fast.
goosejuice wrote 1 day ago:
A bit hand wavy. It obviously depends on the business and what
"least of concerns" entails.
In most cases businesses justify the cost of managed databases
for less risk of downtime. A HA postgres server on crunchy can
cost over $500/mo for a measly 4vCPU.
I would agree that it's the least of concerns but for a different
reason. Spending all your time optimizing for optimal performance
(assuming sensible indexing for what you have) by continuously
redesigning your DB structure when you don't even know what your
company will be doing next year isn't worth the time for a few
hundred a month you might save.
giantrobot wrote 1 day ago:
What? No no, to be fast you need the whole database only in RAM!
And SQL is hard so just make it a giant KV store. Schemas are
also hard so all values are just amorphous JSON blobs. Might as
well store images in the database too. Since it's RAM it'll be so
fast!
/s
bluGill wrote 1 day ago:
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!
helpfulContrib wrote 1 day ago:
I used to host 3,000 active daily users from a 33mhz 486 with a 56k
modem.
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.
larodi wrote 1 day ago:
Everyone moved too fast into the future, and this is perhaps not
that good. The whole ASCII and 90s/cyberpunk nostalgia is being a
major cue.
rbanffy wrote 1 day ago:
We need something thatâs small, cheap, plugs into a power
outlet (or a PoE port), and lets anyone serve their personal
little node of their distributed social network.
I started thinking about that around an implementation that could
run under Googleâs App Engine free tier, but never completed
it.
vidarh wrote 1 day ago:
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)
JohnBooty wrote 23 hours 28 min ago:
I love that so much. You just don't see wacky solutions like this
any more. I guess it's a good thing, but this career has gotten a
hell of a lot less fun and interesting.
_vaporwave_ wrote 1 day ago:
Very cool! Do you have a contingency in place for things like power
outages?
philip1209 wrote 1 day ago:
Not really . . . Cloudflare Always Online, mostly.
I had 2m35s of downtime due to power outages this week.
firecall wrote 1 day ago:
A MacBook Air solves this problem very nicely!
Not only does is have a built in UPS, but also comes with a
screen, keyboard and trackpad for you need to do admin tasks
physically att the console!
philip1209 wrote 20 hours 25 min ago:
Yeah, I had considered this! But, then I'd need a UPS on my
modem and wifi, and at that point it seemed overkill.
firecall wrote 18 hours 25 min ago:
Yes, totally.
Although you could use a backup USB cellular modem, plugged
directly into the Mac!
At some I imagine I'll inherit or acquire a cheap older M1
Macbook Air, which will be perfect!
I also have whole home battery backup and solar, so I
technically have a UPS for everything!
Where I live the power tends to go out from time to time!
I monkeyed around with cheap ex-lease Dell Micro PCs with
Intel 8th Gen to 11th Gen CPUs. But they not as performant as
I'd like, and once you've experienced modern CPUs like
Apple's M series, you dont really want to go back!
tempest_ wrote 1 day ago:
Presumably CF is doing most of the work if the page doesnt actually
change all that much?
kevincox wrote 19 hours 48 min ago:
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.
boogieup wrote 1 day ago:
Nobody's actually doing work because serving web pages is cheap.
fmbb wrote 1 day ago:
Is it really cheap through ruby?
philip1209 wrote 1 day ago:
Yeah, but there's Plausible Analytics self-hosted on the mac mini
that's getting more of the load right now.
rapind wrote 1 day ago:
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.
k4runa wrote 1 day ago:
Nice
tantalor wrote 1 day ago:
> Next.js now serves as the most common tool for building a startup.
This is completely unfounded.
neric wrote 1 day ago:
The number of crypto exchanges and news paper I've seen that run on
Nuxt.js
taormina wrote 1 day ago:
Because cyrpto exchanges and newspapers make up the majority of
startups? Most scams don't advertise themselves as startups and
most newspapers are just dying and going out of business, not
rebranding as startups.
philip1209 wrote 1 day ago:
If you normalize for for market cap, I think it's a reasonable
assumption. But, yeah - maybe it's a bit inflated.
graypegg wrote 1 day ago:
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"
andrei_says_ wrote 7 hours 38 min ago:
Figma, online photo and video editors, canva and browser based games
are the only non-CRUD examples I can think of from recent memory.
globular-toast wrote 1 day ago:
> 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.
searls wrote 22 hours 13 min ago:
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 ( [1] ) 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.
URI [1]: https://changelog.com/podcast/521
globular-toast wrote 18 hours 40 min ago:
I'm not sure I'm following what you're saying here. Are you
saying that, ultimately, everything boils down to CRUD? Like how
humans are really just a very elaborate chemical reaction? Or are
you saying businesses are literally CRUD? As in you can charge
money to create database records?
Of course everything is just CRUD. That's all a database can do.
But writing every piece of software at that level is insanity.
When I say pure CRUD I mean software that is literally just a
thin veneer over a database. Now that actually is useful
sometimes but generally you'll want to be able to write higher
level abstractions so you can express your code in a more
powerful language than CRUD. Are you really saying you've
consulted for businesses that just do CRUD? As in they have
meetings about creating, updating and deleting database records?
andrei_says_ wrote 21 hours 24 min ago:
Similar experience here. I see unnecessarily overengineered SPAs
everywhere - from blogs to CRUD-only SAAS and read about devs
starting each project as an SPA by default. Including blogs and
static websites.
The choice to spend 10x-50x the resources and deal with the agony
of increasing complexity doesnât make sense to me. Especially
in the last few years since Railsâ Hotwire solves updating page
fragments effortlessly.
nlitened wrote 1 day ago:
I actually believe that most of useful real-world software is
âone step away from Excelâ, and thatâs fine
globular-toast wrote 1 hour 38 min ago:
I think it's two steps away from Excel. The first step is making
schemas explicit and doing normalisation to avoid data anomalies.
This is where RoR gets you. The second step is naming the
operations/use cases in your business/domain (preferably with
words people already use) rather than trying to frame everything
as CRUD operations.
adsteel_ wrote 1 day ago:
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.
zdragnar wrote 1 day ago:
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).
grncdr wrote 18 hours 45 min ago:
> 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:
<%= render @product.reviews.order(created_at: :desc).limit(5)
%>
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.
cosmic_cheese wrote 20 hours 16 min ago:
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.
loodish wrote 1 day ago:
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.
foobazgt wrote 1 day ago:
I don't understand why you consider this to be a burden. The
gateway will calculate the depth / quantities of any query for
you, so you're just setting a config option. When you create a
REST API, you're making similar kinds of decisions, except you're
baking them bespokely into each API.
Query whitelisting makes sense when you're building an API for
your own clients (whom you tightly control). This is the original
and most common usecase for graphql, though my personal
experience is with using it to provide 3rd party APIs.
It's true that you can't expect to do everything identically to
how you would have done it with REST (authz will also be
different), but that's kind of the point.
motogpjimbo wrote 1 day ago:
A malicious user who had the knowledge and ability to craft
expensive GraphQL queries could just as easily use that knowledge
to tie your REST API in knots by flooding it with fake requests.
Some kind of per-user quota system is going to be required either
way.
procaryote wrote 1 day ago:
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.
stickfigure wrote 1 day ago:
> 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.
gedy wrote 1 day ago:
GraphQL is not arbitrary queries into your database! Folks need
to really quit misunderstanding that.
You can define any schema and relations you want, it's not an
ORM.
what wrote 1 day ago:
It is arbitrary queries though? I can send any query that
matches your schema and your graphql engine is probably going
to produce some gnarly stuff to satisfy those queries.
whstl wrote 1 day ago:
You need to program every query resolver yourself, it's not
tied to some ORM.
There are of course products that do this automatically, but
it's not really that simple. There's a reason things like
Hasura are individual products.
gedy wrote 1 day ago:
No when I say "schema" I mean the GraphQL structure, not your
DB schema.
The GraphQL structure can be totally independent from your DB
if need be, and (GraphQL) queries on those types via API can
resolve however you need and are defined by you. It's not a
SQL generator.
stickfigure wrote 1 day ago:
The problem is not that you'll expose some part of the
database you shouldn't (which is a concern but it's
solvable). The problem is that you expose the ability for a
hostile client to easily suck down vast swaths of the part
of the database you do expose.
foobazgt wrote 1 day ago:
How is this different from REST?
stickfigure wrote 23 hours 25 min ago:
Generally, REST calls are narrowly tailored with a
simple contract; there are some parameters in and some
specific data out. This tends to be easy to secure, has
consistent performance and load behavior, and shows up
in monitoring tools when someone starts hammering it.
On the other hand, unless you've put some serious work
into hardening, I can craft a GraphQL query to your
system that will produce way more data (and way more
load) than you would prefer.
A mature GraphQL web API (exposed to adversaries) ends
up whitelisting queries. At which point it's no better
than REST. Might as well just use REST.
gedy wrote 1 day ago:
I think the OP is possibly confusing GraphQL with an
ORM like Active Record. You are correct that you don't
accidentally "expose" any more data than you do with
REST or some other APIs. It's just a routing and
payload convention. GraphQL schema and types don't
have to be 1:1 with your DB or ActiveRecord objects at
all.
(I'm not aware of any, but if there are actually gems
or libraries that do expose your DB to GraphQL this
way, that's not really a GraphQL issue)
stickfigure wrote 1 day ago:
In the spectrum of "remote procedure call" on one end and
"insert sql here" on the other end, GraphQL is waaaaay closer
to SQL than RPC.
ako wrote 1 day ago:
No itâs not, graphql is an rpc that returns a tree of
objects where you can indicate what part of the tree is
relevant to you.
stickfigure wrote 1 day ago:
...and that's exactly the problem! Without a lot of
hardening, I (a hostile client) can suck down any part of
the database you make available. With just a few calls.
GraphQL is too powerful and too flexible to offer to an
untrusted party.
gedy wrote 1 day ago:
This is a silly argument and sounds like a hot take from
someone who's never used this. You could say the same
about REST or whatever. It has nothing to do with "the
database".
gedy wrote 23 hours 25 min ago:
> Your naive GraphQL API, on the other hand, will let
me query large chunks of your database at a time
No it won't, because it's not tied directly to the
database and does not allow for arbitrary queries.
Any of the "aha!" gotchas you mention are the same
issues as you could have with REST, JSON-API, etc.
I'm sorry you don't understand what I'm pointing out,
but thanks for the convo though.
stickfigure wrote 23 hours 32 min ago:
You sound like someone that's never had an adversarial
client. I spent years reverse engineering other
companies' web APIs. I'm also responsible for a system
that processes 11 figures of financial transactions,
part of which (for now) is an incredibly annoying
GraphQL API that gets abused regularly.
REST calls are fairly narrowly tailored, return
specific information, and it's generally easy to notice
when someone is abusing them. "More like RPC".
Your naive GraphQL API, on the other hand, will let me
query large chunks of your database at a time. Take a
look at Shopify's GraphQL API to see the measures you
need to take to harden an API; rate limits defined by
the number of nodes returned, convoluted structures to
handle cursoring.
GraphQL is the kind of thing that appeals to frontend
folks because they can rebalance logic towards the
frontend and away from the backend. It's generally a
bad idea.
whstl wrote 1 day ago:
Yep. It is not trivial to make it into a pseudo-SQL
language, like Hasura did.
Funny enough, see this assumption frustrating a lot of
people who try to implement GraphQL APIs like this.
And even if you do turn it into a pseudo-SQL, there's still
plenty of control. Libraries allow you to restrict depth,
restrict number of backend queries, have a cost function,
etc.
cultofmetatron wrote 1 day ago:
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.
URI [1]: https://www.youtube.com/watch?v=aOk67eT3fpg&ab_channel=The...
mr-ron wrote 1 day ago:
Isnât this there bff stacks show their worth? As in those nextjs
apps that sit between react and rails?
zdragnar wrote 1 day ago:
Not really, then you're just shifting the complexity from the
front-end back to a middle man. Now it still exists, and you
still have all the network traffic slowing things down, but it
lives in its own little service that your rails devs aren't going
to bother thinking about or looking at optimizing.
Much better to just do that in rails in the first place.
aantix wrote 1 day ago:
The Rails support for multi-model, nested form updates is superb.
Separate entities on the backend - a unified update view if
thatâs whatâs desired.
No need for any outside dependencies.
graypegg wrote 1 day ago:
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.
dmix wrote 1 day ago:
Turbo frames solves a lot of this. [1] Multiple models managed on a
single page, each with their own controllers and isolated views.
URI [1]: https://turbo.hotwired.dev/
pdimitar wrote 1 day ago:
Or you can do it right and use Elixir's LiveView, from which
everyone is getting inspired these days.
dmix wrote 13 hours 14 min ago:
Not everyone can make a dramatic switch of languages and
frameworks. Turbo is excellent at what it does. Pure joy to
use, replacing much of our Vue frontend.
xutopia wrote 1 day ago:
LiveView is the brainchild of Chris McCord. He did the
prototype on Rails before getting enamoured by Elixir and
building Phoenix to popularize the paradigm.
LiveView is amazing and so is Phoenix but Rails has better
support for building mobile apps using Hotwire Native.
andrei_says_ wrote 1 day ago:
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.
LargeWu wrote 1 day ago:
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.
rtpg wrote 1 day ago:
If you lean into more 1:1 mappings (not that a model can't hold
FKs to submodels), then everything gets stupid easy. Not that
what you're saying is hard... just if you lean into 1:1 it's
_very easy_. At least for Django that's the vibe.
jaredklewis wrote 1 day ago:
You seem to be in agreement with the parent, who argues 1 model
(aka database row) = 1 rest entity (aka /widgets/123) is a bad
paradigm.
Different widget related front-end views will need different
fields and relations (like widget prices, widget categories, user
widget history and so on).
There are lots of different solutions:
- Over fetching. /widgets/123 returns not only all the fields for
a widget, but more or less every possible relation. So a single
API call can support any view, but with the downside that the
payload contains far more data than is used by any given view.
This not only increases bandwidth but usually also load on the
database.
- Lots of API calls. API endpoints are tightly scoped and the
front-end picks whichever endpoints are needed for a given view.
One view calls /widgets/123 , /widgets/123/prices and
/widgets/123/full-description. Another calls /widgets/123 and
/widgets/123/categories. And so on. Every view only gets the data
it needs, so no over fetching, but now we're making far more HTTP
requests and more database queries.
- Tack a little "query language" onto your RESTful endpoints. Now
endpoints can do something like:
/widgets/123?include=categories,prices,full-description .
Everyone gets what they want, but a lot of complexity is added to
support this on the backend. Trying to automate this on the
backend by having code that parses the parameters and
automatically generates queries with the needed fields and joins
is a minefield of security and performance issues.
- Ditch REST and go with something like GraphQL. This more or
less has the same tradeoffs as the option above on the backend,
with some additional tradeoffs from switching out the REST
paradigm for the GraphQL one.
- Ditch REST and go RPC. Now, endpoints don't correspond to
"Resources" (the R in rest), they are just functions that take
arguments. So you do stuff like
`/get-widget-with-categories-and-prices?id=123`,
`/get-widget?id=123&include=categories,prices`,
`/fetch?model=widget&id=123&include=categories,prices` or
whatever. Ultimate flexibility, but you lose the well understood
conventions and organization of a RESTful API.
After many years of doing this lots of time, I pretty much
dislike all the options.
procaryote wrote 1 day ago:
Lots of API calls scales pretty well, as long as those APIs
aren't all hitting the same database. You can do them in
parallel. If you really need to you can build a view specific
service on the backend to do them in parallel but with shorter
round-trips and perhaps shared caches, and then deliver a more
curated response to the frontend.
If you just have one single monolithic database, anything
clever you do on the other levels just lets you survive until
the single monolithic database becomes the bottle-neck, where
unexpected load in one endpoint breaks several others.
jupp0r wrote 20 hours 46 min ago:
"you can do them in parallel" - not in Rails.
procaryote wrote 8 hours 16 min ago:
Well, you could do them in parallel from the client to
independent endpoints.
But yeah, rails might be a bad match
jbverschoor wrote 1 day ago:
Webapps are going back to multiple requests because of http2 /
quic multiplexing.
jupp0r wrote 20 hours 42 min ago:
This solves the problem of slow transport between your
frontend and your backend, but it will still incur a lot of
unnecessary load on the database as well as compute on your
backend (which isn't normally a problem unless you're using
something really slow like Rails).
cetu86 wrote 1 day ago:
So what do you do instead?
jaredklewis wrote 1 day ago:
I do one or some combination of the options above. I've also
tried some more exotic variations of things on the list like
Hasura or following jsonapi.org style specs. I haven't found
"the one true way" to structure APIs.
When a project is new and small, whatever approach I take
feels amazing and destined to work well forever. On big
legacy projects or whenever a new project gets big and
popular, whatever approach I took starts to feel like a
horrible mess.
0x457 wrote 1 day ago:
No, it's an API Entity can be composed of sub-entities which may
or may not exposed directly via API.
That's what [1] is for.
However, Rails scaffolding is heavily geared towards that 1:1
mapping - you can make all CRUD endpoints, model and migration
with a single command.
URI [1]: https://guides.rubyonrails.org/association_basics.html
wahnfrieden wrote 1 day ago:
Rails began that trend by auto-generating "REST" routes for 1:1
table mapping to API resource. By making that so easy, they
tricked people into idealizing it
Rails' initial rise in popularity coincided with the rise of REST
so these patterns spread widely and outlasted Rails' mindshare
philip1209 wrote 1 day ago:
Yeah, I agree.
Too many degrees of freedom can degrade an experience, if not used
properly.
DIR <- back to front page