And even then it will warn in many situations. Unsafe does not suddenly make everything okay, it only allows 3 specific things that are otherwise not allowed.
Possibly, but decreasing the flight time still won't take much out of the equation that would make it a net win against normal aircrafts.
That's not saying there is no market for something like this, but for anything but the longest flights it's going to be a very specific kind of customer.
A Large part of the reason they couldn't easily address the UI performance was because of the old extensions.
The reason that Firefox switched to webextensions was in order to switch to a formal extension API that could be supported long term, instead of the old open integration API which made it difficult to readable without breaking all sorts of extensions.
There reason they adapted the web extension API that chrome uses, was because it largely made sense, was already pretty fleshed out and would allow extension writers that were already familiar with that to also target Firefox.
The earth-to-earth idea is nice, and whilst it would be an improvement, I expect the travelling time to be the biggest obstacle.
You have to gather the people, check them in and clear them during internation flights. Then you have to load everybody on a boat, ship them to the platform X miles into sea, unload them, take them up the big tower, letting them board and settle and depending on how predicatable this is, wait for clearance to take off.
Now is the short flight.
And afterwards we can do the entire thing in reverse.
Some things might be a bit more optimized, like perform customs, safety instructions etc during the boat trip. But the entire trip from arriving at the sea/space-port until leaving it at the destination would probably be making this a diminishing returns and only really interesting for the extremely long flights.
Not necessarily. Lots of people have a car and live more than 5 kilometers from the city center or their work. But a decent amount of people take their bikes when it is under 15 kilometers.
Grocery shopping is often less than 5 kilometers, but me and my neighbours often use the car for that (eventhough often it could be done by bike).
I think the biggest reason is purely cultural. It is normal (almost expected) that kids and teenagers go to school, sport and clubs by bike. You grow up riding a bike and it is your first real "liberation" from depending on your parents for everything.
It kinda represents freedom to go where you want to go before coming of age and being allowed to drive a car. (The minimum age to get your driving license used to be 18, though recently you can get a "starters license" at 17 as long as you drive under adult supervision).
And later on you realise that often taking the car, whilst great, isn't that more practical (and certainly not as economical) as taking the bike now and again.
Since refcounting only happens expicitly it should be pretty clear where possible drops happen that lead to large pauses.
It wouldn't be too hard to replace that Rc with an Rc that performs deferred drops by putting them in a queue and performing a number of drops at an oppurtune time (eg. using an idle-hook in a event loop).
It might even be possible to send all drops to a thread dedicated to dropping, but that would probably only work if the contents are Sync or Send. This form of async drops should always be possible for Arc.
But big pauses should rarely occur since refcounting is something that has to be added explicitly,
Rust is a language where compound types are used extensively instead of building dynamic structures using collections for trivial things and the use of Drop trait is not something that can be fully relief upon (making that most solutions try to go without using it). This should make most drops pretty lightweight, even when dropping large numbers of items.