> “just ban simple automatic storage duration structure copying” is a terrible usability and horrific ergonomics decision to make
This sounds like a great idea to me! Rust disables implicit copying for structs with destructors, and together with move-by-default, it works really well. Unlike PoD structs, you don't need to heap allocate them to ensure their uniqueness. Unlike copy constructors, you don't need to worry about implicit copies. Unlike C++ move, there's no moved-from junk value left behind.
> Rust disables implicit copying for structs with destructors
"Disabling" is maybe not the right way to think about it. Rust only has "implicit copying" for Copy types, so you have to at the very least #[derive(Copy,Clone)] to get this, it's true that you can't (and therefore neither can a derive macro) impl Copy on types which implement Drop and that's on purpose but you're making a concrete decision here - the answer Rust knows is never correct is something you'd have to ask for specifically, so when you ask it can say "No" and explain why.
Lots of similar behaviour in C++ is silent. Why isn't my Doodad behaving the way I expected? I didn't need to ask for it to have the behaviour I expected but the compiler concludes it can't have that behaviour, so, it doesn't, and there's nowhere for a diagnostic which says "Um, no a Doodad doesn't work like that, and here's why!"
Diagnostics are hard and C++ under-values the importance of good diagnostics. Rust recently landed work so libraries can provide improved diagnostics when you try to call them with inappropriate parameters. For example now if you try to collect() an iterator into a slice, the compiler notices that slice doesn't implement FromIterator and it asks FromIterator to explain why this can't work, whereupon FromIterator notices you were trying to use a slice and emits a diagnostic for this particular situation - if you'd tried to collect into an array it explains how you'd actually do that, since it's tricky - the slice is impossible since it's not an owning type, you need to collect into a container.
IMHO it would still be a useful feature, just one that is not strictly needed. You are not able to to pass around such structs, but neither is that possible with the suggested `defer` statement. The only advantage of `defer` is that the destructor code is inline, rather than in a separate destructor function.
But you could gain reusability of headers to be also used in C++, not needing to reinvent the wheel with new issues (e.g. variable lifetime), and a whole lot of existing experience with RAII.
- A train will take you right into the city center, sometimes even where cars are not allowed. OTOH entering the city from suburbia can take an hour of being stuck in traffic.
- metro and trams can skip traffic. Bus lanes are common. There are no "stroads". Average car speed in London is 12mph. That's slower than a bike.
- Finding a parking place can easily take longer than waiting for public transport, and it will probably be an underground garage, far away from your destination. Bus stops are much denser than parking garages, so they usually involve less walking.
The US experience of driving on an 8-lane highway and arriving at a mandatory-parking-quota asphalt desert in front of your destination is rare in Europe. The closest we get is a 3-lane motorway to an IKEA on the city outskirts.
So basically make the urban environment a sea of constant fast driving cars filling all available space. There's a reason a lot of cities are converting roads and urban centers into non-car area. Parking and car lanes replaced with bike paths and green areas. It's a much better quality of life. Which, oddly, some people prefer to a 1800s style corporate dystopia where most people's miserable lives are nothing but a means to drive ever more wealth to an elite minority.
In Europe, Tesla uses the CCS2 standard (like everyone else except the Leaf), and Tesla's network is just one of many. It doesn't have a significant advantage. European Teslas even suggest 3rd party chargers in the built-in nav.
In some places it may even be better to buy an 800V EV, and use the faster Ionity and Fastned networks.
gifski is also maintaining consistent Floyd-Steinberg dithering across frames (basically dithering in 3 dimensions).
This allows more reuse of the background colors, and keeps file sizes lower by avoiding adding unnecessary temporal noise. Other converters that remap and dither each frame independently will needlessly create unique noise patterns in each frame.
I've set it up for an elderly person, and it backfired terribly — they lacked dexterity to reliably turn it on and off, forgot the feature existed, and then one day accidentally zoomed in screen by only a few percent, and though the phone broke, because "the status bar has disappeared".
I don't think you need to infer that Apple believes they own every device.
You don't need to infer anything, really. You just need to observe that every corporation will engage in rent-seeking behavior whenever they're in a position to get away with it.
Apple is far from the first mobile device maker to try to make it difficult or impossible to install software through alternative channels. That practice has been in place since before the invention of the smartphone. Google likely would have done the same thing with Android, had it not been far more profitable for them to take a different tactic. Heck, in the USA, back in the analog landline phone era, the Bell system famously did functionally the same thing until regulators stepped in.
On that note, I'm annoyed that Apple does it, but I'm even more annoyed that, in the USA, we are absolutely toothless about regulation because we can't shake the pollyannaish belief that we should be able to expect corporations to play nice purely out of the goodness of their nonexistent hearts.
> Google likely would have done the same thing with Android, had it not been far more profitable for them to take a different tactic.
I don't think that's fair. You have to consider the culture at Google and pre-Google Android. It might be the case, but at the time it felt like a very natural way for them to go.
> On that note, I'm annoyed that Apple does it, but I'm even more annoyed that, in the USA, we are absolutely toothless about regulation because we can't shake the pollyannaish belief that we should be able to expect corporations to play nice purely out of the goodness of their nonexistent hearts.
Agreed, though I think this is a cultural problem more than a regulatory problem. We humans are suckers for good marketing, as Apple has masterfully demonstrated over the years. Some of their real life PR/marketing lines are indistinguishable from parody, yet people's faith and trust in Apple is at or near a religious level of devotion. They love the products and they desperately want to believe in the goodness of the creator.
Unless/until we figure out how to pull the curtain back so people see through the spin, they will stay powerful. Once we do that, the regulation will follow naturally.
I've used to excuse such behaviors, saying that Apple has better integration between their products, cares about UI design more than anybody else, or that such integrations are new and don't have proper APIs yet.
However, years have passed, and Apple has been systematically giving preferential treatment to their apps and services, while dragging their feet on APIs for 3rd parties.
They keep using genuinely useful aspects of the App Store as a shield for anti-competitive abuse and petty rules (only in Apple's imagination allowing apps to mention other platforms is the same thing as allowing malware).
They've been spreading FUD and presenting false dichotomies that it's either exactly Apple's way, or chaos and malware. Instead of creating safe and efficient APIs for 3rd party browser engines, they chose not to have competition for Safari instead. Instead of creating APIs for easy centralized subscription management, they conveniently kept it exclusive to their own subscriptions, with pricing that can only be sustained in a duopoly.
Apple had plenty of time, and lots of chances to ease off their worst anti-competitive behaviors to keep regulators away, but instead they've doubled down on owning the platform and their users, and are now throwing tamper tantrums and malicious compliance.
I appreciate the more thoughtful comment! I agree with some of it, and disagree with some of it -- which isn't possible when you try and boil it down into a one-liner.
There are literally thousands upon thousands of comments debating both topics ("owning" an apple device & app store stuff) on HN alone. Let alone everywhere else from reddit to governments.
If it was so simply one-sided, there wouldn't be such lively debate.
I don't think we need to rehash those thousands of comments to agree that the debate can't be settled in a single blanket statement?
I don't really have the same impression that you have had when it comes to discussions about Apple's approach to HN.
This linked comment (which I randomly found on HN's search) summarises what I've seen here:
"The way these discussions usually go is that a bunch of Apple users complain about the restrictions, a bunch of Apple users say they like them, and a few Android users like myself remind the complainers that there are, in fact, other options that don't involve forcing Apple to take away the rules that most iOS users appreciate having."
I do recall a few users opposing allowing alternative app stores (which is the debate that is freshest in my mind) because they prefer to stick to Apple's, and the common rejoinder from the community that nothing is being taken away from those who prefer to stick to Apple's store but that other users who want something different have more choice.
I'm still curious about what additional nuance you have in mind, since I honestly can't remember seeing it.
You cannot summarize thousands of comments (there's nearly 4000 comments between [1] and [2] alone) in sentence or two and pretend like it is representative of the entire debate and everyone's opinion.
Even so, your quote and further commentary proves there is more nuance to be had -- some Apple users are complaining, some Apple users are defending, others are suggesting compromise! The nuance can be found when you examine how those separate groups of people came to their opposing opinions. To say there is no nuance, yet give an example of a more nuanced argument is almost funny.
While I have absolutely no interest in debating it, the example that first came to my mind regarding the "Apple thinks they own every device" comment was the nuanced debate around security, especially in relation to the target market of the devices.
Thanks; I didn't see that debate on security and I can see it being a valid point, especially with the burden of a technically-inclined person having to fix others' (family/friends) devices.
I was trying to point to the opinion of the majority that I've seen and what I have seen from most of the community when security is mentioned is that Apple needs stronger security from a technical standpoint rather than controlling what and what is allowed on users' devices. I think both opinions hold validity, and you may be right that there is more nuance.
Yes, you could. But be careful to make sure that there's no more data left after the decoder finishes, because it's possible to append a ZIP file (or acropcalypse) at the end of any other valid image file data, and decoders usually stop at the end of the image and don't parse past its end, so won't complain about extra data.
