Yes. All `&mut` references in Rust are equivalent to C's `restrict` qualified pointers. In the past I measured a ~15% real world performance improvement in one of my projects due to this (rustc has/had a flag where you can turn this on/off; it was disabled by default for quite some time due to codegen bugs in LLVM).
1. in most cases they don't want to handle `InterruptedException` or `IOException` and yet need to bubble them up. In that case the code is very verbose.
2. it makes lambdas and functions incompatible. So eg: if you're passing a function to forEach, you're forced to wrap it in runtime exception.
3. Due to (1) and (2), most people become lazy and do `throws Exception` which negates most advantages of having exceptions in the first place.
In line-of-business apps (where Java is used the most), an uncaught exception is not a big deal. It will bubble up and gets handled somewhere far up the stack (eg: the server logger) without disrupting other parts of the application. This reduces the utility of having every function throw InterruptedException / IOException when those hardly ever happen.
There is no apolitical, there never was. To say that you're apolitical is just an implicit endorsement of the status quo, coming from a place of privilege.
If this is enforced via Play Protect, then the whole mechanism can likely be disabled with:
adb shell settings put global package_verifier_user_consent -1
This does not require root access and prevents Android from invoking Play Protect in the first place. (This is what AOSP's own test suite does, along with other test suites in eg. Unreal Engine, etc.)
I personally won't be doing this verification for my open-source apps. I have no interest in any kind of business relationship with anyone just to publish an .apk. If that limits those who can install it to people who disable Play Protect globally, then oh well.
They're also the best equipped to tell if you've done so, and restrict access from critical functionality needed by many in their day-to-day lives if you've done so.
The intentions behind all the security hardware they introduced in pixel phones first, and is now required by play integrity to function might've been well-meaning, but that doesn't really matter in the end. Security features that the user can't control and bypass aren't security features - they're digital handcuffs.
Software compatibility in general. There’s still a lot of Windows-only software out there that people rely on.
Also, security-by-default for apps would be nice. Snap and Flatpak are great starts but it’s still to difficult to manage and too easy to install non-sandboxed software. Some random weather app should never have access to your photos, camera, file system, networking, etc… without the user explicitly granting permission.
This is all about the revival of pebble-bed reactors, which were attemped several decades ago but had problems with the graphite pebbles breaking down and releasing graphite fragments that clogged the pipes, basically. China is way ahead on this with helium-cooled versions. The big deal is that in the event of complete power loss (see Fukushima) they go into shutdown without melting down, although if the coolant lost and replaced with air you would get a nasty Chernobyl-style graphite fire. Still an improvement in safety. See:
> "Several high-temperature thermal neutron–spectrum pebble bed reactors are being commercialized. China has started up two helium-cooled pebble bed high-temperature reactors. In the United States, the X-Energy helium-cooled and the Kairos Power salt-cooled pebble bed high-temperature reactors will produce spent nuclear fuel (SNF) with burnups exceeding 150 000 MWd per tonne. The reactor fuel in each case consists of small spherical graphite pebbles (4 to 6 cm in diameter) containing thousands of small TRISO (microspheric tri-structural isotropic) fuel particles embedded in the fuel of zone these pebbles."
(2024) "Safeguards and Security for High-Burnup TRISO Pebble Bed Spent Fuel and Reactors"
I don't know what point you're trying to make here. Obviously developers will choose to break compatibility every other day for very flimsy reasons -- I have a million examples, including "Why did Conversations decide to remove OTR support ?" Or even "why are you forking software at all in Snikket?".
My problem here is that XMPP encourages this by adopting a _breaking change_ to a protocol. To my knowledge this is not a client deciding to go out of its way to break compatibility, it's a client deciding to implement the current version of OMEMO and as a consequence ending up incommunicado. If you look at the most recent version of popular XEPs you'll end up with a client that can talk to nobody. This is not a good example of stewardship and doesn't look good look as a candidate for replacing email, a protocol that must last for at least half a century. Core XMPP did look good candidate, but the chase for the shiny has corrupted this protocol as has countless others. Same reason we're down to basically only two workable Jabber server implementations.
Arguments like "oh don't worry, we'll smooth things over by updating all clients in tandem" just don't make me see things better, because I know by experience that it never happens in practice.
I read Potassco's Answer Set Solving in Practice book [0] but it's pretty dense. I suspect it would be easier to digest if you read it while also following their course materials, which are all online [1].
These days I recommend people start with the Lifschitz book [2] and read through the Potassco book [0]. Lifschitz's book is a much gentler introduction to ASP and logic programming in general and its examples are in ASP code (not math). It's also more geared towards the programming side than the solving side, which is probably better for most people until they really want to understand what clingo/gringo/clasp are doing and what their limitations are.
There are other more applied courses, like Adam Smith's Applied ASP course at UCSC [3]. The problems in that course look like a lot of fun.
