On 12/19/2017 2:30 PM, Mengu wrote:
> i never had a chance to thank you for d, so here it goes: thank you very much! been in love with it for so long. despite my anger, i keep coming back :)

You're welcome!

> would you mind writing a tutorial / blog post on this matter for dummies such as myself? from what i gather from the forum posts is that _in theory_ we can do this but _in reality_ most of us don't know how.

I'm not very good at tutorials. But plenty of others here are!

Seems to me there is a really, really good article for CVu or Overload in all this, starting  with reprinting the ESR article, follwed up by some experience history article like this.


On Tue, 2017-12-19 at 11:42 -0800, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Dec 19, 2017 at 01:54:05AM -0800, Walter Bright via Digitalmars-d wrote:
> > "C, Python, Go, and the Generalized Greenspun Law"
> > 
> > http://esr.ibiblio.org/?p=7804
> 
> Coming from a strong C/C++ background, it took me a good long while
> to
> accept the GC.  I had all the usual objections about lack of control
> (e.g. over GC pauses), lack of determinism (never know when something
> will get collected), performance, etc..  But there's one thing the GC
> gives that no amount of clever programming can: productivity.
> 
> It's exactly as ESR says: once your code gets to a certain point of
> complexity, in a manual memory management language like C/C++ your
> coding time becomes more and more disproportionately spent on
> managing
> memory rather than working on your problem domain. That is, if you
> wish
> to preserve code correctness.  It *is* possible to be productive past
> this point, but memory-related bugs become more frequent and
> eventually
> overwhelms your effort to make progress in the problem domain.
> 
> After I started writing non-trivial code in D, I found my brain has
> been
> freed up from the constant energy drain of having to think about
> managing memory -- is that pointer still in scope, do I have to free
> it,
> have I freed it already, are the parameters borrowed references or
> transfer of ownership, should they be borrowed references instead,
> should I use a refcounting wrapper instead, what happens to this
> template if a refcounted type was passed in instead of something
> else,
> what happens to the reference if an exception is thrown here, ad
> nauseam
> -- now I can actually think about the algorithm as it directly
> pertains
> to the problem domain, rather than constantly fiddling with the dirty
> details of memory management.
> 
> As a result, not only my productivity skyrocketed, but the
> correctness
> of my algorithms improved. When you're constantly under the nagging
> of
> manual memory management gotchas, you may well churn out
> *memory-correct* code, but not necessarily code that's correct *in
> the
> problem domain*.  Being freed from the fidgety concerns of memory
> management means more mental resources can be directed at actually
> solving the problem at hand and doing a better job at it.  Not to
> mention an entire class of memory-related bugs are eliminated by the
> GC.
> 
> That's why nowadays my opinion is that if you're not working with
> performance-sensitive code (i.e., where every missed CPU cycle
> increases
> the likelihood of a patient dying or the airplane crashing), and if
> you
> haven't profiled your code to clearly show that the GC is a
> performance
> bottleneck, then you really should just let the GC do its job.  There
> *have* been cases where I've found that GC performance is hindering
> my
> code; so far, judicious, strategic use of GC.disable() and manual
> calls
> to GC.collect() have sufficed to fix that, without needing to throw
> out
> the GC baby with the bathwater altogether.  Having to go back to
> paying
> the mental memory management tax on every other line of code I write
> is
> just not a wise use of my time and energy.
> 
> 
> T
> 
-- 
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 Tuesday, 19 December 2017 at 22:30:57 UTC, Mengu wrote:
> On Tuesday, 19 December 2017 at 10:09:41 UTC, Walter Bright wrote:
>> I tend to write hybrid programs in D, so I wouldn't call it a fallback. Just like I might use both structs and classes!

[snip]

> would you mind writing a tutorial / blog post on this matter for dummies such as myself? from what i gather from the forum posts is that _in theory_ we can do this but _in reality_ most of us don't know how.

