My entire point was that Rails is not designed for this.
I first thought it's just a backend use-case, where processing 1000 records in a paginated result is common, but the parent mentions "rails", so it sounds like a frontend use-case.
On an average mobile connection, it’s maybe a second or so.
“Why would I pointlessly accept this clear case of massive technical debt for literally no reason what-so-ever?”
Rails does not present any sort of promise that go does not also present, so just saying “yeah, I’ll handcuff my app like this cause I feel like using Ruby” is, frankly, absurd.
When you ask the right questions, you never land on Ruby, and that’s why Ruby continues to decline.
Ruby is concise compared to Go though. I like Go and but when I use it I have to accept that I'll write (and debug) at twice as much code as I would do in Ruby.
If you're mostly just loading data into a large fast cache, lines of code may be a more critical dimension than execution speed.
That's how well designed Rails projects work and you get most of what you need straight out of the box.
