4 ms·

> I’m not criticizing pause times, but rather that you can’t rely on code inspection to identify the point of resource deallocation, which is pretty much the fl

> I’m not criticizing pause times, but rather that you can’t rely on code inspection to identify the point of resource deallocation, which is pretty much the flagship feature of a GC :) This is completely wrong. The flagship feature of a GC is memory management, __not__ filehandle management or management of other resources. While many GCs support finalizer hooks, most languages with GCs (Go, Python, etc) explicitly discourage using these to close file handles for specifically the reasons you cite. Automatic resource management is useful and desirable, but it's out of scope for GCs.

arcticbull 8y ago
In re-reading my statement, I understand the confusion, when I said 'not being able to rely on code inspection is the flagship feature of a GC' I meant, glibly, that non-deterministic deallocation of memory in a way the programmer does not have to (alternatively, cannot) reason about meaningfully. I suppose in reality it depends. Finalizer hooks are absolutely bad, I agree. Which means that resource management has to be grafted on top of a GC memory model. Since the compiler won't be helping you enforce the management of resources since, as you point out, it's out of scope, it introduces a new vector for error. Rust allows you to bind the two and handle them together, both in a checked/enforced way. I've yet to see a GC'd language that does the same, but I can't think of why one couldn't exist.
- weberc2 8y ago
  > Since the compiler won't be helping you enforce the management of resources since, as you point out, it's out of scope, it introduces a new vector for error It's not a new vector of error; it's the same vector that C has to deal with. > resource management has to be grafted on top of a GC memory model Only if this means "don't bind resource lifetimes to memory lifetimes", which is the solution that every tracing GC language implementation (that I'm aware of) uses. There's nothing stopping you from refcounting file handles just like you would in C. The compiler could even automatically add in the refcounting instructions for you, or the language runtime could have a special GC just for file handles.
  - arcticbull 8y ago
    Sure but we're comparing it with Rust not C.

arcticbull 8y ago

In re-reading my statement, I understand the confusion, when I said 'not being able to rely on code inspection is the flagship feature of a GC' I meant, glibly, that non-deterministic deallocation of memory in a way the programmer does not have to (alternatively, cannot) reason about meaningfully. I suppose in reality it depends. Finalizer hooks are absolutely bad, I agree. Which means that resource management has to be grafted on top of a GC memory model. Since the compiler won't be helping you enforce the management of resources since, as you point out, it's out of scope, it introduces a new vector for error. Rust allows you to bind the two and handle them together, both in a checked/enforced way. I've yet to see a GC'd language that does the same, but I can't think of why one couldn't exist.

weberc2 8y ago
> Since the compiler won't be helping you enforce the management of resources since, as you point out, it's out of scope, it introduces a new vector for error It's not a new vector of error; it's the same vector that C has to deal with. > resource management has to be grafted on top of a GC memory model Only if this means "don't bind resource lifetimes to memory lifetimes", which is the solution that every tracing GC language implementation (that I'm aware of) uses. There's nothing stopping you from refcounting file handles just like you would in C. The compiler could even automatically add in the refcounting instructions for you, or the language runtime could have a special GC just for file handles.
- arcticbull 8y ago
  Sure but we're comparing it with Rust not C.