[ingenter]

> 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

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]

>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

>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]

> 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 is an implementation for "GC only when you need it".

[gpderetta]

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.

[DougBTX]

Microsoft's Managed C++ is frankly scary, but its gc root type seems pretty close to this.

[DannyBee]

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]

Which one (or more) of those three properties does the D language fail to satisfy?