It's insane that this comment is grey while the parent that's insinuating without proof that someone is a pedophile is going strong. What has happened to HN?!
Evidence suggests the powerful, especially the billionaire class, is regularly involved in sex trafficking. At this point I think it's reasonable to assume they are until you shown otherwise.
Frankly, to become a billionaire demonstrates a lack of empathy. Someday we'll recognize it as the mental health condition it is.
When I used to ride around SF on an e-bike, I’d deliberately choose undulating routes so I could climb at max assist speed and then fly down the descents above max assist speed.
I code and maintain a Rails stack. About 20% of the time an endpoint takes to respond is spent in Ruby. New Relic tells me our Apdex is 99, and it’s very rare for an endpoint to take more than 100ms. Most respond in under 80ms. I could LLM-port it (and probably will one day), but end-user response performance wouldn’t be the motivation.
What does make me consider switching is reading about things like how Shopify’s native apps are moving towards superfast product cores that can be tested incredibly quickly, with the slower UX layer kept separate. I think that model is the future, and in that world Rails starts to look pretty dead.
If your average per request in the application layer is say 20ms. Your p50 is probably 10-15ms and your p99 is probably something like 80ms. p99.9 is probably a good bit higher than that.
If your site is highly interactive, everyone using it is going to regularly run into actions that take long enough that they notice them, and it won’t feel snappy.
Let’s say you went all out and wrote the application layer in C with purely static allocation. You could easily see a p50 around 1-2ms and a p99 of 3-5ms. (This is obviously dependent on the app).
Even with an average time spent waiting in the database of 80ms, you’ve already made a noticeable difference.
That’s not even mentioning the biggest impact, which is that you can likely get by with far fewer application servers.
Now does it make even more sense to optimize your queries? Yes. Definitely. But with faster application stack you can start moving more things into the application layer and out of the database which is generally harder to scale.
And if you have or can build endpoints that don’t hit your database at all, those will actually be 10x faster than before every time.
It would be interesting to hear more about how you’re actually using them. Do you have sophisticated feedback loops around the models so they can verify their work and converge on good solutions? And how do you decide what to give the 5090 vs the Spark vs a frontier model?
Correctness matters much more than speed to me, but if I can get both, that’s obviously very interesting.
Cause: Legacy Salesforce login service got into a resource-exhaustion cascade.
Fix: Rolling some unspecified fix they proved in testing out over the fleet seemingly very slowly (After their earlier attempts to roll something out faster failed).
Coincidentally, Salesforce just laid off the senior engineering lead on their shared login service team who 2 months ago was describing the practices his team follows to keep 99.95% uptime on that shared login service (this guy: https://www.linkedin.com/posts/patricktprice_engineeringmana...)
Layoffs are usually short-term money-savers at long-term cost, but hot damn this is the shortest short term I've ever seen.
And while I haven’t actually done my homework, the push to email-based login seems like it’s really pushing people to start using their own custom domains for logging in