Anything in particular you find missing in the GC-series blog posts [1]?

[1] https://dlang.org/blog/the-gc-series/

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

But ESR doesn't seem to be fond of the GC idea for C like languages though.
He states in a comment:

">For a long time I’ve been holding out hope for a ‘standard’ garbage collector library for C. But not gonna hold my breath.

Yeah, good idea not to. People as smart/skilled as you and me have been poking at this problem since the 1980s and it’s pretty easy to show that you can’t do better than Boehm–Demers–Weiser, which has limitations that make it impractical. Sigh…"

Which does not say that he is against D's philosophy to offer GC and RC.

Interestingly he doesn't know about D and he hasn't answered your comment yet but instead answered another commenter about D and got some pointers.
We will see if he looks into D and shares his opinion about it.

On 19/12/17 11:54, Walter Bright wrote:
> "C, Python, Go, and the Generalized Greenspun Law"
> 
> http://esr.ibiblio.org/?p=7804
> 

I have two takeaways from that article:

1. ESR doesn't understand C++ one bit.
2. I feel exactly the same way about D.

I'll start with 1. I've been writing in C++ for a long time now, and have *never* had to spend much time on double frees/leaks. This is especially true since C++11, where the built-in types are good enough for anything which doesn't include graphs with cycles (and, yes, I would use a GC for those).

RAII + reference counting where needed pretty much eliminated those problems for me. ESR's lumping of C++ and C together, at the very least, lacks an explanation of why C++'s additional tools for handling this case are insufficient. A more likely case is that ESR is simply ignorant of them and their impact when used correctly.

The only times where I saw people mucking about with the allocators is when the *performance* profile was deemed not good enough. D's built-in facilities have nothing to offer on that front: The main case against the GC is it's horrid (and, worse, unexpected) performance.


I spend a lot of my time on D trying to work around the limitations that the GC is imposing on me, to the point where I feel like much we do here is to write our own infrastructure, because we can't use the built-in one. To be clear, the problem is a performance one here too, but the handling is completely different.

In C++ it is possible to start with the built-in facilities and then slowly work alternative ones as bottlenecks are analyzed. No such path is possible in D. If you don't want to use the GC, you will need to rework *everything*. Your entire code will have to revolve around using non-GC facilities, most of which you will have to write for yourself.

So, no, I'm not convinced.

Shachar

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

That is what I keep saying thanks to my experience using Oberon systems during
the 90's, and following everything that was done with Mesa/Cedar, Modula-2+, Modula-3, Singularity, Midori, just to name the most famous ones in CS circles.

Microsoft has been busying adopting lessons from Midori into C#, hence .NET Native, and the language changes for features already present in D.

The problem is that this yet another area where developers only change their opinion if they experience themselves what it means to use a GC enabled systems programming language.

It is very hard to change the mentality that just because the GC is there, doesn't mean there aren't other ways to manage memory and other resources.

GC is a convenience, if at the end the use case constraints aren't met, then it is time to profile and use other approaches, like actually doing some manual memory management in the hot path, but only if it really a must have.

Google is already using Go on some of their Fuchsia system modules, like the TCP/IP stack and file system driver utilities, maybe someone like Google really needs to push such an OS into developers to settle the discussion once for all.

And then D's GC won't be an issue any more, given that the language is much better than just using Go.

--
Paulo

On Tuesday, 19 December 2017 at 11:03:37 UTC, Joakim wrote:
> On Tuesday, 19 December 2017 at 10:54:12 UTC, w0rp 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 think D and the GC are highly appropriate for developing high performance application software. That's where D really shines. It's a shame that Qt is such a nightmare to use in anything that isn't C++. GTK is easy enough to use at least. What's funny is that both frameworks implement their own memory management schemes. That points to a need for automatic memory management.
>
> Why only application software?  The point of that blog post is that whole swathes of system programming should be done with mostly GC, leaving only OS kernels, some real-time apps, and the highly-constrained embedded space to the betterC mode.

