6 ms·

Why would you want to burden a GC'd functional language with the syntactical and semantic requirements of Rust's resource management?

rcaught 9y ago
Karma?
Rusky 9y ago
To provide stronger types in some cases? To opt into in performance-sensitive programs? To see if it can be made less burdensome if different tradeoffs are made?
- abiox 9y ago
  what do you mean by "stronger types"?
  - testestx 9y ago
    Affine and linear types and variants (ownership types, uniqueness types) can model predictable release of resources, like a compiler-enforced C++'s RAII. As another commenter put, > The paper explains it's because they want deterministic destructors for things like file handles.
skybrian 9y ago
The paper explains it's because they want deterministic destructors for things like file handles.
catnaroek 9y ago
Because Rust-style resource management is not only about performance, but also about correctness. And the ML crowd cares a lot about the latter - rightly so. I'd kill for a language with ordinary ML types for values (integers, strings, etc.), and substructural types for objects (file handles, database connections, etc.).
- nickpsecurity 9y ago
  "I'd kill for a language with ordinary ML types for values (integers, strings, etc.), and substructural types for objects (file handles, database connections, etc.)." Could you explain what that means and how it benefits compared to common languages discussed here? Those of us from imperative backgrounds mainly read these threads to learn ideas that we might move into such languages.
  - zenhack 9y ago
    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.
sitkack 9y ago
To escape the GC and have determinism. Ownership annotations will eventually make it into all languages. They orthogonal to types. Optional type annotations will eventually make it into all languages. And at that point, we will have some sort of common semantic substrate to root all of current languages on.
- rs86 9y ago
  Ownership in rust is determined from the type system using linear types.
pjmlp 9y ago
Because you can enjoy the productivity of working in a GC functional language, and only use affine types when critical to do so. Just like GC enabled systems programming languages do provide ways of manually managing resources in performance critical sections.
masklinn 9y ago
1. deterministic resource management (locks, files, …) 2. affine & linear types are actually useful modelling tools e.g. to make state machines statically non-rollbackable/duplicable (this is related to resource management as those are generally the STMs you want to lock down)
thesz 9y ago
You may employ non-trivial optimizations to a program which are not available in the Rust compiler and then output to, say, Rust. Or C. Also, you can easier combine different parts of a program, creating algebraic structures not available in Rust. Rust does not support higher-order functions nicely, OCaml does, for one example.

rcaught 9y ago

Karma?

Rusky 9y ago

To provide stronger types in some cases? To opt into in performance-sensitive programs? To see if it can be made less burdensome if different tradeoffs are made?

abiox 9y ago
what do you mean by "stronger types"?
- testestx 9y ago
  Affine and linear types and variants (ownership types, uniqueness types) can model predictable release of resources, like a compiler-enforced C++'s RAII. As another commenter put, > The paper explains it's because they want deterministic destructors for things like file handles.

skybrian 9y ago

The paper explains it's because they want deterministic destructors for things like file handles.

catnaroek 9y ago

Because Rust-style resource management is not only about performance, but also about correctness. And the ML crowd cares a lot about the latter - rightly so. I'd kill for a language with ordinary ML types for values (integers, strings, etc.), and substructural types for objects (file handles, database connections, etc.).

nickpsecurity 9y ago
"I'd kill for a language with ordinary ML types for values (integers, strings, etc.), and substructural types for objects (file handles, database connections, etc.)." Could you explain what that means and how it benefits compared to common languages discussed here? Those of us from imperative backgrounds mainly read these threads to learn ideas that we might move into such languages.
- zenhack 9y ago
  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.

sitkack 9y ago

To escape the GC and have determinism. Ownership annotations will eventually make it into all languages. They orthogonal to types. Optional type annotations will eventually make it into all languages. And at that point, we will have some sort of common semantic substrate to root all of current languages on.

rs86 9y ago
Ownership in rust is determined from the type system using linear types.

pjmlp 9y ago

Because you can enjoy the productivity of working in a GC functional language, and only use affine types when critical to do so. Just like GC enabled systems programming languages do provide ways of manually managing resources in performance critical sections.

masklinn 9y ago

1. deterministic resource management (locks, files, …) 2. affine & linear types are actually useful modelling tools e.g. to make state machines statically non-rollbackable/duplicable (this is related to resource management as those are generally the STMs you want to lock down)

thesz 9y ago

You may employ non-trivial optimizations to a program which are not available in the Rust compiler and then output to, say, Rust. Or C. Also, you can easier combine different parts of a program, creating algebraic structures not available in Rust. Rust does not support higher-order functions nicely, OCaml does, for one example.