And their viewers presumably want to view it.

I think there are a few reasons we have landed on the model we have.

1. People don't like unbounded liabilities. This is scary enough with regular web-hosting but given the huge size of video files, hosting them on your own website was frankly terrifying.
2. Most people (both viewers and creators) don't' want to pay actual cash for messing about online, so ad-driven services rule the roost, it's much easier to do that if you have scale.
3. Many of the major platforms ran at a loss for years and may still be doing so, at least in terms of direct profits. Afaict both Twitch and Youtube post revenue figures but not profit figures.

The authorities control all the exits sure, but unless they plan to search the devices of everyone on the plane, it's difficult to see how they could determine who was behind the mischief

The headline talks about eliminating the disease, but the body talks about stuff like reducing the number of deaths below some threshold, that doesn't sound like "elimination" to me. Am I missing something?

The problem is we don't have a control group of people who don't ingest microplastics but are otherwise the same as those who do. We can of-course compare the health of people from more and less contaminated areas, but those more and less contaminated areas will likely also differ in other ways, both known and unknown, that may have more significant effects than the microplastics.

Depends where you live.

Here in the UK, most employers started insisting on payment to bank account years ago, and cheques stopped being used at retail when the cheque gaurantee card scheme was shut down in 2011, but they are still used in other contexts, particularly for one-time payments. Traditional high street banks still issue and accept cheques, though I've heard that some no longer hand out chequebooks by default and some of the challenger banks are more problematic.

I understand in the USA, Canada and France cheques are far more widely used than here. OTOH many European countries are much further along the path to getting rid of them than us.

The roguelike games also have a low barrier for people who want to write their own, as there are freely available graphical tiles, libraries such as Doryen to do the heavy lifting, and plenty of tutorials covering most programming languages. See https://roguebasin.com/index.p... for some tutorials.

Most existing games are open-source, so if creating a new game doesn't appeal, you can download your favourite and start changing it to be more to your liking.

by far.

I think that is pushing it.

If I'm counting correctly there have only been 9 crewed flights of falcon 9/dragon. 1 spacex demo, 6 operational flghts for NASA and 2 private flights.

By contrast there were 135 crewed space shuttle flights, 2 of which resulted in loss of crew.

One accident would essentially take spacex's record on crewed flights from best to worst.

Now the total number of falcon 9 launches is much higher, but those haven't been without incident, one blew up on the pad prior to launch, and one broke up in flight. Hopefully nothing simlar will happen on a crewed launch and if it does hopefully the launch escape system will do it it's job.

OTOH much of the point of a video game is to let you escape the drudgery of real-life. People will tolerate an hours drive in real life, not so much in a video game. You can put in fast uncongested highways and let the player drive like a maniac but i'm still not convinced you can go much bigger than GTA Vs map without getting really annoying.

The tricky bit with trackers was always how to get the signal out at a minimal cost, both in financial and power terms.

What apple did with the airtag was leverage their massive installed base of phones to solve that problem.

IMO there are multiple different categories of UB in C/C++.

Some UB just reprepresents pig-headedness on the part of compiler writers and standards organisations. The optimisation benefits are massively outweiged by the fact that they make even the simplest operations (like addition) into potential footguns.

Some UB is arguable, stuff like the aliasing rules. On the one hand i'm not convinced the optimisation opertunities justify the extra mental load, on the other hand they relate to things (like pointer typecasts) that should be used sparingly anyway.

These first two categories could be got rid of quite easily if there was the will to do so. Indeed in gcc there are actually compiler flags to turn many of them into defined behaviour for those who can be bothered to actually RTFM.

But there is a third category of UB. UB that represents fundamental consequences of the language and library design and of low level programming in general. This last category includes stuff like buffer overflows (and sometimes underflows), stale pointer de-references, double frees.

I don't think this third category can ever be done away with completely in low level programming. The best you can hope for is to do what rust tries to do and compartmentalize it but I can't see how you can do even that without language and library changes radical enough that you may as well call it a new language.

A particular problem is the combination of sharing and mutability. Lets take for example I have a type that represents a string, it has a pointer to the string data, a length and a capacity. I read the pointer and start a loop of read character, process character, increment pointer until I reach the end of the string.

However, while the code working through the string some other peice of code comes along, maybe another thread, maybe an interrupt handler, maybe a callback function. This other piece of code appends a character to the string, triggering reallocation of the string. Suddenly the first piece of code has a stale pointer.

Rust gets around this by forbidding shared mutability in safe code except under very specific circumstances but I really don't see how you can solve this problem for an existing language and library ecosystem.

Do a benchmark on a production workload on a real application and we'll talk. Pretending like this project with 360 github stars is somehow authoritative for every language is silly.

Doesn't address the issue of how the concurrency was set up for these synthetic benchmarks, which again bear very little resemblance to a real web application task. Javascript has a different concurrency model and again, unrealistic compared to how a real web browser would run this.

The other thing about this particular set of benchmarks is that it's actually selecting for languages with good parallel threading support and concurrency in general, which has been a weak point of Ruby until recently. I don't know what threading approach they used but there are newer approaches such as Fibers instead of Threads, or the Ractor pattern. They also left elixir and erlang off the list. Elixir is a language with Ruby-like semantics but the concurrency of erlang. I'd be interested to see how it compares to JS.