"It takes care of itself
-------------------------------
When writing a throwaway script that I will only use a handful of times, optimising that code isn’t necessarily high on my priority list. The priority is to get it written, and get it running. That’s where the V8 (C++) engine that NodeJS is compiled into throws you a bone.

When you have no choice but to call arrays into memory and manipulate them, sometimes very very large arrays, you can begin to worry about the state of your machine and the amount of memory that is being used. Luckily, V8 handles automatic garbage collection.

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 can be a bit intensive, it means when I am quickly iterating through code I don’t need to pay a tremendous amount of attention to my memory management, and I can entrust V8 to handle all the little nuances."

Don't be a computer. Do more with GC.

https://medium.com/@kieranmaher13/why-i-use-nodejs-for-basically-everything-i-do-e0a627787ecc

On Thursday, 11 October 2018 at 21:22:19 UTC, aberba wrote:
> When writing a throwaway script that I will only use a handful of times, optimising that code isn’t necessarily high on my priority list. The priority is to get it written, and get it running. That’s where the V8 (C++) engine that NodeJS is compiled into throws you a bone.
>

That is fine, if you want to position yourself as competition to languages like Go, Java or C#. D wants to be a viable competition to languages like C, C++ and Rust, as a result, there are usecases where GC might not be enough. Also, the quoted part mentions throwaway scripts, which D can be used for, but most people would use Python or Node.JS like in the article instead.

On Thursday, 11 October 2018 at 21:22:19 UTC, aberba wrote:
> "It takes care of itself
> -------------------------------
> When writing a throwaway script...

...there's absolutely no need for a GC. In fact, the GC runtime will only detract from performance.

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

> Don't be a computer. Do more with GC.

Writing a throwaway script there's nothing stopping you from using mmap or VirtualAlloc. 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.

On 10/12/2018 09:26 AM, Stanislav Blinov wrote:
> On Thursday, 11 October 2018 at 21:22:19 UTC, aberba wrote:
>> "It takes care of itself
>> -------------------------------
>> When writing a throwaway script...
> 
> ...there's absolutely no need for a GC. In fact, the GC runtime will only detract from performance.

Throwaway scripts can allocate a lot of memory and have nontrivial running times. It's less common for scripts than for long-running processes, granted, but I've written scripts to go through gigabytes of data.

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

People demonstrably have trouble doing that. We can do it most of the time, but everyone occasionally forgets.

Beyond that, the concept you're failing to mention here is ownership. You need to use your own mental effort to figure out what memory is owned by what part of the code. The GC lets you ignore that.

>> Don't be a computer. Do more with GC.
> 
> Writing a throwaway script there's nothing stopping you from using mmap or VirtualAlloc. 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.

A string is a plain old array, and languages with manual memory management also support associative arrays.

On Friday, 12 October 2018 at 17:31:30 UTC, Neia Neutuladh wrote:

> Throwaway scripts can allocate a lot of memory and have nontrivial running times. It's less common for scripts than for long-running processes, granted, but I've written scripts to go through gigabytes of data.

Your point being?.. It's not like you need a GC to allocate gigabytes of storage. With D it's super easy to just allocate a huge hunk and simply (literally) slice through it.

> People demonstrably have trouble doing that. We can do it most of the time, but everyone occasionally forgets.

The GC isn't a cure for forgetfulness. One can also forget to close a file or a socket, or I dunno, cancel a financial transaction.
GC isn't magic. In fact, to use it correctly you need to pay *more* attention than when managing memory manually. Don't leave dangling pointers. Nurse uninitialized data. Massage it to not sweep in hot paths... People seem to forget that and advertise it as some sort of magic wand that does all you want without you having to think.

> Beyond that, the concept you're failing to mention here is ownership. You need to use your own mental effort to figure out what memory is owned by what part of the code. The GC lets you ignore that.

Nope, it doesn't. If you "forget" who owns the data, you may as well "forget" who writes it and when. Would GC help then as well? You need to expend pretty much the same effort to track that.

>> Writing a throwaway script there's nothing stopping you from using mmap or VirtualAlloc. 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.
>
> A string is a plain old array.

An ASCII string, perhaps. Not a Unicode one. Count statically-typed compiled languages with native strings, please.

>  and languages with manual memory management also support associative arrays.

Of course they do. But again, are those built-in types?

On 10/12/2018 11:14 AM, Stanislav Blinov wrote:
> On Friday, 12 October 2018 at 17:31:30 UTC, Neia Neutuladh wrote:
> 
>> Throwaway scripts can allocate a lot of memory and have nontrivial running times. It's less common for scripts than for long-running processes, granted, but I've written scripts to go through gigabytes of data.
> 
> Your point being?.. It's not like you need a GC to allocate gigabytes of storage. With D it's super easy to just allocate a huge hunk and simply (literally) slice through it.

Over the lifetime of the script, it processed more memory than my computer had. That means I needed a memory management strategy other than "allocate everything". The GC made that quite easy.

>> People demonstrably have trouble doing that. We can do it most of the time, but everyone occasionally forgets.
> 
> The GC isn't a cure for forgetfulness. One can also forget to close a file or a socket, or I dunno, cancel a financial transaction.

