5 ms·

> Your prelude and the followup question is not well-formed. Thank you for your feedback, I appreciate it. > C++ programmers do not have a bias against GC as

> Your prelude and the followup question is not well-formed. Thank you for your feedback, I appreciate it. > C++ programmers do not have a bias against GC as a specific problem-solving technique. Expert C++ programmers can embrace GC Please watch this portion of the video, and the way the speaker is pronouncing the word "collect": https://www.youtube.com/watch?v=JfmTagWcqoE#t=1h5m25s https://www.youtube.com/watch?v=JfmTagWcqoE#t=1h5m25s Regarding general-purpose GC: I don't support using GC for everything. If there is a problem that can only be solved with GC, it doesn't mean that we should express our entire running programs in terms of dynamic cyclic graphs. I believe we can do much better, with much fewer resources.

jasode 10y ago
>Please watch this portion of the video, and the way the speaker is pronouncing the word "collect": Herb was deliberately using circumlocution to avoid the phrase "garbage collection" so as to not poison the well. The latter part of the video explains his reasoning for presenting it that way: https://www.youtube.com/watch?v=JfmTagWcqoE&t=1h32m55s https://www.youtube.com/watch?v=JfmTagWcqoE&t=1h32m55s >I don't support using GC for everything. [...] I believe we can do much better, with much fewer resources. This is a statement that sounds reasonable and balanced . How can anyone possibly disagree with it?!? The issue is that it's very difficult to take that universal wisdom and construct a real programming language that satisfies all the following properties seamlessly and elegantly: 1) language that has optional GC 2) has zero cost when not using it. This means no active tracing loop that checks object graphs and no large memory blocks reserved to allow reallocation and defragmention. 3) transparent syntax that's equally elegant for manual memory or GC in the same language To make your GC-when-appropriate advice real, one has to show a real implementation. E.g. one can fork the GCC or LLVM compilers and add GC to it. Or fork the Java OpenJDK compiler and show how syntax can remove the GC on demand. Or construct a new language from scratch. There may be some lessons learned from the D Language backing away from GC. Also, Apple Objective-C retreated from GC as well.
- ingenter 10y ago
  > To make your GC-when-appropriate advice real, one has to show a real implmentation. I haven't tested it closely, but I believe that Rust with this crate: https://github.com/Manishearth/rust-gc https://github.com/Manishearth/rust-gc is an implementation for "GC only when you need it".
- DougBTX 10y ago
  Microsoft's Managed C++ is frankly scary, but its gc root type seems pretty close to this.
  - DannyBee 10y ago
    Right, but they pay a different cost there that isn't listed: "It's not entirely compatible with the existing language" private and multiple inheritance do not work, for example (yes, i know some of this is fixable, but some is not) public __gc class one { int i; }; public __gc class two: private one { int h; i = h; }; //error __gc class a {}; __gc class b {}; __gc class c: public a, public b {}; //will produce an error etc
- piaste 10y ago
  Which one (or more) of those three properties does the D language fail to satisfy?
- gpderetta 10y ago
  Rust would be a perfect GC-optional language as, having per-thread heaps, GC using threads can be completely segregated from the non-using ones.

jasode 10y ago

>Please watch this portion of the video, and the way the speaker is pronouncing the word "collect": Herb was deliberately using circumlocution to avoid the phrase "garbage collection" so as to not poison the well. The latter part of the video explains his reasoning for presenting it that way: https://www.youtube.com/watch?v=JfmTagWcqoE&t=1h32m55s https://www.youtube.com/watch?v=JfmTagWcqoE&t=1h32m55s >I don't support using GC for everything. [...] I believe we can do much better, with much fewer resources. This is a statement that sounds reasonable and balanced . How can anyone possibly disagree with it?!? The issue is that it's very difficult to take that universal wisdom and construct a real programming language that satisfies all the following properties seamlessly and elegantly: 1) language that has optional GC 2) has zero cost when not using it. This means no active tracing loop that checks object graphs and no large memory blocks reserved to allow reallocation and defragmention. 3) transparent syntax that's equally elegant for manual memory or GC in the same language To make your GC-when-appropriate advice real, one has to show a real implementation. E.g. one can fork the GCC or LLVM compilers and add GC to it. Or fork the Java OpenJDK compiler and show how syntax can remove the GC on demand. Or construct a new language from scratch. There may be some lessons learned from the D Language backing away from GC. Also, Apple Objective-C retreated from GC as well.

ingenter 10y ago
> To make your GC-when-appropriate advice real, one has to show a real implmentation. I haven't tested it closely, but I believe that Rust with this crate: https://github.com/Manishearth/rust-gc https://github.com/Manishearth/rust-gc is an implementation for "GC only when you need it".
DougBTX 10y ago
Microsoft's Managed C++ is frankly scary, but its gc root type seems pretty close to this.
- DannyBee 10y ago
  Right, but they pay a different cost there that isn't listed: "It's not entirely compatible with the existing language" private and multiple inheritance do not work, for example (yes, i know some of this is fixable, but some is not) public __gc class one { int i; }; public __gc class two: private one { int h; i = h; }; //error __gc class a {}; __gc class b {}; __gc class c: public a, public b {}; //will produce an error etc
piaste 10y ago
Which one (or more) of those three properties does the D language fail to satisfy?
gpderetta 10y ago
Rust would be a perfect GC-optional language as, having per-thread heaps, GC using threads can be completely segregated from the non-using ones.