1) Rust's standard idioms (in this case, Results and Iterators) encourage less bug-prone or ambiguous APIs (standard and otherwise)
2) Rust's ecosystem makes it easy to find and integrate solutions not offered by the standard API
3) And then finally, Rust's borrow checker prevented a threading issue
Others are rightly pointing out that only #3 is fundamentally unique to Rust. All of these other things could be done for C++. But, importantly, they haven't.
This raises an interesting dimension to the comparison which is that many of Rust's advantages don't really come down to its unique traits (heh) but to the simple fact that it's "C++ without baggage". It had a fresh start when it came to establishing standard idioms for everyone to use, providing cross-platform tooling for everyone to use, providing centralized package management for everyone to use, etc. If you introduced to C++ a Result type, or a package manager (I assume people have done this already), most C++ developers wouldn't end up using them. Most libraries wouldn't be using the same vocabulary. It would be arduous to even move the standard library over, because it would be a breaking change. Much of the tooling out there would probably never get specialized support.
I don't think these network effects and cultural forces get talked about enough. Sure, this stuff is "just a library", and C++ has libraries. But the culture and the baggage and the stakeholders around a language have a huge impact on what ends up being practical to do with it, independent from what's technically possible.
It's humorous but I don't like normalizing the idea that it's OK for authority figures to lie to the people they are charged to protect. That's part of the mess we're in with policing.
Let's say Apple allows everything that Epic etc. is asking for. Would it really be better for everyone?
---- The problems with letting all apps advertise external payment systems:
• Someone may publish a free app to avoid paying anything to Apple, and then charge users [an asston of] money to ""unlock"" via an alternate payment system.
• Users may not be able to see a list of all in-app purchases (and their guaranteed prices) as they can on the App Store, without downloading the app.
• Sharing your payment details and other information with multiple entities, and having to continually trust each of them (e.g. to not abuse or leak).
• Confused users may clog up Apple's customer support with complaints related to third-party payment systems.
• Angry users may demand Apple to offer refunds for shit that was paid for via third-party payment systems.
---- The problems with allowing third-party app stores on iOS:
• How will iOS sandboxing be enforced for apps delivered via third-party stores? Will those apps still have to be submitted to and signed by Apple?
• Store apps would need the privilege to write binaries on your iPhone. How will that privilege be regulated to prevent abuse? e.g. what happens if a store starts writing malware?
• Users may sometimes have to wait longer for an app to update on one store than on others (as already happens on Steam vs GoG).
• Developers would no longer be assured that they will have access to literally all the users that iOS has, by publishing on just one store.
You would have to submit to each store, wait for approval on each of them, update for each of them... to come close to the userbase that you can currently access by just publishing once on the App Store.
• Developers will no longer all play by the same rules. One store may allow some content while another may prohibit it.
For example, take porn: Should any third-party store be allowed to serve apps with "adult" content, or will they still ultimately be bound by Apple's ruling on such matters?
• iOS Parental Control settings may be ineffective on other stores (and browsers if third-party engines were allowed too).
• If an app or game is exclusive to a store that a user isn't already using, they would have to create a new account and download an additional app just to access that one exclusive.
• Not all stores may be compatible with the iOS backup and restore system, or the APIs for app-thinning and on-demand resources.
They licensed the OS to you with a specific set of permissions to enable a specific business model. I understand how you would want them to not get paid but I don't see how that's fair.
If a customer wants a different app store, the customer can buy a non-apple device. Apple doesn't have a monopoly in mobile devices or app stores.
DRM is just security theater that makes us all culturally poorer. Give me the name of a movie on Netflix or any of the other mainstream streaming services, and I'll find you a high-quality copy of it, often with subtitles in many different languages, for the cost of a usenet subscription (you don't even need to worry about a DMCA notice from your ISP for torrenting). DRM is not stopping anything. The studios and streaming services have made it just convenient enough to pay, with nice UI/UX on top.
The reason people pay is the convenience! The DRM isn't required for that. If they dropped all DRM tomorrow, they would lose far fewer subscriber dollars than they spend on DRM implementations, license servers, key management, etc. They're just greedy, want control, and want to keep it illegal to break out of that control.
Meanwhile, any media "purchases" you make are gone in a blink if the company you bought them from goes out of business or just decides they don't feel like offering the service anymore. The funny thing is that most of the buy-to-"own" (where you don't actually own it) prices are similar to the cost of a DVD or blu-ray disc. Ditto for Kindle books and their paperback counterparts. All the promises of digital distribution giving consumers lower prices were predictable lies.
I'm surprised nobody mentioned that Windows Defender does something very similar (checking for never-seen-before binaries at runtime, uploading them to Microsoft servers, then running them there) : https://news.ycombinator.com/item?id=21180019
1) Rust's standard idioms (in this case, Results and Iterators) encourage less bug-prone or ambiguous APIs (standard and otherwise)
2) Rust's ecosystem makes it easy to find and integrate solutions not offered by the standard API
3) And then finally, Rust's borrow checker prevented a threading issue
Others are rightly pointing out that only #3 is fundamentally unique to Rust. All of these other things could be done for C++. But, importantly, they haven't.
This raises an interesting dimension to the comparison which is that many of Rust's advantages don't really come down to its unique traits (heh) but to the simple fact that it's "C++ without baggage". It had a fresh start when it came to establishing standard idioms for everyone to use, providing cross-platform tooling for everyone to use, providing centralized package management for everyone to use, etc. If you introduced to C++ a Result type, or a package manager (I assume people have done this already), most C++ developers wouldn't end up using them. Most libraries wouldn't be using the same vocabulary. It would be arduous to even move the standard library over, because it would be a breaking change. Much of the tooling out there would probably never get specialized support.
I don't think these network effects and cultural forces get talked about enough. Sure, this stuff is "just a library", and C++ has libraries. But the culture and the baggage and the stakeholders around a language have a huge impact on what ends up being practical to do with it, independent from what's technically possible.