News for hackers. Stuff that matters.
Re:Zero-cost futures in Rust by SideburnsOfDoom on Thursday August 11, 2016 @05:17PM (#12271613)
Put it this way:

Cost of a branch misprediction is 10s of cpu cycles. (1) Measured in gigahertz (10^9 cycles per second).

Time to turn around a web request is, if you're very lucky and have done the work, mainly about getting a value from an in-memory cache at multiple milliseconds (2). That's 1 / (10^3) seconds.

If you're not lucky, 10s or 100s of milliseconds to generate the response.

It seems that the second duration is best case around 10^6 times longer. I would not sweat the first one.

1) http://stackoverflow.com/a/289860/5599 2) http://synsem.com/MCD_Redis_EMS/

Re:Zero-cost futures in Rust by gpderetta on Thursday August 11, 2016 @05:23PM (#12271648)
Contrary to popular belief, not all C++ programs (or rust FWIW) are web servers serving HTTP requests over the Internet.
Re:Zero-cost futures in Rust by SideburnsOfDoom on Thursday August 11, 2016 @05:27PM (#12271671)
Yep, that's why I'm asking about the use-cases in the grandparent comment.
Re:Zero-cost futures in Rust by gpderetta on Thursday August 11, 2016 @05:35PM (#12271732)
As an example, many real-time systems are often a giant ball of messy asynchronous code and state machines. Futures can help with that, although lately I have found that somtimes the best, cleanest, way to implement a state machine is to make it explicit.
Re:Zero-cost futures in Rust by haimez on Thursday August 11, 2016 @10:25PM (#12273066)
How much do you attribute that to the benefit of creating a high barrier to entry for modifying that code? Could this be summarized as: code that inexperienced devs can't understand, stays performant because they can't figure out how to change it?
Re:Zero-cost futures in Rust by gpderetta on Friday August 12, 2016 @09:39AM (#12275502)
None of the teams I've worked with had such a policy and certainly I wouldn't work in a team like that.