3 ms·
> What's supposed to be the problem in the first place? Bugs like this one: https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable-for-years-an
by Const-me 7y ago
> What's supposed to be the problem in the first place?
Bugs like this one: https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6 https://medium.com/@shnatsel/how-rusts-standard-library-was-...
> Want a safe program? Just don't use "unsafe"
There’s a lot of unsafe code already in standard library, even more in third-party libraries.
For this reason, I think VM-based runtimes are safer in general. It’s not free like in Rust, costs runtime performance especially startup time. But for Rust, we have to trust authors of standard library, and all other libraries we consume. That’s too many people to trust, and too much code to verify.
> I don't see how this is related to the discussion.
Java standard library doesn’t use unsafe code, it’s all pure Java, e.g. https://zgrepcode.com/java/openjdk/10.0.2/java.base/java/util/vector.java https://zgrepcode.com/java/openjdk/10.0.2/java.base/java/uti... Same with vast majority of third-party libraries.
Security boundary is lower on the stack, attack surface is much smaller at that level. We only have to trust/verify JVM code. Everything that runs on top of that, including the standard library, runs in a strong sandbox.
- vardump 7y agoFair point. I guess you could say Rust is just as secure as the weakest library routine you call from your code. That said, in C++, unsafe is just form example a harmless looking pointer cast or array [] indexing away. At least with Rust you know where the dragons lie. Just grep for "unsafe".