3 ms·

What's wrong with garbage collectors? Depending on the type, you can get performance characteristics better than or similar to destructor-based management. Eve

What's wrong with garbage collectors? Depending on the type, you can get performance characteristics better than or similar to destructor-based management. Even current operating systems use forms of garbage collection (such as refcounting) to track resources.

jhasse 9y ago
Most things get moved to the heap.
- pjmlp 9y ago
  Only in GC languages that don't offer good language features for value types, which usually isn't the case with the ones targeted for low level systems development.
  - Rusky 9y ago
    "Good language features for value types," while retaining memory safety, means at least one of these things: * Boxing anything you take a reference directly to * Forbidding sum types and complicating the GC to allow interior pointers * Forbidding references to value types * A borrow checker Guess which one is most flexible, and novel in Rust.
    - pjmlp 9y ago
      A language like Modula-3 doesn't suffer from those issues. We only don't have it thanks to Compaq killing the project after acquiring DEC Olivetti. Politics as usual. Rust ideas come from Cyclone and ATS, it is not novel in Rust. The borrow checker still is pretty much WIP, that the NLL changes will surely improve, but don't not yet solve all ergonomic problems.
      - Rusky 9y ago
        Modula-3 either uses one of those techniques, or is not memory safe. (Looks like primarily the first one- manual deallocation is unsafe and it relies on GC for the rest?) Cyclone and ATS do not have Rust's combination of ownership and borrowing.
cyphar 9y ago
The problems with a GC (in the context of embedding it in a larger codebase written in a another language) is that the calling conventions are more complicated and the existence of a GC (especially mark-and-sweep GCs) means that the embedding is not "seamless". Even with a C FFI interface it's still harder than (for example) using Rust or C in such a project. And if both languages have GC, then you're in even more trouble.
- johncolanduoni 9y ago
  For what language runtime are the calling conventions an issue? Even the most calling-convention dependent GC I can think of (GHC Haskell's) can handle standard C ABIs and .NET is a good example of making this whole process relatively seamless. If you can export a C FFI with pinned pointers in both directions, I don't see how it's any harder than Rust or C. The multiple GCs in a process issue is usually due to the collector not playing nice with signal/exception handler installation when using safepoints, which is purely an issue of lazy implementations. There's even ways to collect cross-heap cycles when working this multiple GCs (Xamarin on Android does this fairly well).

jhasse 9y ago

Most things get moved to the heap.

pjmlp 9y ago
Only in GC languages that don't offer good language features for value types, which usually isn't the case with the ones targeted for low level systems development.
- Rusky 9y ago
  "Good language features for value types," while retaining memory safety, means at least one of these things: * Boxing anything you take a reference directly to * Forbidding sum types and complicating the GC to allow interior pointers * Forbidding references to value types * A borrow checker Guess which one is most flexible, and novel in Rust.
  - pjmlp 9y ago
    A language like Modula-3 doesn't suffer from those issues. We only don't have it thanks to Compaq killing the project after acquiring DEC Olivetti. Politics as usual. Rust ideas come from Cyclone and ATS, it is not novel in Rust. The borrow checker still is pretty much WIP, that the NLL changes will surely improve, but don't not yet solve all ergonomic problems.
    - Rusky 9y ago
      Modula-3 either uses one of those techniques, or is not memory safe. (Looks like primarily the first one- manual deallocation is unsafe and it relies on GC for the rest?) Cyclone and ATS do not have Rust's combination of ownership and borrowing.

cyphar 9y ago

The problems with a GC (in the context of embedding it in a larger codebase written in a another language) is that the calling conventions are more complicated and the existence of a GC (especially mark-and-sweep GCs) means that the embedding is not "seamless". Even with a C FFI interface it's still harder than (for example) using Rust or C in such a project. And if both languages have GC, then you're in even more trouble.

johncolanduoni 9y ago
For what language runtime are the calling conventions an issue? Even the most calling-convention dependent GC I can think of (GHC Haskell's) can handle standard C ABIs and .NET is a good example of making this whole process relatively seamless. If you can export a C FFI with pinned pointers in both directions, I don't see how it's any harder than Rust or C. The multiple GCs in a process issue is usually due to the collector not playing nice with signal/exception handler installation when using safepoints, which is purely an issue of lazy implementations. There's even ways to collect cross-heap cycles when working this multiple GCs (Xamarin on Android does this fairly well).