On Wednesday, January 03, 2018 19:03:20 Dan Partelly via Digitalmars-d wrote:
> On Tuesday, 2 January 2018 at 01:07:21 UTC, Jonathan M Davis
>
> wrote:
> > On Tuesday, January 02, 2018 00:34:57 Nerve via Digitalmars-d
> >
> > 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 would simply add that the strongest vocalizations come from those with objections. The silent majority that is perfectly okay with GC and gets huge development complexity reductions thanks to it rarely spare the energy to argue againts the constant GC complaints.
> >
> > +1
> >
> > - Jonathan M Davis
>
> Really, would you expect that the strongest vocalizations should come from those with no objections ? (save for ESR's rant ? ). No need to answer.

The problem is that there are some very vocal folks who complain about the GC, and then that often leads to folks thinking that there's a serious problem with the fact that D has a GC, when arguably, that isn't true at all. There are pros and cons to using a GC, there are some circumstances where it's not appropriate, and we can do better to have it be optional where appropriate, but in spite of what some of the vocal folks say, it has been a big boon to D to have a GC, and it gets increasingly annoying to have to deal with folks insisting that the GC should be excised from everywhere and avoided as much as possible.

So, if no one speaks up about how it's actually great to have a GC, it starts seeming like we all think that D shouldn't have a GC, which isn't the case at all.

- Jonathan M Davis

On Wednesday, 3 January 2018 at 21:11:06 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 3 January 2018 at 19:42:28 UTC, Tony wrote:
>> Why would someone choose to use a language with a Garbage Collector and then complain that the language has a Garbage Collector?
>
> People always complain about garbage collectors that freeze up the process. Irrespective of the language. It's the antithesis of low level programming…

Why would they choose D for low level programming when they knew before they chose it that it had a Garbage Collector? It seems like their programming language decision methodology  was flawed. To me,  the only people who should be complaining about D's garbage collector are people who don't use D, not people who do. But maybe that is the case, the people who complain about the Garbage Collector in this D forum are not using D.

On Wed, Jan 03, 2018 at 03:28:15PM -0700, Jonathan M Davis via Digitalmars-d wrote: [...]
> The problem is that there are some very vocal folks who complain about the GC, and then that often leads to folks thinking that there's a serious problem with the fact that D has a GC, when arguably, that isn't true at all. There are pros and cons to using a GC, there are some circumstances where it's not appropriate, and we can do better to have it be optional where appropriate, but in spite of what some of the vocal folks say, it has been a big boon to D to have a GC, and it gets increasingly annoying to have to deal with folks insisting that the GC should be excised from everywhere and avoided as much as possible.
> 
> So, if no one speaks up about how it's actually great to have a GC, it starts seeming like we all think that D shouldn't have a GC, which isn't the case at all.
[...]

+1.

Even though I'm well aware of the current GC's limitations, and have implemented various workarounds in my own code, I totally agree that it has been great to have a GC in D.  It frees up a big chunk of my mental capacity while coding to actually think about the problem domain, rather than being drained by constantly needing to think about memory management issues, like I have to when writing C/C++ code.  It makes for faster development time, and less bugs (heck, it eliminates an entire class of bugs that commonly plague C/C++ code).

The performance cost is usually not even noticeable unless you're writing (1) memory-intensive, CPU-intensive code, or (2) real-time code like medical appliance controllers where people may die if the code doesn't respond within 1ms, or (3) 3D game engines where people may die if they miss an animation frame or two, though only virtually. :-P

When the GC *does* become a source of performance concerns, I've found that in 99% of the cases all it takes is to call GC.disable and schedule your own GC.collect at strategic points in your code.  In one particular memory-intensive, CPU-intensive program I wrote, all I needed was to make a 3-line change:

	...
	GC.disable;
	...
	if (++counter % 1_000_000 == 0) // or whatever number you wish
		GC.collect;

and I was able to obtain performance improvements upwards of 40%.

Furthermore, upon closer inspection, eliminating array allocations in one specific hotspot in my inner loop by reusing a static buffer won me another 15-20% performance improvement, again a rather small code change, and standard practice to reduce GC load.

All it took was to run a profiler to identify the hotspots, and fix the few places in the code where it actually mattered (and usually, such places only need a minor change).  The rest of the code was perfectly fine using the GC just as it is. There was no need to completely excise the GC, rewrite all of my code to use ref-counting or *shudder* malloc/free, or any of the extreme stuff that the vocal minority seems to advocate for.

I'm not saying there aren't use cases where you *do* want to use @nogc and completely avoid the GC (@nogc is there for a reason), but that these use cases aren't all as common as some people would have us think. The majority of application code won't even notice a difference, even with the current supposedly poor GC.


T

-- 
Windows: the ultimate triumph of marketing over technology. -- Adrian von Bidder

On Wednesday, 3 January 2018 at 22:37:54 UTC, Tony wrote:
> Why would they choose D for low level programming when they knew before they chose it that it had a Garbage Collector?

Because it was/is a work-in-progress when they first got interested in it, and it was also advertised as a replacement for C and C++.  It was also assumed that one could expect significant improvements on the GC as the language matured. But of course, computers also get more and more memory to scan…


> who do. But maybe that is the case, the people who complain about the Garbage Collector in this D forum are not using D.

Both. Some use D, but not the GC after initialization. Some wanted to use D (in production), but has put that on hold and are just waiting to see where it is heading. Some gave up on D for low level programming and turned to other languages.

So yes and no. ;-)

