307 karma · joined November 16, 2021
While doesn't matter much in the rest of the policy, this is a common misconception among AI skeptics. It is not the case for a long time (since RL is used heavily in the training) and a LLM may go beyond its training data.
Integer overflows are not checked in release builds by default, since they are not related to memory safety.
On the other hand, rust emits noalias everywhere, which helps in autovectorization.
It's not adb / avd or some device emulator. It's an app that you install on your device, and then it can load your app from your development device using a link. I was able to run it in 5 minutes without having android studio or any other android development kits on my laptop.
Unprivileged services can exploit known compiler bugs and do anything they want in safe Rust. How this affects their security model?
If you want to immediately use a C++ library in Rust with minimal manual effort, check out autocxx [0]. Its generated api isn't very idiomatic Rust, and it uses Pin, moveit, ... but it covers a good percent of C++ apis and you can also make an idiomatic wrapper for it in Rust.
That level of difference doesn't matter. The point is that WASM is a portable and sandboxed target (like JVM) which is (or will be) faster, more secure (e.g. capability based security in WASI) and with more language support (strictly more when optional GC becomes a thing) and other differences are implementation details.
FYI, Sourcegraph supports LSIF generated by rust-analyzer. For example, https://sourcegraph.com/github.com/matrix-org/matrix-rust-sd... shows lock method belongs to tokio. It should be able to show origin of write_u16 as well (In the precise mode, not search based).
Gitlab can also consume LSIF, and github should do it someday, IMO, their current way doesn't scale. In most languages you should implement a full compiler front end in order to provide a 100% correct goto definition.