Related to Ruby perf, I still hear folks worried about rails “not being able to scale”. Let me say something controversial (and clearly wrong): Rails is the only framework that has proven it _can_ scale. GitHub, Shopify, AirBnb, Stripe all use rails and have scaled successfully. Very few other frameworks have that track record.
There’s plenty of reasons to not use rails, but scaling issues doesn’t feel like a strong one to me.
In the interim I've found https://dndkit.com a _really_ nice solution, but it's only available in React-land.
Looks like this new library was written at least in part by the same guy who wrote react-beautiful-dnd, so my hopes are high (as long as this one stays maintained...)
I'm interested to see how this hits finance firms – I know people who were forced to take a year off between jobs (although they were compensated the whole time). Always thought that would be a pretty sweet deal.
Ended up just paying for an IPv4 address to avoid the hassle.
I don't think this is "the year of IPv6" but it might be its decade.
That's not going to be true. It might be true when things are running well, but when it fails, it'll either be at most once or at least once. You don't build for the steady state, you build against the failure mode. That's an important deciding factor in whether you choose a system: you can accept duplicates gracefully or you can accept some amount of data loss.
Without reviewing all of the code, it's not possible to say what this actually is, but since it seems like it's up to the implementor to set up replication, I suspect this is an at-most-once queue (if the client receives a response before the server has replicated the data and the server is destroyed, the data is lost). But depending on the diligence of the developer, it could be that this provides no real guarantees (0-N deliveries).
I took a peek at the code and it looks like their visibility timeout is pretty much a lock on a message. So it's not exactly once for any meaningful definition, but it does prevent the same message from being consumed multiple times within the visibility timeout.