6 ms·

I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language. I like garbage collection—it's not always the right tool, but

I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language. I like garbage collection—it's not always the right tool, but it's a great tool in the proper domains. Modern GC builds upon decades of research to achieve memory safety at runtime with good performance and very low cognitive overhead on the part of the programmer. What I don't agree with is the idea of taking Rust's ideas and putting them into manually-memory-managed, unsafe languages. We should be moving away from such languages as an industry.

cultofmetatron 5y ago
> I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language. sooo... ocaml?
- johnisgood 5y ago
  Or many other programming languages, but yes, OCaml is a pretty good one, and it is perfectly suitable for systems programming.
skohan 5y ago
> I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language You're describing Swift
- saghm 5y ago
  Swift also has some stuff coming from the history of Objective-C interop (inheritance is the big one I'm thinking of, although I'm sure there are others that are slipping my mind). I'm not sure how mainstream this opinion is, but personally I _prefer_ not having classes and inheritance, and while I could always choose not to use them in my own code, I imagine it's common enough in libraries that I'd end up dealing with it a bit anyways. Combined with the fact that Linux support still seems like it's a bit secondary makes me feel like there still is a potential niche out there for "Rust with garbage collecting" that Swift might not be filling entirely.
  - mirekrusin 5y ago
    What are you both talking about? Swift doesn't have garbage collector the same way Rust doesn't have it.
    - skohan 5y ago
      Swift doesn't have tracing GC, but to be pedantic automatic reference counting is a form of GC. But that only goes for reference types. For value types you're correct that both languages use mostly static memory management. I guess in that sense you'd have to consider Rust as a gc'd language as well: the only difference really is that you have more fine-grained control over which mode of reference counting is being used for a given object.
      - pjmlp 5y ago
        Chapter 5 of the GC Handbook, one of the major CS references in GC algorithms.
        mirekrusin 5y ago
        GC is standalone runtime that does tracing and deallocates memory at some arbitrary time. Are you really claiming that using C++'s smart pointers is using GC? I think you're conflating semi/automatic memory management with GC.
        pjmlp 5y ago
        You're conflating tracing GC algorithm with GC as CS concept. Regarding C++ smart pointers, if you manually call them like in std::shared_ptr<>(), no. If the runtime calls it for you like on C++/CX or compiler blessed types like _com_ptr_t, then surely.
        mirekrusin 5y ago
        ARC in Swift doesn't have runtime part, retain/release code is injected at the compile time. It doesn't have ie. cycle detector running periodically or anything like that. If you define this setup as GC then by this definition Rust's borrow-checker is also a GC because it works the same way - by injecting static code during compilation (but has different rules).
- bouke 5y ago
  Swift does not employ garbage collection, but reference counting.
  - skohan 5y ago
    Swift doesn't have tracing gc but ref counting is a form of gc
  - pjmlp 5y ago
    Chapter 5 of the GC Handbook, one of the major CS references in GC algorithms. Reference counting is a GC algorithm, regardless how people sell it to the man on the street. Additionally there is a whole set of politics how ARC had to be sold after the technical failure to make Objective-C GC implementation work without core dumps, due to the underlying C semantics. Plus making retain/release calls automatic wasn't anything new as idea, VB and Delphi did it first with COM AddRef/Release.
- pjmlp 5y ago
  Also Haskell, D, Chapel, among others.
pjmlp 5y ago
I can attest that so far the lifetime static analysers for C++ haven't progressed that much. However until certain C++ overloads don't give more love to memory-safe, garbage collected language or languages like Rust, that is better than nothing. For example, I don't expect Windows team to ever lose their love for C++, NVidia moving from their C++ love for CUDA, or Metal shaders in something else. Ah, and then many of those languages are keeping C++ around by building on top of GCC or LLVM. So any improvement towards to make C and C++ safer is better than just using them as they are.

cultofmetatron 5y ago

> I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language. sooo... ocaml?

johnisgood 5y ago
Or many other programming languages, but yes, OCaml is a pretty good one, and it is perfectly suitable for systems programming.

skohan 5y ago

> I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language You're describing Swift

saghm 5y ago
Swift also has some stuff coming from the history of Objective-C interop (inheritance is the big one I'm thinking of, although I'm sure there are others that are slipping my mind). I'm not sure how mainstream this opinion is, but personally I _prefer_ not having classes and inheritance, and while I could always choose not to use them in my own code, I imagine it's common enough in libraries that I'd end up dealing with it a bit anyways. Combined with the fact that Linux support still seems like it's a bit secondary makes me feel like there still is a potential niche out there for "Rust with garbage collecting" that Swift might not be filling entirely.
- mirekrusin 5y ago
  What are you both talking about? Swift doesn't have garbage collector the same way Rust doesn't have it.
  - skohan 5y ago
    Swift doesn't have tracing GC, but to be pedantic automatic reference counting is a form of GC. But that only goes for reference types. For value types you're correct that both languages use mostly static memory management. I guess in that sense you'd have to consider Rust as a gc'd language as well: the only difference really is that you have more fine-grained control over which mode of reference counting is being used for a given object.
    - pjmlp 5y ago
      Chapter 5 of the GC Handbook, one of the major CS references in GC algorithms.
      - mirekrusin 5y ago
        GC is standalone runtime that does tracing and deallocates memory at some arbitrary time. Are you really claiming that using C++'s smart pointers is using GC? I think you're conflating semi/automatic memory management with GC.
        pjmlp 5y ago
        You're conflating tracing GC algorithm with GC as CS concept. Regarding C++ smart pointers, if you manually call them like in std::shared_ptr<>(), no. If the runtime calls it for you like on C++/CX or compiler blessed types like _com_ptr_t, then surely.
        mirekrusin 5y ago
        ARC in Swift doesn't have runtime part, retain/release code is injected at the compile time. It doesn't have ie. cycle detector running periodically or anything like that. If you define this setup as GC then by this definition Rust's borrow-checker is also a GC because it works the same way - by injecting static code during compilation (but has different rules).
bouke 5y ago
Swift does not employ garbage collection, but reference counting.
- skohan 5y ago
  Swift doesn't have tracing gc but ref counting is a form of gc
- pjmlp 5y ago
  Chapter 5 of the GC Handbook, one of the major CS references in GC algorithms. Reference counting is a GC algorithm, regardless how people sell it to the man on the street. Additionally there is a whole set of politics how ARC had to be sold after the technical failure to make Objective-C GC implementation work without core dumps, due to the underlying C semantics. Plus making retain/release calls automatic wasn't anything new as idea, VB and Delphi did it first with COM AddRef/Release.
pjmlp 5y ago
Also Haskell, D, Chapel, among others.

pjmlp 5y ago

I can attest that so far the lifetime static analysers for C++ haven't progressed that much. However until certain C++ overloads don't give more love to memory-safe, garbage collected language or languages like Rust, that is better than nothing. For example, I don't expect Windows team to ever lose their love for C++, NVidia moving from their C++ love for CUDA, or Metal shaders in something else. Ah, and then many of those languages are keeping C++ around by building on top of GCC or LLVM. So any improvement towards to make C and C++ safer is better than just using them as they are.