3 ms·

Weirdly enough, some of the worst memory leaks I’ve debugged in my career were in GCed languages. Because any object can reference anything, retaining reference

Weirdly enough, some of the worst memory leaks I’ve debugged in my career were in GCed languages. Because any object can reference anything, retaining references can hide anywhere in the code. (Including via closures and other exotic things you forget about). And because in GC languages we don’t often have a destructor (or anything like it), it’s very common for people to forget to clean up resources. (Eg filesystem handles, sockets, wasm object references, and so on). One weird thing about rust is that network sockets and file handles are automatically closed when the handle drops out of scope. The borrow checker takes care of that. If you do the same thing in JavaScript (open a socket then do nothing), the program won’t even quit on its own and you’ll have no idea why.

xigoi 3y ago
> And because in GC languages we don’t often have a destructor (or anything like it), it’s very common for people to forget to clean up resources. (Eg filesystem handles, sockets, wasm object references, and so on). > One weird thing about rust is that network sockets and file handles are automatically closed when the handle drops out of scope. The borrow checker takes care of that. If you do the same thing in JavaScript (open a socket then do nothing), the program won’t even quit on its own and you’ll have no idea why. That’s not an inherent problem of GC. You can have linear types or destructors in a GC language.
- thfuran 3y ago
  The first sentence you quoted acknowledged that it's a tendency rather than a fact of GC.
ClimaxGravely 3y ago
If I understand correctly, what you are describing would often be done with a using scope block in C#. EX using (SomeKindOfHandle handle) { // handle releases when the scope ends }
tracker1 3y ago
In IE6 it was really easy to lay memory with long lived apps. Any HTML object could have a JS event attached and give versa for object references in JS. Done it was across the COM boundary, if you removed an element from the DOM it would stick around if referenced in JS and give versa for inline JS on* attributes... I worked on an application with extjs that the workers had to close and reopen at least once a day. Or unofficial instructions were portable Firefox.
Thiez 3y ago
You are spreading a common misconception. The borrow checker takes care of exactly nothing when it comes to cleaning up resources. The borrow checker is "just" type checking, like a built-in static analysis. But it doesn't affect code generation at all! There is an alternative implementation of the Rust compiler (`mrustc`) which doesn't implement the borrow checker at all! But if your code passes the `rustc` borrow checker, then `mrustc` should compile it correctly (* if you don't use too many new features, afaik it is a bit behind the official compiler). I think the borrow checker has an unfair reputation of being complicated and magical. Its rules aren't always obvious to a beginner, but at the end of the day it's just type checking / static analysis. People often imagine it also does things at runtime, or affects code semantics in some way. It does not. And it's only scary because because it's so stern :)

xigoi 3y ago

> And because in GC languages we don’t often have a destructor (or anything like it), it’s very common for people to forget to clean up resources. (Eg filesystem handles, sockets, wasm object references, and so on). > One weird thing about rust is that network sockets and file handles are automatically closed when the handle drops out of scope. The borrow checker takes care of that. If you do the same thing in JavaScript (open a socket then do nothing), the program won’t even quit on its own and you’ll have no idea why. That’s not an inherent problem of GC. You can have linear types or destructors in a GC language.

thfuran 3y ago
The first sentence you quoted acknowledged that it's a tendency rather than a fact of GC.

ClimaxGravely 3y ago

If I understand correctly, what you are describing would often be done with a using scope block in C#. EX using (SomeKindOfHandle handle) { // handle releases when the scope ends }

tracker1 3y ago

In IE6 it was really easy to lay memory with long lived apps. Any HTML object could have a JS event attached and give versa for object references in JS. Done it was across the COM boundary, if you removed an element from the DOM it would stick around if referenced in JS and give versa for inline JS on* attributes... I worked on an application with extjs that the workers had to close and reopen at least once a day. Or unofficial instructions were portable Firefox.

Thiez 3y ago

You are spreading a common misconception. The borrow checker takes care of exactly nothing when it comes to cleaning up resources. The borrow checker is "just" type checking, like a built-in static analysis. But it doesn't affect code generation at all! There is an alternative implementation of the Rust compiler (`mrustc`) which doesn't implement the borrow checker at all! But if your code passes the `rustc` borrow checker, then `mrustc` should compile it correctly (* if you don't use too many new features, afaik it is a bit behind the official compiler). I think the borrow checker has an unfair reputation of being complicated and magical. Its rules aren't always obvious to a beginner, but at the end of the day it's just type checking / static analysis. People often imagine it also does things at runtime, or affects code semantics in some way. It does not. And it's only scary because because it's so stern :)