I have no idea why the C++ designers chose those particular names, but at least Scala uses the same Promise/Future dichotomy, where you resolve (or reject) a Promise into a Future. Perhaps they drew from the same well?
I have no experience with SQS, but there is definitely space for a simpler queue implementation (or even a standard) than AMQP. I think it's needlessly complex for many problem domains.
Here's one example. Web browsers often use bloom filters or similar data structures to check for malicious URLs. They first check the URL against the local bloom filter, and if a match is found, they double check against an online API to make sure it wasn't a false positive.
Shipping a full list of malicious URLs would be too expensive, but a bloom filter fits in a fraction of the space and can still eliminate a vast majority of the API calls.
> Imagine if that lone guy at Microsoft didn't figure out trick with 286 protected mode that allowed Windows to survive and wasn't heard by top management - we would all be running OS/2 10 now.
Going above 32G doesn't kill performance per se, it just means that there is not point in using heap sizes between 32G and 48G due to the larger pointers. If you go above that, it's all good again.
It's a nice tool, I use it daily. Right now my only gripe is that it doesn't format (PostgreSQL) JSON columns in any way, so if you're storing a lot of JSON data, it can be difficult to view.
During the hottest days of the summer (it very rarely goes above 28C or so - average maximum temperature is around 22C during the hottest summer months in southern Finland), yes, but not that often.
Music isn't obviously not the focus of any Twitch stream, but nevertheless, people are breaking copyright laws by playing copyrighted music on their streams. And if Twitch becomes a part of YouTube, they might have to crack down on copyrighted music on streams, due to pressure from the copyright holders.
> Without concurrent request dispatch, jruby's hypothetical greater thread parallelism is unlikely to effect requests-per-second benchmarks. Also, the benchmarking test would have to be willing to issue requests concurrently!
That's a good point.
That said, JRuby would most likely benefit from a concurrent test, as the thread-per-request model of JRuby can scale much higher than the process-per-request model which is used a lot in the MRI world.
I'd wager that it's the TB/Undertow code running most of the time on that benchmark. On real-world benchmarks the difference is going to be a lot smaller. Not saying that you shouldn't run your JRuby apps on Torquebox - it's a great choice.