Yep, I'm not actually claiming that driving is safer per se, but it's apples vs oranges. I'm also not sure about 24M hours, total commercial airlines hours (i.e. aircraft hours, not passengers') is around 14M/year in 2018 (link in my other comment), so we need to multiply by the average number of passengers. Which gives >1B hours/year for commercial airlines only.
If that door had hit horizontal stabilizer though we would have had a completely different statistics even with 1B hours. Fortunately it didn't happen, but with the current trend the idea that flying is always safer may become not so obvious, and "orders of magnitude" thing may disappear pretty fast.
Statistics is a tricky thing. There are 43K traffic fatalities in the US per year and 53K deaths from colorectal cancer. Which means chances of dying from colorectal cancer is higher than dying in a traffic accident. Well, over a lifetime, but distribution over age can be different etc. In the same way 43K fatalities are not an even distribution over region, type of driving, destination, age etc.
Of course I have to admit that flying commercial airlines is safer by average numbers, in the US and for now. But if we estimate total flying hours as 1.3B/year (http://web.mit.edu/airlinedata/www/2018%2012%20Month%20Docum... times 100 passengers per aircraft) it only takes 1300 deaths per year to make it even with average traffic fatalities. If that flight had been unlucky enough to go down we would have had 177 deaths, already not "orders of magnitude safer" than driving. And the trend is not good.
But again, we are comparing apples to oranges. Driving is a very different experience, both long and short trips. Nobody chooses to drive from Boston to LA just out of fear of flying (well, maybe there are exceptions, but "nobody" is still a very accurate word). As for short trips, changes of getting into an accident in urban area driving to the airport is probably higher than driving in the other direction towards your destination. Again, it depends.
> In 2007, the National Transportation Safety Board estimated a total of nearly 24 million flight hours. Of these 24 million hours, 6.84 of every 100,000 flight hours yielded an airplane crash, and 1.19 of every 100,000 yielded a fatal crash. https://www.psbr.law/aviation_accident_statistics.html
So we have 330M people in the US, of which let's say 100M are driving regularly. How regularly? Let's assume 2 hours a day for 52x5 = 260 working days in a year. So given that we have 43K traffic fatalities per year let's compute fatalities per hour of driving. 100M * 2 * 260 / 43K = 1.2M So we have 1 fatality per 1.2M hours of driving. At the same time we have roughly 1 fatality per 100K hours of flying. Oops!
Of course one should consider that:
(a) it's 2007 data, it's probably lower now (10 times lower?),
(b) we definitely cover longer distances per hour of flying (by the way not that much, 60 mph vs 600 mph is within 10x difference),
(c) it's probably all flying, including private, but I'm not considering just public buses either.
Add defensive driving though, and it's not that obvious which is safer.
Yes, entropy increases in the salad dressing, but only when it's insulated (in reality we can't consider salad dressing outside of the Earth gravitational field, but let's say the Earth is insulated too). Now imagine that the extra energy (i.e. generated heat) has dissipated (either out of a window or, if we consider the Earth too, into the space). Is it still an increase of entropy? Our Solar system is not a closed system, the extra heat that was generated by creation of planets has dissipated (and is continuing to do so). So in the end the entropy of the Solar system is lower, i.e. we have more order, at least in our vicinity. Possibly in the whole universe since it's (presumably) expanding. Anyway, I wouldn't apply 2nd law of thermodynamics to the whole universe, we have no idea what happens at that scale.
Standard gear box oil is 80W90, which at -30C (even at -20C) turns into a thick jelly. Even in neutral starter has to move gears in that jelly. So normally you don't want to release the clutch until engine is warm enough and stable, and even when you do release it (in neutral) you do it slowly, sometimes in multiple attempts to avoid engine stalling, like starting on a steep hill. I haven't tried automatic at those temperatures, but ATF is much less viscous, so it should be much easier on the starter at low RPM.
People just don't care about their vehicles, that's why. There are multiple examples of even diesels starting at -25°C without heating. All my cars have been gas and while starting them at -30°C required some magical actions (like turning on headlights briefly to warm the battery up or depressing the clutch if you have a manual transmission) they all started most of the time. No extra tools or devices were necessary.
> It hates any form of order and will actively attempt to destroy it.
If you are talking about ever increasing entropy, it applies to any environment. But keep in mind that the Moon itself is a manifestation of order. If it hadn't been the case we would have been observing a cloud of dust and gas where our Solar system is.
Most modern cars will happily start at -20°C and many will start at -30°C without any special additions (don't ask me how I know, you just need to know what you are doing). Of course it's not -200°C, but one thing to remember is that there is no temperature in the vacuum. The temperature of the Lunar surface is not it. An object without heating can easily reach lower temperatures there, yet it may not be that hard to keep that object warm as e.g. somewhere in the Arctic as there is no conductivity, only the radiation heat transfer.
If you block your timer goes out the window, right? Because the poll will never get there until the blocking call is done. So yeah, you can block, but it will disrupt the whole chain, including tasks above yours up to await. Similar to Erlang VM where the language itself yields (e.g. there are no loops and every recursive call is effectively a yield), but if you add a C module and are careless enough to block, the whole EVM blocks. So no, if you want to use async you shouldn't block. For loops? Nope, not if they take long time for the same reason, you may want to break them down to smaller chunks ("long" depends on other tasks and expected latency).
Having said that, Erlang exists and doing well, so async is as good as any model designed for special cases. But this discussion basically answers the question
> Why don’t people like async?
Because not everybody (which means a majority of developers) needs this complexity. And the upward poisoning means that I can't block in my function if my web server is based on async, which affects everybody who is using it.
Interesting, in the Java world Thread.stop is deprecated too: https://docs.oracle.com/javase/7/docs/technotes/guides/concu... Which means there is no good way to actually stop a thread involuntary. Of course in most simple apps it's not a big deal, but I would not do it in long-running apps.
OTOH in Rust async model is based on polling. Which means that poll may never block, but instead has to set a wake callback if no data is available. So there is no way to interrupt a rogue task and all async functions should rely on callbacks to wake them (welcome to Windows 3.1, only inside out!). Thread model is much more lax in this sense, e.g. even though my web server (akka-http) is based on futures, nothing prevents me from blocking inside my future, in most cases I can get away with it. As I understand it's not possible in Rust async model, I can only use non-blocking async functions inside async function. So in reality you don't interrupt or clean up anything in Rust when a timeout happens, you simply abandon execution (i.e. stop polling). I wonder what happens with resources if there were allocated.
Can you cancel a tight computing loop (i.e. without system calls and without yielding of any sort) with async? I wonder how? Also if you can inject a cleanup code in your async task what prevents you from doing it with threads? Such things existed long before async/await and system calls didn't change for async/await. Also, what's the difference between "framework" and async/await runtime, isn't the latter a kind of a framework?
You wait on a shared channel so both read and sleep threads queue a message when ready (whichever comes first). Not sure about channels, but in other languages it would be a concurrent queue.
As I understand when you are blocked on I/O and sends a signal to the waiting thread, that system call will simply be released and return an error. Ruby (Java etc.) does make it simple because of GC, so I don't need to worry about file descriptor leaks etc. But talking about Rust, shouldn't it be a part of a thread management? Basically if an error happens during normal blocking system call, it goes through the same sequence, no? E.g. you have to release any thread-local allocations no matter by each way system call was terminated. Rust threads are supposed to be memory safe, not sure about file descriptors. I don't quite understand what you mean by "yielding" though.
Not sure about Rust, but in other languages that don't have async: create a queue, spawn a thread with your task, thread with sleep and wait for a message from any of those two. Kill the still running thread when you get the message. Can't say it's incredibly hard (unless it's Javascript or you work in a single-threaded model in general).
In some sense it is. Async is a glorified future, and future is a glorified thread management, and threads are a way to facilitate asynchronous execution. You can also create a threadless runtime, but then you are relying on OS threads (e.g. I/O or XHR), otherwise you are simply combining function calls (for which we already have language syntax).
Not exactly sure how async in Python works, but if its runtime is non-preemptive and single-threaded (i.e. based on yield), then congratulations, you reinvented Windows 3.1! Those who are old enough to be "lucky" to use it, remember that the damn thing could hang the whole OS if your application was careless enough to block and not yield. Also "slow" is relative, if you create a thread to do DB query, thread creation is a way faster than any DB request, so not sure why it's slow. Never had problems with Ruby threads even though Ruby doesn't have a mechanism to create a thread pool (didn't have? it's been some time since I worked with Ruby). Java & Scala, OTOH are using thread pools, even multiple variations of them, so the thread startup time doesn't matter. In any case you are talking about I/O, in which case neither thread startup nor context switching matters.
If that door had hit horizontal stabilizer though we would have had a completely different statistics even with 1B hours. Fortunately it didn't happen, but with the current trend the idea that flying is always safer may become not so obvious, and "orders of magnitude" thing may disappear pretty fast.