You don't like GC? Do you?

[Neia Neutuladh]

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.