On Saturday, 22 July 2017 at 14:39:17 UTC, Moritz Maxeiner wrote:
> On Saturday, 22 July 2017 at 13:27:03 UTC, aedt wrote:
>> Unless some miracle happens and makes the GC better by preventing stop-the-world
>
> I have yet to see a (working, correct) non-STW GC that doesn't make other trade offs not acceptable for D (extra thread(s), memory barriers for all writes, etc.).
> There's room for improvement of the current GC, but I sincerely doubt we will see one that's not STW.
>
>> or gets rid of the GC
>
> And remove one of the primary reasons why one doesn't have to prototype in some script language (e.g. python)? No thanks.

Ocaml comes to mind, it is being used bu jane street for high frequency trading
and they dont complain

I think the key point it, is that if stw fast enough, it is good enough for most uses

I think a very fast GC should be next on the list for D

On Saturday, 22 July 2017 at 15:13:12 UTC, Ali wrote:
> On Saturday, 22 July 2017 at 14:39:17 UTC, Moritz Maxeiner wrote:
>> On Saturday, 22 July 2017 at 13:27:03 UTC, aedt wrote:
>>> Unless some miracle happens and makes the GC better by preventing stop-the-world
>>
>> I have yet to see a (working, correct) non-STW GC that doesn't make other trade offs not acceptable for D (extra thread(s), memory barriers for all writes, etc.).
>> There's room for improvement of the current GC, but I sincerely doubt we will see one that's not STW.
>>
>>> or gets rid of the GC
>>
>> And remove one of the primary reasons why one doesn't have to prototype in some script language (e.g. python)? No thanks.
>
> Ocaml comes to mind, it is being used bu jane street for high frequency trading
> and they dont complain
>
> I think the key point it, is that if stw fast enough, it is good enough for most uses
>
> I think a very fast GC should be next on the list for D

Ocaml's GC is stop-the-world for both its minor and major heap [1], so if someone wants to write another GC implementation for D, that's a good place to draw inspiration from, yes.

[1] https://realworldocaml.org/v1/en/html/understanding-the-garbage-collector.html

On 22.07.2017 16:20, Russel Winder via Digitalmars-d wrote:
> D without the GC isn't at all interesting, might as well use Go in that
> case.

Uh, no.

On Saturday, 22 July 2017 at 14:20:24 UTC, Russel Winder wrote:
> On Sat, 2017-07-22 at 13:27 +0000, aedt via Digitalmars-d wrote:
>> 
> […]
> D without the GC isn't at all interesting, might as well use Go in that case. So D only gets traction if it keeps a GC.

Go people are also trying to make their GC pretty fast afaik
https://news.ycombinator.com/item?id=12821586

On Thursday, 20 July 2017 at 16:15:43 UTC, porter wrote:
> On Thursday, 20 July 2017 at 15:40:04 UTC, Wulfklaue wrote:
>
>

the problems are greater than thought

http://forum.dlang.org/thread/bqlfknpsdetzoxuxrtte@forum.dlang.org

On Sat, 2017-07-22 at 17:06 +0000, aedt via Digitalmars-d wrote:
> On Saturday, 22 July 2017 at 14:20:24 UTC, Russel Winder wrote:
> > On Sat, 2017-07-22 at 13:27 +0000, aedt via Digitalmars-d wrote:
> > > 
> > 
> > […]
> > D without the GC isn't at all interesting, might as well use Go
> > in that case. So D only gets traction if it keeps a GC.
> 
> Go people are also trying to make their GC pretty fast afaik https://news.ycombinator.com/item?id=12821586

I believe they are their third or fourth already. Java and Go development teams put a significant amount of effort into GC.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sunday, 23 July 2017 at 08:27:08 UTC, Russel Winder wrote:
> On Sat, 2017-07-22 at 17:06 +0000, aedt via Digitalmars-d wrote:
>> Go people are also trying to make their GC pretty fast afaik https://news.ycombinator.com/item?id=12821586
>
> I believe they are their third or fourth already. Java and Go development teams put a significant amount of effort into GC.

Those languages were of course designed within the restrictions of a GC to begin with too, but there seems to be a Go 2 language in the works now:

https://blog.golang.org/toward-go2?utm_source=golangweekly&utm_medium=email

On Mon, 2017-07-24 at 10:07 +0000, Ola Fosheim Grøstad via Digitalmars- d wrote:
> […]
> 
> Those languages were of course designed within the restrictions of a GC to begin with too, but there seems to be a Go 2 language in the works now:

I had assumed D was designed to be a GC language from the outset.

> https://blog.golang.org/toward- go2?utm_source=golangweekly&utm_medium=email
> 

It seems that the Go team are using backward compatibility as a rod for their own backs just as Java/JDK folk did. There is a big difference between taking the community with you, cf. Python 2 → 3 for an anti- pattern, versus not allowing breaking changes, cf. the mess Java is in.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 24 July 2017 at 11:28:51 UTC, Russel Winder wrote:
> I had assumed D was designed to be a GC language from the outset.

The D memory model is still in flux and always allowed C-like memory management. Whereas both Go and Java sacrificed fast C interfacing from the early days to get proper GC support, so there is a qualitative difference in the assumptions made in the language designs.

> It seems that the Go team are using backward compatibility as a rod for their own backs just as Java/JDK folk did.

Yes, maybe. Although I guess one strategy would be to allow library codebases to move along up until say Go 1.12 and get wide scale feature adoption in Go libraries that are very close to the 2.0 semantics, thus making porting to 2.0 more attractive to library devs. But some platforms, like App Engine is currently stuck at Go 1.6 so not sure how Google as a whole thinks about this.

Interestingly Dart is now moving towards static typing, as many of the current user Google users expect Java-like static predictability. So, one thing is what the language designers want, but maybe Google's own usage will take Go in another direction as well.

On Monday, 24 July 2017 at 12:47:43 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 24 July 2017 at 11:28:51 UTC, Russel Winder wrote:
>> I had assumed D was designed to be a GC language from the outset.
>
> The D memory model is still in flux and always allowed C-like memory management. Whereas both Go and Java sacrificed fast C interfacing from the early days to get proper GC support, so there is a qualitative difference in the assumptions made in the language designs.
>


I am obviously not a language design or implementation expert, but what you said, does it mean that D cannot have a fast GC by design