On Thursday, 21 December 2017 at 22:11:26 UTC, Thomas Mader wrote:
>> 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.

No, not like in Go. A few years ago there was a project implementing concurrent GC by forking the process and scanning the heap snapshot in parallel to the main process. It kinda worked but it's not portable, it won't work on Windows, so don't expect it to land into main D distribution and become an official GC.
There were other projects to improve current GC, make it more precise (but still not 100% precise) and optimize to some extent, but they don't bring substantial speed improvements, since the main scheme remains the same: no write barriers, scan whole heap every time and hope false pointers won't cause too much leaks.

Making the GC more like in Go and JVM means adding write barriers, it means making general code slower (we're not fast-as-C anymore), it means losing easy C compatibility (hello FFI!), it means forbidding many current language features like unions and casts, it means changing the language to something that's not D anymore.

So I think we can expect some minor improvements in GC, but nothing radical.

On Thursday, 21 December 2017 at 22:45:23 UTC, Neia Neutuladh wrote:
> You can use mprotect(2) for write barriers, and that doesn't require compiler support. It's relatively inefficient, though.

As I understand it's prohibitively inefficient, that's why this approach is not used by any real world GC.

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

Floating point values are also numbers, real numbers. ;)
Indeed in 64 bits our current GC is not too leaky. But still people encounter leaks occasionally, when trying to make long running services.

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

I'm not sure all major OSs will let you choose freely address ranges when allocating memory.

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

Sure, carefully written D code has all the means to outperform Go.

On Tuesday, 19 December 2017 at 12:21:19 UTC, I Love Stuffing 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
>
> 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.

Probably this one could be the answer

On Friday, 22 December 2017 at 12:13:39 UTC, Emma Watson wrote:
> On Tuesday, 19 December 2017 at 12:21:19 UTC, I Love Stuffing 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
>>
>> 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.
>
> Probably this one could be the answer

I believe so, yes. GC should be a library feature, std library of the language should be independent of existence of a garbage collector, and the language itself should not contain features which are dependent of the existence of a garbage collector. (strings, maps, unbounded arrays all should have been part of standard lib IMO and not part of the core language and dependent of GC.

I wanted to look at D as a "beter C++", with simple and sane metaprograming and metaligusitic features.  It is almost there, but unfortunately, not 0 cost abstraction without loosing too much. You depend too much of having garbage collection active. It works as a "betterC" it seems, but you loose a lot of functionality which should be in a "better C" and again, a lot from the standard libraries is lost. Template C++ 2017 works well for a better C as well, and I retain 0 cost abstraction, decent (yet inferior to D meta-programming), closures,
exceptions, scopes...

Perhaps Im wrong, I only play with D by several days.

On Fri, 2017-12-22 at 13:38 +0000, Dan Partelly via Digitalmars-d wrote:
> […]
> 
> I wanted to look at D as a "beter C++", with simple and sane
> metaprograming and metaligusitic features.  It is almost there,
> but unfortunately, not 0 cost abstraction without loosing too
> much. You depend too much of having garbage collection active. It
> works as a "betterC" it seems, but you loose a lot of
> functionality which should be in a "better C" and again, a lot
> from the standard libraries is lost. Template C++ 2017 works well
> for a better C as well, and I retain 0 cost abstraction, decent
> (yet inferior to D meta-programming), closures,
> exceptions, scopes...
[…]

I think we are now in a world where Rust is the zero cost abstraction language to replace C and C++, except for those who are determined to stay with C++ and evolve it.

D, like Go, should glory in having a GC and just go with it.

Of course this does not mean the GC as is is good enough. Go is on its
third I believe, and Java on it's fifth.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Friday, 22 December 2017 at 13:38:25 UTC, Dan Partelly wrote:
> It works as a "betterC" it seems, but you loose a lot of functionality which should be in a "better C" and again, a lot from the standard libraries is lost. Template C++ 2017 works well for a better C as well, and I retain 0 cost abstraction, decent (yet inferior to D meta-programming), closures,
> exceptions, scopes...

It seems that there's an effort from the top to bring more higher level features into --betterC. I agree with you that more should be there, that it should really be betterC++ and strive for feature parity with modern C++.

bpr wrote:

> It seems that there's an effort from the top to bring more higher level features into --betterC. I agree with you that more should be there, that it should really be betterC++ and strive for feature parity with modern C++.

we already have better c++: it is titled "D".

On Friday, 22 December 2017 at 04:56:57 UTC, thedeemon wrote:
> Making the GC more like in Go and JVM means adding write barriers, it means making general code slower (we're not fast-as-C anymore), it means losing easy C compatibility (hello FFI!), it means forbidding many current language features like unions and casts, it means changing the language to something that's not D anymore.
>
> So I think we can expect some minor improvements in GC, but nothing radical.

What about a special GC mode for SafeD only processes which could probably be made precise and maybe even concurrent?
If a process is entirely in SafeD the GC would run in the "safed" mode otherwise the conservative GC is being run.

Go seems to make the following assumption which should be doable for D too: "Starting with Go 1.3, the runtime assumes that values with pointer type contain pointers and other values do not." [1]

[1] https://golang.org/doc/go1.3#garbage_collector

On Friday, 22 December 2017 at 15:23:51 UTC, Russel Winder wrote:
> I think we are now in a world where Rust is the zero cost abstraction language to replace C and C++, except for those who are determined to stay with C++ and evolve it.

Why should we settle for this ? D code (efortless) is easier to read then Rust. I assume this to be true for a lot of programmers who know C/C++. It also introperates very well with C, which is great boon, since at low level we live on the shoulder of a titan written in C.  It has tremnedous features, and ironically the best of them could have been designed to not relay on GC. As most , if not all, of the features offered by its library could have been done with no GC.

>
> D, like Go, should glory in having a GC and just go with it.
>
> Of course this does not mean the GC as is is good enough. Go is on its
> third I believe, and Java on it's fifth.

A good implementation at library level of GC would mean that I can use one single language
in all areas of system programming. Or at least, a implementation where std:: and core features of language should not relay on GC. This, IMO is an advantage not to be neglected. A better C mode with a very powerfull high level standard library (like std:: ), exceptions, RAII, classes (yes, why not ) typeid would be a very big step ahead. All those could be done without having to worry about existence of GC. C++ has all those.

IMO the key here is the standard libray of the language. Nothing in it should relay  on the existence of GC. Why, why, does it have to depend on GC and hence automatically disqualify itself from a better C world ? The C runtime ezposed by core is powerfull, but imagine having std:: power in better C as well. I really lament this.

You could have the best of the two worlds.

On Friday, 22 December 2017 at 04:56:57 UTC, thedeemon wrote:
> Making the GC more like in Go and JVM means adding write barriers, it means making general code slower (we're not fast-as-C anymore), it means losing easy C compatibility (hello FFI!)

What exactly will be lost? And do we even have easy C compatibility to begin with or you just don't about problems with it?

> it means forbidding many current language features like unions and casts

They would cause no more problems than for precise GC, not specific to barriers.