Serious question: Has anyone tested how much money you can actually make doing a month of Amazon Mechanical Turk? (It would make for an interesting YouTube video!) I am curious if it is middle class wages in very poor countries (like Nigeria). Some light Googling tells me that middle class salary in Nigeria is about 6K USD, so about 3 USD/hour (assuming: 50 weeks/year * 40 hours/week = 2000 hours/year). Is this possible with MTurk?
That's ok. AI will kill those off soon enough, and like all winners, rewrite history enough so that that inconvenient theft never happened anyway. It's manifest destiny, or something.
Haven't read the post, but I think there must be something wrong if a type's safety depends on the Drop trait due to the existence of std::mem::forget.
in Vec::drain() by setting the Vec len to 0, std semantically moves all elements from the Vec to the Drain and in in Drain::drop it semantically moves the non drained elements back
i.e. vec::Drain::drop is responsible for not leaking non drained elements, not for safety
and sure not leaking means positioning them so in the vec that the len can be set to a value where all elements from 0..len have not been moved out etc. but that doesn't change that semantically it's responsibility is "not leaking" instead "making sure it's sound".
- initially it was believed you can rely Drop for soundness
- then the rust community realized that this is an oversight -- the so called leakocalipyse
- there also was no easy straight forward way to fix that, in the end it was decided that leaking must be sound and `std::mem::forget` was added
- while there was some initial fallout (e.g. scoped threads and some &mut iterators now leaking collections if leaked) it wasn't to bad as you still can use function scopes to enforce some non leaking (i.e. if you accept a closure you can make sure something runs both before and after it)
- but with async functions a lot of the workarounds don't work anymore as the async function could be leaked mid execution by calling async functions ... so by now some people which rust had taken a different turn back then. But then to be fair this is the kind of "hypothetically wishing" because making leak sound was with the knowledge and constraints available back then very clearly the right choice.
That would make the lifetime last forever, preventing you from ever getting the mutable reference back and causing any safety issues. (Your intuition serves you well, though: graphics APIs designed to commit on a guard type's Drop::drop are prone to panicking, since the GPU driver does not care about Rust lifetimes. To implement that properly, you usually need ersatz typestates.)
The crucial bit for Vec::drain is in these two lines of code, which the article lists but does not discuss:
// set self.vec length's to start, to be safe in case Drain is leaked
self.set_len(start);
You cannot rely on Drop alone for safety, you need a fallback strategy in case of a leak (mem::forget or Rc cycle).
Rust lifetimes only ensure that there is no use after free; there is no guarantee that Drop is called before the end of the lifetime. It's possible to mutably access the original Vec after leaking a Drain.
and fails to properly convey outright stating both in the title and places in the article that drop can be responsible for safety (it can't, in drain it's responsible for not leaking non drained elements, not safety)
