4 ms·

In Java, you can modify same data from multiple threads without the compiler complaining anything. In Rust that would cause a compile time error, until you sync

In Java, you can modify same data from multiple threads without the compiler complaining anything. In Rust that would cause a compile time error, until you synchronize the data.

cesarb 7y ago
Not only multiple threads, a common mistake is to modify a collection while iterating it, which can happen within a single thread (and it's even worse when it happens conditionally, so it'll only fail sometimes). The thing I love the most in Rust is the duality between "&mut" and "&": when you have a "&mut" reference to something, you know nobody else has any "&mut" or a "&" reference to it, so you can modify the data structure without worry; and when you have a "&" reference to something, you know nobody else has any "&mut" reference to it, so you can read the data structure without worry. I wish I had something like that in Java, instead of having to sprinkle "synchronized" everywhere just in case (which not only doesn't protect against a recursive call within the same thread, but also can lead to AB/BA deadlocks... which is made so much more fun by code called from executors which have a ThreadPoolExecutor.CallerRunsPolicy, meaning not only will it happen only in production, it will only happen in production when the system is overloaded. Took us weeks of debugging to reproduce one instance of that...).
Const-me 7y ago
In Rust, all the unsafety of C is just 1 small keyword away. It's used a lot in practice, both in standard and third-party libraries. 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.
- vardump 7y ago
  > 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".

In Java, you can modify same data from multiple threads without the compiler complaining anything. In Rust that would cause a compile time error, until you synchronize the data.

cesarb 7y ago

Not only multiple threads, a common mistake is to modify a collection while iterating it, which can happen within a single thread (and it's even worse when it happens conditionally, so it'll only fail sometimes). The thing I love the most in Rust is the duality between "&mut" and "&": when you have a "&mut" reference to something, you know nobody else has any "&mut" or a "&" reference to it, so you can modify the data structure without worry; and when you have a "&" reference to something, you know nobody else has any "&mut" reference to it, so you can read the data structure without worry. I wish I had something like that in Java, instead of having to sprinkle "synchronized" everywhere just in case (which not only doesn't protect against a recursive call within the same thread, but also can lead to AB/BA deadlocks... which is made so much more fun by code called from executors which have a ThreadPoolExecutor.CallerRunsPolicy, meaning not only will it happen only in production, it will only happen in production when the system is overloaded. Took us weeks of debugging to reproduce one instance of that...).

Const-me 7y ago

In Rust, all the unsafety of C is just 1 small keyword away. It's used a lot in practice, both in standard and third-party libraries. 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.

vardump 7y ago
> 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".