On Tuesday, 19 December 2017 at 12:21:19 UTC, I Love Stuffing wrote:
> I'm still not sure why this precludes GC from just being a standard library feature vs. a language feature. D is probably better prepared than other languages in doing that cleanly.

GC is the runtime library feature, it's accepted as a default because it's provided by the default runtime.

On Tuesday, 19 December 2017 at 13:14:50 UTC, Mark wrote:
> "In well-written modern C++, memory management errors are a solved problem. You can just write code, and know that the compiler and library will take care of cleaning up for you, just like with a GC-based system, but with the added benefit that it’s deterministic, and can handle non-memory resources such as file handles and sockets too."

They compare it to malloc+free MM.

On Wednesday, 20 December 2017 at 11:21:59 UTC, Thomas Mader wrote:
> What I don't get is why he doesn't believe in good GC for C (my previous post) but at the same time praising Go for it's GC.
> What makes it easier to have a good GC in Go vs. in C?
> I guess the GC in D has the same problems as a GC in C.

A good GC requires the compiler to add special bookkeeping code to every pointer mutation in the heap, and to generate special data for each function to help GC find all the pointers in its stack and closures. Without such help from the compiler you can't make anything decent, just a slow half-conservative GC that scans whole heap every time and leaks memory being unable to tell whether some stack value is a number or a pointer. Go compiler includes that special bookkeeping, so the running code is a bit slower but GC can be fast, its GC can analyze heap concurrently, it can clean it by parts. With C you can't do that. D compiler also doesn't insert that bookkeeping code, so running code is fast as C but GC is slow and sloppy.

On Tuesday, 19 December 2017 at 13:14:50 UTC, Mark wrote:
> On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:
>> "C, Python, Go, and the Generalized Greenspun Law"
>>
>> http://esr.ibiblio.org/?p=7804
>
> What do you think of the following comment to that article?
>
> "In well-written modern C++, memory management errors are a solved problem. You can just write code, and know that the compiler and library will take care of cleaning up for you, just like with a GC-based system, but with the added benefit that it’s deterministic, and can handle non-memory resources such as file handles and sockets too."

As a former C++ programmer, the comment is exactly right, in C++ resource management is a solved problem (or at least feels like it which doesn't say much), and in D it's way more _complex_ (many cases, many workarounds, and _you have to understand it_, for example you need a mental model of how the GC works).

There is also a downside to the C++ scoped owership wa: you have to find an owner for everything even if they are just memory. So small scripts in D will be written almost 2x faster because of that and rich stdlib.



THe other

On Tuesday, 19 December 2017 at 11:30:14 UTC, ketmar wrote:
> but Rikki, we have this! i'm using refcounted structs for years, and it works like a charm! ;-)

You can either have guaranteed memory-safe (due to DIP1000) but inefficient RC (due to extra runtime checks*), or efficient and not memory safe. That's why DIP74, DIP77 were created.

* https://forum.dlang.org/post/aeeffshzkfjbrejztksj@forum.dlang.org

On Thursday, 21 December 2017 at 13:27:55 UTC, Guillaume Piolat wrote:
> [...]
>
> There is also a downside to the C++ scoped owership wa: you have to find an owner for everything even if they are just memory. So small scripts in D will be written almost 2x faster because of that and rich stdlib.

Right. That's definitely a nuisance. It's probably also an issue in Rust with its "borrowing and ownership" apparatus.

On Thursday, 21 December 2017 at 11:08:23 UTC, thedeemon wrote:
> A good GC requires the compiler to add special bookkeeping code to every pointer mutation in the heap, and to generate special data for each function to help GC find all the pointers in its stack and closures. Without such help from the compiler you can't make anything decent, just a slow half-conservative GC that scans whole heap every time and leaks memory being unable to tell whether some stack value is a number or a pointer. Go compiler includes that special bookkeeping, so the running code is a bit slower but GC can be fast, its GC can analyze heap concurrently, it can clean it by parts. With C you can't do that. D compiler also doesn't insert that bookkeeping code, so running code is fast as C but GC is slow and sloppy.

But for D it's planned to rewrite the GC to become something like the Go GC right?
The last attempt to do this was afaik a Google Summer of code project.

On Thursday, 21 December 2017 at 11:08:23 UTC, thedeemon wrote:
> A good GC requires the compiler to add special bookkeeping code to every pointer mutation in the heap, and to generate special data for each function to help GC find all the pointers in its stack and closures.

Precise stack scanning requires compiler support, yes.

You can use mprotect(2) for write barriers, and that doesn't require compiler support. It's relatively inefficient, though.

> Without such help from the compiler you can't make anything decent, just a slow half-conservative GC that scans whole heap every time and leaks memory being unable to tell whether some stack value is a number or a pointer.

Numbers tend very much to be small, and pointer values tend not to be small, especially on 64-bit. So it shouldn't be that common to confuse the two. It should be more common to confuse floating point values for pointers, but the odds go down as address space increases.

Actually, there's an idea. Instrument real-world code to determine what address ranges are least likely to be hit by a false pointer, then try to arrange the GC to concentrate allocations in those ranges.

> Go compiler includes that special bookkeeping, so the running code is a bit slower but GC can be fast, its GC can analyze heap concurrently, it can clean it by parts. With C you can't do that. D compiler also doesn't insert that bookkeeping code, so running code is fast as C but GC is slow and sloppy.

D also offers better support for not allocating than Go. const/immutable to reduce defensive copies. std.experimental.allocator. GC.addRange for when you mix the GC with manually allocated memory.

Go's only objective with its collector is to reduce the maximum pause time, and it's not bad at that. The JVM is going for low overhead with its default parameters, and you can muck about with it to prioritize low pause times; it's better than Go at both. D is currently going for predictability.

On Wednesday, 20 December 2017 at 18:28:20 UTC, Ali Çehreli wrote:
> I think it's a psychological phenomenon worthy of scientific interest how a craft with so many guidelines can still be accepted.

Actually, the 'core guidelines' is itself a psychological phenomenon of interest, given that most people will mostly never read it.

On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:
> "C, Python, Go, and the Generalized Greenspun Law"
>
> http://esr.ibiblio.org/?p=7804

The question that remains, is how scalable and tunable is "D's GC implementation" to my programming needs (whatever they might happen to be).

It seems to me, that most GC implementations assume particular things about the environment in which they're operating, whereas I think that the programmer should be able to tell the GC about the environment in which it's operating, and the GC can adjust its parameter to that environment (e.g real time collection, generational collection, regional collection, etc...).

To the extent that a particular type of GC implementation forces its particular model onto the programmer, that I think, is a real limitation of GC.

That's why I believe manual memory management, much like the language C, will be around for a long time to come.