You don't like GC? Do you?

[Atila Neves]

On Friday, 12 October 2018 at 23:24:56 UTC, Stanislav Blinov 
wrote:
> 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 case you run out of memory, the GC scans. That's the gain.

>>> In fact, the GC runtime will only detract from performance.
>
>> Demonstrably untrue. It puzzles me why this myth persists.
>
> Myth, is it now?

Yes.

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

*If* the GC scans.

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

I disagree. What I got from the OP was that for most code, the GC 
helps. I agree with that sentiment.

> Alright, from one non-native English speaker to another, well 
> done, I salute you.

The only way I'd qualify as a non-native English speaker would be 
to pedantically assert that I can't be due to not having learned 
it first. In any case, I'd never make fun of somebody's English 
if they're non-native, and that's most definitely not what I was 
trying to do here - I assume the words "simple" and "easy" exist 
in most languages. I was arguing about semantics.

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

Not in my experience. They've literally disappeared from the code 
I write.

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

IMHO, lazy programmers are good programmers.

> For most applications, you *do* know how much memory you'll 
> need, either exactly or an estimation.

I don't, maybe you do. I don't even care unless I have to. See my 
comment above about being lazy.

> 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",

I have a clue. I could even look at the druntime code if I really 
cared. But I don't.

> how many indirections, DLL calls, syscalls with libc's 
> wonderful poison that is errno... You don't want to think about 
> that.

That's right, I don't.

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

Meh. There are so many executables that are part of distributions 
that are written in Python, Ruby or JavaScript.

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

No, I don't. I used to in C++, and now I don't.

> Pretty much the only way you don't is if you're writing purely 
> functional code.

I write pure functional code by default. I only use side-effects 
when I have to and I isolate the code that does.

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

I probably didn't write a nasty bug if the pointer that was 
reassigned was to GC allocated memory. It lives as long as it has 
to, I don't think about it.

> "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 hardly ever use classes in D, but I'd like to know more about 
why it's not @safe.

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

I write a destructor once, then I never think about it again. 
It's a lot different from worrying about closing resources all 
the time. I don't write `scope(exit)` unless it's only once as 
well, otherwise I wrap the code in an RAII struct.

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

I don't know. I don't think Socket should even have been a class. 
I assume it was written in the D1 days.

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

If the compiler had the GC turned on, yes. That's not a point 
about GC, it's a point about dmd.