4 ms·

I only work in GCed languages, so I don't know how manual memory management works, except segfaults in some courses at university. Guess I should quit my job, a

I only work in GCed languages, so I don't know how manual memory management works, except segfaults in some courses at university. Guess I should quit my job, as you say I apparently can't really code :/ Thanks for letting me and others here know!

ndepoel 7y ago
In my experience GC makes programmers sloppy in their resource usage. Just allocate a bunch of memory annnd... whatever, the GC will take care of that. But there are a lot of other resources besides memory that aren't automatically cleaned up like that. So what happens is people forget to close network sockets, forget to unsubscribe event handlers, forget to set certain references to null to actually allow the GC to do its work, etcetera... The existence and over-reliance on GCs has led to a mindset where many programmers are just not aware that what you create must also be destroyed at some point.
stephc_int13 7y ago
Let me rephrase this. In the CS / Programming space, we have quite a lot of difficult problems to solve, in my opinion, memory management is really easy compared for example to multithreading. In fact the so called Garbage Collector do not really solve the problem of memory management, there are still a lot of potential for leaks and poor memory management when GC is used. And it adds a lot of complexity to the language runtime, and it gets in the way, I've seen a lot of discussions about how to avoid triggering the GC, in the end, the solutions are more complex than good old manual memory management. I am not saying that memory management is trivial if it was it could efficiently be handled by the compiler or the runtime. There is no magic bullet solution for easy memory management, one has to choose the right policy considering the context, which is most of the time out of reach for the compiler. The context is mostly the expected lifetime of the memory allocation.

ndepoel 7y ago

In my experience GC makes programmers sloppy in their resource usage. Just allocate a bunch of memory annnd... whatever, the GC will take care of that. But there are a lot of other resources besides memory that aren't automatically cleaned up like that. So what happens is people forget to close network sockets, forget to unsubscribe event handlers, forget to set certain references to null to actually allow the GC to do its work, etcetera... The existence and over-reliance on GCs has led to a mindset where many programmers are just not aware that what you create must also be destroyed at some point.

stephc_int13 7y ago

Let me rephrase this. In the CS / Programming space, we have quite a lot of difficult problems to solve, in my opinion, memory management is really easy compared for example to multithreading. In fact the so called Garbage Collector do not really solve the problem of memory management, there are still a lot of potential for leaks and poor memory management when GC is used. And it adds a lot of complexity to the language runtime, and it gets in the way, I've seen a lot of discussions about how to avoid triggering the GC, in the end, the solutions are more complex than good old manual memory management. I am not saying that memory management is trivial if it was it could efficiently be handled by the compiler or the runtime. There is no magic bullet solution for easy memory management, one has to choose the right policy considering the context, which is most of the time out of reach for the compiler. The context is mostly the expected lifetime of the memory allocation.