3 ms·

So, from an executution model standpoint Rust is pretty close to C++ -- manual memory management, with RAII as the usual strategy for managing things. The big n

So, from an executution model standpoint Rust is pretty close to C++ -- manual memory management, with RAII as the usual strategy for managing things. The big novelty is that the type system actually enforces this, so you can't have dangling pointers, or forget to close a file, or... But most languages have had a solution to the resource problem at least as far as memory is concerned for a long time: garbage collection. It has huge advantages over Rust's approach, in that you can basically not think about RAII or ownership at all; as long as you're not actively holding on to an object, the memory will get reclaimed for you. But this doesn't solve the problem for other resources like files, since when a file is closed actually matters semantically. You don't want to just let the garbage collector decide when to shut down a tcp connection. So what the gp is suggesting is, it would be nice to have a language that uses GC where it makes sense, as it's generally easier to work with, but also provides sane mechanisms for releasing resources like files and sockets.

pjmlp 9y ago
> But this doesn't solve the problem for other resources like files, since when a file is closed actually matters semantically. You don't want to just let the garbage collector decide when to shut down a tcp connection. At least in some languages this is not an issue if one is able to use higher order functions, with bonus points if they allow for trailing lambdas. So if it is possible to organize the application architecture as regions where the resources are supposed to be valid, then one can manually get rid of such resources. Of course, this might not always be possible, and there is the caveat that one needs to remember to apply such patterns. Which is easier if it can be imposed via the type system.
- catnaroek 9y ago
  > At least in some languages this is not an issue if one is able to use higher order functions, with bonus points if they allow for trailing lambdas. I am afraid you are talking nonsense. Higher-order functions make verification harder, not easier, because they hide the point at which control flow is transferred from one module to another. This is backwards, because this point should be prominent, in big neon letters, precisely so that you can tell exactly when a resource stops being available, or when an invariant goes from being “your responsibility” to “someone else's problem”.
  - zenhack 9y ago
    I think pjmpl is referencing apis like this: with_file "hello.txt" (fun fd -> (* do stuff *) ) where you've basically created a c++ destructor style api with a lambda. It's certainly not "verification" in any formal sense, and the type system can't help you there any more than it can in c++. But this is a perfectly reasonable pattern.
    - catnaroek 9y ago
      > where you've basically created a c++ destructor style api with a lambda. Except for the part where destructors are meant to be called no more than once per object, at the end of its lifetime. All that you can guarantee is that `with_file` doesn't call the destructor more than once. But that's not terribly interesting.
      - zenhack 9y ago
        You can screw up destructors in exactly the same ways. And it also serves to make sure you close the file at all. But again hence the value of having the lifetime of the object enforced by the type system.
        catnaroek 9y ago
        In the presence of reference-counted mutable objects, destructors no longer guarantee that cleanup will happen. But that much is okay. This is a liveness property, and, as far as I can tell, nobody really knows of any non-annoying way to enforce liveness properties with types. On the other hand, “cleanup is the last operation that can be performed on an object” is a safety property, and types are excellent tools for verifying properties of this kind.
    - pjmlp 9y ago
      Yep, that was it. Thanks for the example.

pjmlp 9y ago

> But this doesn't solve the problem for other resources like files, since when a file is closed actually matters semantically. You don't want to just let the garbage collector decide when to shut down a tcp connection. At least in some languages this is not an issue if one is able to use higher order functions, with bonus points if they allow for trailing lambdas. So if it is possible to organize the application architecture as regions where the resources are supposed to be valid, then one can manually get rid of such resources. Of course, this might not always be possible, and there is the caveat that one needs to remember to apply such patterns. Which is easier if it can be imposed via the type system.

catnaroek 9y ago
> At least in some languages this is not an issue if one is able to use higher order functions, with bonus points if they allow for trailing lambdas. I am afraid you are talking nonsense. Higher-order functions make verification harder, not easier, because they hide the point at which control flow is transferred from one module to another. This is backwards, because this point should be prominent, in big neon letters, precisely so that you can tell exactly when a resource stops being available, or when an invariant goes from being “your responsibility” to “someone else's problem”.
- zenhack 9y ago
  I think pjmpl is referencing apis like this: with_file "hello.txt" (fun fd -> (* do stuff *) ) where you've basically created a c++ destructor style api with a lambda. It's certainly not "verification" in any formal sense, and the type system can't help you there any more than it can in c++. But this is a perfectly reasonable pattern.
  - catnaroek 9y ago
    > where you've basically created a c++ destructor style api with a lambda. Except for the part where destructors are meant to be called no more than once per object, at the end of its lifetime. All that you can guarantee is that `with_file` doesn't call the destructor more than once. But that's not terribly interesting.
    - zenhack 9y ago
      You can screw up destructors in exactly the same ways. And it also serves to make sure you close the file at all. But again hence the value of having the lifetime of the object enforced by the type system.
      - catnaroek 9y ago
        In the presence of reference-counted mutable objects, destructors no longer guarantee that cleanup will happen. But that much is okay. This is a liveness property, and, as far as I can tell, nobody really knows of any non-annoying way to enforce liveness properties with types. On the other hand, “cleanup is the last operation that can be performed on an object” is a safety property, and types are excellent tools for verifying properties of this kind.
  - pjmlp 9y ago
    Yep, that was it. Thanks for the example.