By lines of code, programs allocate memory much more often than they deal with files or sockets or financial transactions. So anything that requires less discipline when dealing with memory will reduce bugs a lot, compared with a similar system dealing with sockets or files.

> GC isn't magic. In fact, to use it correctly you need to pay *more* attention than when managing memory manually. Don't leave dangling pointers. Nurse uninitialized data. Massage it to not sweep in hot paths... People seem to forget that and advertise it as some sort of magic wand that does all you want without you having to think.

It's good enough for a lot of people most of the time without thinking about things much. It reduces the frequency of problems and it eliminates use-after-free and double-free, which are sources of data corruption, which is hard to track down.

And in the context of a one-off script, I'm probably not going to worry about using the GC efficiently as long as I'm not running out of memory.

>> Beyond that, the concept you're failing to mention here is ownership. You need to use your own mental effort to figure out what memory is owned by what part of the code. The GC lets you ignore that.
> 
> Nope, it doesn't. If you "forget" who owns the data, you may as well "forget" who writes it and when. Would GC help then as well? You need to expend pretty much the same effort to track that.

That's why we have the const system.

On Friday, 12 October 2018 at 16:26:49 UTC, Stanislav Blinov wrote:
> On Thursday, 11 October 2018 at 21:22:19 UTC, aberba wrote:
>> "It takes care of itself
>> -------------------------------
>> When writing a throwaway script...
>
> ...there's absolutely no need for a GC. In fact, the GC runtime will only detract from performance.
>
>> 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.
>
>> Don't be a computer. Do more with GC.
>
> Writing a throwaway script there's nothing stopping you from using mmap or VirtualAlloc. 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.

What a bunch of nonsense! I used to talk like this some 20 years ago when all I saw in the computing world was C and C++...

Sure garbage collection is not for every project, depends what industry you are in I guess... In my case (business applications/services) I have never had the need to turn off garbage collection!

However, someone in the gaming industry, embedded or realtime systems would indeed need to turn off the GC...

On Friday, 12 October 2018 at 18:50:26 UTC, Neia Neutuladh wrote:

> Over the lifetime of the script, it processed more memory than my computer had. That means I needed a memory management strategy other than "allocate everything". The GC made that quite easy.

Now *that* is a good point. Then again, until you run out of address space you're still fine with just plain old allocate-and-forget. Not that it's a good thing for production code, but for one-off scripts? Sure.

>>> People demonstrably have trouble doing that. We can do it most of the time, but everyone occasionally forgets.
>> 
>> The GC isn't a cure for forgetfulness. One can also forget to close a file or a socket, or I dunno, cancel a financial transaction.

> By lines of code, programs allocate memory much more often than they deal with files or sockets or financial transactions. So anything that requires less discipline when dealing with memory will reduce bugs a lot, compared with a similar system dealing with sockets or files.

My point is it's irrelevant whether it's memory allocation or something else. If you allow yourself to slack on important problems, that habit *will* bite you in the butt in the future.
But the other end of the spectrum is also harmful. That's how we get those "good" APIs such as XCB that fragment the hell out of your heap, force libc on you and make you collect their garbage.

> It's good enough for a lot of people most of the time without thinking about things much.

That's precisely the line of thinking that gave us Java, C#, Python and other bastard languages that didn't want to concern themselves with the hardware all that much. 30 years of "progress" down the drain.

> It reduces the frequency of problems and it eliminates use-after-free

Not in D it doesn't. Unless you only ever write @safe code, in which case you're not in the "without thinking about things much" camp.

> and double-free, which are sources of data corruption, which is hard to track down.

Agreed.

> And in the context of a one-off script, I'm probably not going to worry about using the GC efficiently as long as I'm not running out of memory.

Sure, *that's* the appropriate message. Not the "use the GC, it's not as bad as you think".

>> If you "forget" who owns the data, you may as well "forget" who writes it and when. Would GC help then as well? You need to expend pretty much the same effort to track that.
>
> That's why we have the const system.

Oh please, really? Const in D? And you're still talking about people that don't like to think about things much?

On Friday, 12 October 2018 at 16:26:49 UTC, Stanislav Blinov wrote:
> On Thursday, 11 October 2018 at 21:22:19 UTC, aberba wrote:
>> "It takes care of itself
>> -------------------------------
>> When writing a throwaway script...
>
> ...there's absolutely no need for a GC. In fact, the GC runtime will only detract from performance.

For me, at least, spending an extra two weeks optimizing a program to eliminate that last 0.1 seconds of running time is not a good decision.

On Friday, 12 October 2018 at 19:06:36 UTC, Dejan Lekic wrote:

> What a bunch of nonsense! I used to talk like this some 20 years ago when all I saw in the computing world was C and C++...
>
> Sure garbage collection is not for every project, depends what industry you are in I guess... In my case (business applications/services) I have never had the need to turn off garbage collection!
>
> However, someone in the gaming industry, embedded or realtime systems would indeed need to turn off the GC...

Who said anything about turning it off? I'm pointing out that using the GC for the sake of simplicity is precisely the wrong reason to do so, that's it. Bunch of nonsense, right. Have fun writing sloppy code then.