Which is actually how Android works.

NDK is quite constrained and its only purpose is for high performance 3D graphics (Vulkan), real-time audio, SIMD/NEON and integrating existing C and C++ code into Java.

Everything else is done in Java, and on Android Things even user space drivers are implemented in Java.

Also where Microsoft is driving UWP into, C++ for kernel, graphics and performance critical UWP components, and everything else in .NET Native.

Even the UI team does their Fluent UI graphical effect demos in C#.

--
Paulo

On Wednesday, 20 December 2017 at 08:49:18 UTC, Shachar Shemesh wrote:
> On 19/12/17 11:54, Walter Bright wrote:
>> "C, Python, Go, and the Generalized Greenspun Law"
>> 
>> http://esr.ibiblio.org/?p=7804
>> 
>
> I have two takeaways from that article:
>
> 1. ESR doesn't understand C++ one bit.
> 2. I feel exactly the same way about D.
>
> I'll start with 1. I've been writing in C++ for a long time now, and have *never* had to spend much time on double frees/leaks. This is especially true since C++11, where the built-in types are good enough for anything which doesn't include graphs with cycles (and, yes, I would use a GC for those).
>
> RAII + reference counting where needed pretty much eliminated those problems for me. ESR's lumping of C++ and C together, at the very least, lacks an explanation of why C++'s additional tools for handling this case are insufficient. A more likely case is that ESR is simply ignorant of them and their impact when used correctly.
>
> The only times where I saw people mucking about with the allocators is when the *performance* profile was deemed not good enough. D's built-in facilities have nothing to offer on that front: The main case against the GC is it's horrid (and, worse, unexpected) performance.
>
>
> I spend a lot of my time on D trying to work around the limitations that the GC is imposing on me, to the point where I feel like much we do here is to write our own infrastructure, because we can't use the built-in one. To be clear, the problem is a performance one here too, but the handling is completely different.
>
> In C++ it is possible to start with the built-in facilities and then slowly work alternative ones as bottlenecks are analyzed. No such path is possible in D. If you don't want to use the GC, you will need to rework *everything*. Your entire code will have to revolve around using non-GC facilities, most of which you will have to write for yourself.
>
> So, no, I'm not convinced.
>
> Shachar

I agree with you regarding C++ when I program alone, it is beautiful safe C++14 (now C++17) code.

However I completely disagree when I have to deal with the typical enterprise C++ code, that most of the time looks like C being compiled with a C++ compiler, from developers that learned it before C++98 and can't care less what is being discussed on Reddit and HN.

So I happily use Java and C# at work, only dealing with C++ for low level OS integration stuff, because that C++ that I am going to touch, written by such devs, will require gloves and tweezers.

--
Paulo

On 20.12.2017 09:30, Thomas Mader wrote:
> Interestingly he doesn't know about D

http://esr.ibiblio.org/?p=7724

On Wednesday, 20 December 2017 at 09:16:34 UTC, Timon Gehr wrote:
> On 20.12.2017 09:30, Thomas Mader wrote:
>> Interestingly he doesn't know about D
>
> http://esr.ibiblio.org/?p=7724

Haven't read that one but it just shows it:

"Since I’ve mentioned D, I suppose this is also the point at which I should explain why I don’t see it as a serious contender to replace C. Yes, it was spun up eight years before Rust and nine years before Go – props to Walter Bright for having the vision. But in 2001 the example of Perl and Python had already been set – the window when a proprietary language could compete seriously with open source was already closing. The wrestling match between the official D library/runtime and Tango hurt it, too. It has never recovered from those mistakes."

So he doesn't know about the current state of D and I was referring to the following comment from http://esr.ibiblio.org/?p=7804:

">Eric, have you looked into D *lately*?

No. What’s it got that Go does not?

That’s not intended as a hostile question, I’m trying to figure out where to focus my attention when I read up on it."

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.