On Wednesday, 3 January 2018 at 22:28:15 UTC, Jonathan M Davis wrote:


>
> So, if no one speaks up about how it's actually great to have a GC, it starts seeming like we all think that D shouldn't have a GC, which isn't the case at all.
>
> - Jonathan M Davis

Having GC is awesome, it's like driving a luxury car with all the comfort and safety on highways.  But also there is need for raw powerful cars which  can be driven off-roads, accepting the risks, to haul metal and lumber to civilization, to build infrastructure.

Now my perception is that D tries hard to be both, with some regrettable consequences. Started as a GC language with language features which depend on GC, and a std which was done for a GC language and has dependency on GC. But it also envied
the cars which can be driven off roads, so it allowed GC to be disabled. At the cost of being unable to use parts of the language, and whole parts of std. Then it got even more envious and got a -betterC mode whose raison d'etre is unclear, apart from some people saying it's Walter's toy, which crippled D even more, and made std a dubious proposition until someone goes through it step by step and see the traps.
This could have been solved in 2 ways imo (hindsight )

1. Commit to GC , implement state of the art collector and be happy ever after
2. Go 0 abstraction route. Keep core language independent of GC and have std not depending on it. Then add GC support with the ability to completely disable it with a compiler switch from runtime.

On Thursday, 4 January 2018 at 08:09:27 UTC, Dan Partelly wrote:

> Now my perception is that D tries hard to be both, with some regrettable consequences. Started as a GC language with language features which depend on GC, and a std which was done for a GC language and has dependency on GC. But it also envied
> the cars which can be driven off roads, so it allowed GC to be disabled. At the cost of being unable to use parts of the

Envy? Hardly. Being able to disable D's GC was a feature from early on. Phobos has been modified over the years to make it more compatible with that scenario, as was widely requested.


> language, and whole parts of std. Then it got even more envious and got a -betterC mode whose raison d'etre is unclear, apart from some people saying it's Walter's toy, which crippled D even more, and made std a dubious proposition until someone goes through it step by step and see the traps.

The reason for -betterC is quite clear (and again, has nothing to do with envy): to make it easier to port C (and eventually C++) code to D, and to make D easier to use in environments where the runtime is a burden (e.g. OS kernels). It does not "cripple" D.

On Thursday, 4 January 2018 at 08:28:31 UTC, Mike Parker wrote:
abled. At the cost of being unable to use parts of the
>
> Envy? Hardly. Being able to disable D's GC was a feature from early on. Phobos has been modified over the years to make it more compatible with that scenario, as was widely requested.

I used envy colloquially.
Yes, disabling GC might have been a feature early on. But not early on enough to not have core language features depending on it, and not early enough to have a std not depending on it. Modifying the std to be more compatible with this scenario is indeed happening, but as you say it is a process which started years ago, and its still dragging on, and no clear docs with what works and what not.


>
> The reason for -betterC is quite clear (and again, has nothing to do with envy): to make it easier to port C (and eventually C++) code to D, and to make D easier to use in environments where the runtime is a burden (e.g. OS kernels). It does not "cripple" D.

Rust has a OS being written right now. Does D has ? Anyone ever wanted to use D to write a OS kernel, I doubt it. Is anyone seriously thinking today to port their *working* and maintained C code bases to D, possibly introducing new bugs in the process ? (yes some people like Walter did, Im aware of this. But I doubt this will have any serious adoption)

Id rather use a nice language as D to write new software, not to port old **working**   tools which are only maintained and not developed to it. I see no sense for that.

On Thursday, 4 January 2018 at 10:18:29 UTC, Dan Partelly wrote:

> Id rather use a nice language as D to write new software, not to port old **working**   tools which are only maintained and not developed to it. I see no sense for that.

And the reality of having ported the DMD frontend to D and that Walter is porting the DMC frontend to D is here to just tell us that such things are worth sometimes...

/P

On Thursday, 4 January 2018 at 10:18:29 UTC, Dan Partelly wrote:
> Rust has a OS being written right now. Does D has ? Anyone ever wanted to use D to write a OS kernel, I doubt it.

Yes, a group started on it,  but I don't think it reached completion. Anyway, you see traces of interest around the internet, e.g. http://wiki.osdev.org/D_Bare_Bones

But the argument is fair, as long as Walter and Andrei are trying to position D as an alternative to C and C++. Then D should be evaluated on those terms.

However, Rust won't fare well in a head-to-head comparison either, because of the issues with back-pointers.

On Thursday, 4 January 2018 at 10:40:33 UTC, Ola Fosheim Grøstad wrote:
> However, Rust won't fare well in a head-to-head comparison either, because of the issues with back-pointers.

Could you explain this?