This app exists, it's called indrive
50 karma · joined October 13, 2018
Blockchain is heavily constrained by the vital requirement of not trusting any third party whatsoever. If you relax this, you can build much simpler systems that are equally secure regarding non-repudiation and other properties but doesn't need proof of work.
They even backtracked their version of IO, that used row types to track effects - because it just wasn't worth it.
It uses a Cargo feature meant to be used by native libraries: you typically can link them only once (or else the build will fail when it finds repeated symbols), so Cargo must ensure only one is present on the entire dependency graph. And IIRC Rayon depends on an auxiliary crate that fakes a native lib and provides the thread pool.
If this seems very hacky and convoluted, it's because it is.
Your users didn't hire the bouncer and don't want to be tracked. Secretly, the bouncer may use this data for nefarious purposes. You can't control how the bouncer will use the data.
I happen to (wishfullly) think the next major OS will have capability-based permissions at the core level, a model a bit like Mobile permissions but composable. Good thing that Google's Fuschia is based on capabilities. It's in C++ though.
However, we don't have yet means to emulate downcasting for trait objects, except by using the Any trait (which is a footgun). Until then, class based OOP is more expressive than whatever Rust is doing now.
The trouble is, this is hard to do for non-trivial code (and in the general case is uncomputable).
At some point it becomes uneconomical to use this waste heat rather than discarding it.
The usual complexity classes of decision problems, such as P and NP, are subsets of what a Turing machine can solve, and so are weaker complexity classes.