Note that the paper was written a while ago, so things are a bit outdated (like the integer overflow bit). > Just-in-time code. I'm not the expert on this, bu

Note that the paper was written a while ago, so things are a bit outdated (like the integer overflow bit). > Just-in-time code. I'm not the expert on this, but JIT is where a lot of perf wins can be had for javascript. JIT might even be the best place to work on if you want to make your polished JS engine faster. As far as security goes, goto Lars' reply. > Integer overflow/underflow. We now do exactly what was suggested in the paper. Rust enables overflow checking in debug, and we run our CI in debug anyway (release mode build integration is half baked now and I need to work on that) A concrete example would be a loop that just goes on incrementing something. `for _ in 0..n {ctr++}`. This would be zipped to ctr+=n in release mode (optimizations and no bounds checking), but in debug mode there would be bounds checking making it harder to optimize. Additionally in the real world analogue of this toy example, there would be other slowness in debug, and we wouldn't hit the overflow condition. Here's a case where a Rust API has issues, but only when bounds checks are off: https://internals.rust-lang.org/t/rc-is-unsafe-mostly-on-32-bit-targets-due-to-overflow/2120 https://internals.rust-lang.org/t/rc-is-unsafe-mostly-on-32-... > Unsafe code correctness So, Rust being Rust the situation is vastly better than C++ or similar. But we still have tons of unsafe bindings and also unsafe being used for perf. Last rust upgrade we had an unsafe transmute of a refcell that broke stuff and caused a confusing segfault in some code far away. Proving correctness is hard, though. C++ is riddled with undefined behavior, and `unsafe` shares a lot of that UB, plus more UB due to assumptions that rustc makes. When you write `unsafe`, writing code as if you're in the wonderful world of C++ won't work. There are assumptions like "&T will never be mutated" which rustc will make, which should hold even in unsafe code, and if you do something to break that, you cause UB. On top of that Rust hasn't been properly formalized yet. So this is something that's still far off for us. However, a limited form of correctness checking sounds doable-- but I don't have much knowledge of formal checking to be sure of this. Of course, a limited form of unsafe correctness as proposed in the paper