Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I run a busy production ruby app on a $40/month droplet. My performance issues are almost never related to ruby. It's nearly 100% of the time some complex database query that needs to get indexed/cached.

If coders write their backend in rust for "the ultimate performance", and it's shipping 20MB of javascript to query a poorly designed, poorly indexed database with no caching, they're going to get far worse performance than a ruby app querying a properly designed, cached database with indexing that doesn't have to spend 5 seconds domming the user's DOM first. Performance is a holistic problem, and anecdotally, web sites felt a lot faster during the rails era than they do right now during the JS era.



We can do both, I never said one should be prioritized over the other.


One abosolutely should be prioritized over the other. There's never going to be a situation where you can address every potential source of slowdowns, and make everything 100% efficient all of the time. Given that, in any somewhat realistic environment, you're going to need to prioritize where to spend your focus on making things more efficient.

It's certainly possible that the answer is that the language you're using is fundamentally too slow - I personally have almost never experienced that - almost always I can get more out of a time investment by focusing on improving DB performance, or some problem with delivery, caching or optimizing bundles.

You should look at your personal situation and use real data to decide where to focus, but you always have to focus. "Make everything 100% efficient at all times" is completely unrealistic.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: