3 ms·

> In Rust, all the unsafety of C is just 1 small keyword away. I really don't understand why people constantly bring this up. What's supposed to be the problem

> In Rust, all the unsafety of C is just 1 small keyword away. I really don't understand why people constantly bring this up. What's supposed to be the problem in the first place? Want a safe program? Just don't use "unsafe". Perfectly doable for the vast majority of programs. Java has its "sun.misc.Unsafe". In addition for being unsafe by default when it comes to modifying same data between threads. It doesn't enforce synchronization, so Java programs incorrect in this aspect compile just fine. > It's very hard to integrate Java and C. People don't normally do unless they have to. Random third-party libraries from internets usually don't. I don't see how this is related to the discussion.

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 ago
  Fair 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".

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 ago
Fair 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".