You don't like GC? Do you?

[Stanislav Blinov]

On Friday, 12 October 2018 at 21:34:35 UTC, Atila Neves wrote:

>>> -------------------------------
>>> When writing a throwaway script...
>>
>> ...there's absolutely no need for a GC.
>
> True. There's also absolutely no need for computer languages 
> either, machine code is sufficient.

Funny. Now for real, in a throwaway script, what is there to gain 
from a GC? Allocate away and forget about it.

>> In fact, the GC runtime will only detract from performance.

> Demonstrably untrue. It puzzles me why this myth persists.

Myth, is it now? Unless all you do is allocate memory, which 
isn't any kind of useful application, pretty much on each sweep 
run the GC's metadata is *cold*. What's worse, you don't control 
how much data there is and where it is. Need I say more? If you 
disagree, please do the demonstration then.

> There are trade-offs, and one should pick whatever is best for 
> the situation at hand.

Exactly. Which is *not at all* what the OP is encouraging to do.

>>> What this means is that whenever I have disregarded a block 
>>> of information, say removed an index from an array, then that 
>>> memory is automatically cleared and freed back up on the next 
>>> sweep. While the process of collection and actually checking
>>
>> Which is just as easily achieved with just one additional line 
>> of code: free the memory.
>
> *Simply* achieved, not *easily*. Decades of bugs has shown 
> emphatically that it's not easy.

Alright, from one non-native English speaker to another, well 
done, I salute you. I also used the term "dangling pointer" 
previously, where I should've used "non-null". Strange you didn't 
catch that.
To the point: *that* is a myth. The bugs you're referring to are 
not *solved* by the GC, they're swept under a rug. Because the 
bugs themselves are in the heads, stemming from that proverbial 
programmer laziness. It's like everyone is Scarlett O'Hara with a 
keyboard.

For most applications, you *do* know how much memory you'll need, 
either exactly or an estimation. Garbage collection is useful for 
cases when you don't, or can't estimate, and even then a limited 
subset of that.

>>> Don't be a computer. Do more with GC.
>>
>> Writing a throwaway script there's nothing stopping you from 
>> using mmap or VirtualAlloc.
>
> There is: writing less code to achieve the same result.

Well, I guess either of those do take more arguments than a 
"new", so yup, you do indeed write "less" code. Only that you 
have no clue how much more code is hiding behind that "new", how 
many indirections, DLL calls, syscalls with libc's wonderful 
poison that is errno... You don't want to think about that. Then 
two people start using your script. Then ten, a hundred, a 
thousand. Then it becomes a part of an OS distribution. And no 
one wants to "think about that".

>> The "power" of GC is in the language support for non-trivial 
>> types, such as strings and associative arrays. Plain old 
>> arrays don't benefit from it in the slightest.

> For me, the power of tracing GC is that I don't need to think 
> about ownership, lifetimes, or manual memory management.

Yes you do, don't delude yourself. Pretty much the only way you 
don't is if you're writing purely functional code. But we're 
talking about D here.
Reassigned a reference? You thought about that. If you didn't, 
you just wrote a nasty bug. How much more hypocrisy can we reach 
here?

"Fun" fact: it's not @safe to "new" anything in D if your program 
uses any classes. Thing is, it does unconditionally thanks to 
DRuntime.

> I also don't have to please the borrow checker gods.

Yeah, that's another extremum. I guess "rustacians" or whatever 
the hell they call themselves are pushing that one, don't they? 
"Let's not go for a GC, let's straight up cut out whole paradigms 
for safety's sake..."

> Yes, there are other resources to manage. RAII nearly always 
> manages that, I don't need to think about that either.

Yes you do. You do need to write those destructors or scoped 
finalizers, don't you? Or so help me use a third-party library 
that implements those? There's fundamentally *no* difference from 
memory management here. None, zero, zip.

Sad thing is, you're not alone. Look at all the major OSs today. 
How long does it take to, I don't know, open a project in the 
Visual Studio on Windows? Or do a search in a huge file opened in 
'less' on Unix? On an octacore 4GHz machine with 32Gb 3GHz 
memory? Should just instantly pop up on the screen, shouldn't it? 
Why doesn't it then? Because most programmers think the way you 
do: "oh it doesn't matter here, I don't need to think about 
that". And then proceed to advocate those "awesome" laid-back 
solutions that oh so help them save so much time coding. Of 
course they do, at everyone else's expense. Decades later, we're 
now trying to solve problems that shouldn't have existed in the 
first place. You'd think that joke was just that, a joke...

But let's get back to D. Look at Phobos. Why does stdout.writefln 
need to allocate? How many times does it copy it's arguments? Why 
can't it take non-copyable arguments? Does it change global state 
in your process' address space? Does it impose external 
dependencies? You don't want to think about that? The author 
likely didn't either. And yet everybody is encouraged to use 
that: it's out of the box after all...
Why is Socket a class, blown up from a puny 32-bit value to a 
bloated who-knows-how-many-bytes monstrosity? Will that socket 
close if you rely on the GC? Yes? No? Maybe? Why?
Can I deploy the compiler on a remote machine with limited RAM 
and expect it to always successfully build my projects and not 
run out of memory?

I can go on and on, but I hope I finally made my point somewhat 
clearer. Just in case, a TLDR: *understand your machine and your 
tools and use them accordingly*. There are no silver bullets for 
anything, and that includes the GC. If you go on advocating it 
because it helped you write a 1kLOC one-time-use script, it's 
very likely I don't want to use anything you write.