4 ms·

Rust's type system supports any type of resource, not just memory. The same isn't true for garbage collectors (and no, "finalizers" is not correct resource mana

Rust's type system supports any type of resource, not just memory. The same isn't true for garbage collectors (and no, "finalizers" is not correct resource management). Also, real enum types (including optional) and pattern matching. I'm sure you can come close with Java using interfaces or something, but it's going to be cludgy and tedious in practice (especially if you have primitive variants). To be clear, I'm only stating that Rust is safer, not that safety is the end-all-be-all for every single application and you should never use COBOL or Java or even that you should prefer Rust over them in the general case or anything of the sort.

blub 7y ago
And I'm stating that I don't see why it's safer than Java, even if Java doesn't have pattern matching (it does have optional). It is nice to be able to encode something in the type system, but one could just as well use design by contract or unit testing, and these actually do have supporting evidence in their favor. Is there even any supporting evidence that static typing results in better quality? I think most would agree that it improves performance, makes refactoring and managing the code base easier. Note: I'm also a fan of static type systems and of encoding relationships and requirements in them, but I have no proof that this actually improves quality. It makes things easier to reason about for me and maybe it eliminates some classes of errors, however it's not obvious that these classes of errors represent a noticeable amount of the total.
- vardump 7y ago
  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.
- nicoburns 7y ago
  Lack of exceptions, and forced error handling is a big deal. As is explicitness around null.

blub 7y ago

And I'm stating that I don't see why it's safer than Java, even if Java doesn't have pattern matching (it does have optional). It is nice to be able to encode something in the type system, but one could just as well use design by contract or unit testing, and these actually do have supporting evidence in their favor. Is there even any supporting evidence that static typing results in better quality? I think most would agree that it improves performance, makes refactoring and managing the code base easier. Note: I'm also a fan of static type systems and of encoding relationships and requirements in them, but I have no proof that this actually improves quality. It makes things easier to reason about for me and maybe it eliminates some classes of errors, however it's not obvious that these classes of errors represent a noticeable amount of the total.

vardump 7y ago
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.
nicoburns 7y ago
Lack of exceptions, and forced error handling is a big deal. As is explicitness around null.