5 ms·

> I give it about 10 years time, for pure manual memory management to be like Assembly and embedded development. For someone who has spent some time thinking a

> I give it about 10 years time, for pure manual memory management to be like Assembly and embedded development. For someone who has spent some time thinking about memory management strategies, manual MM isn't actually that much additional work. By far, most code doesn't allocate or free (and that's a good thing). So MM->GC is hardly like Assembly->Compiler. In Assembly you're constantly allocating and pigeonholing, and you can't have nice names for things. Assembly->Compiler is a huge step compared to MM->GC, and GC can cause a lot of headaches as well. (disclaimer, I've done almost no assembly at all).

pjmlp 7y ago
On single developer projects as long as one doesn't stay too much away from them, scale it up to multiple sized distributed teams, add binary libraries, and you end up with double frees, leaks and ownership issues all over the place.
- gpderetta 7y ago
  Purely anecdotally, I spend very little of my time thinking about what passes for manual memory management in C++. For me the big attraction of GC is memory safety not convenience.
  - bitwize 7y ago
    Try Rust. Proven memory safety, no GC.
    - gpderetta 7y ago
      no opportunity at $CURRENT_JOB, but in the future, sure, it is definitely on my radar!
    - pjmlp 7y ago
      Until one tries to do GUI programming, then it is Rc<RefCell<>> everywhere, or arrays with vector clocks for managing old entries.
- jstimpfle 7y ago
  Of course there will always be some issues somewhere. But, ignoring perfect memory safety, the issues are widely overblown, to the extent that I find manually managing memory a lot easier than dealing with GC once a project grows beyond a couple KLOC. It's all about proper planning and code organization. Use pooling, central manager structures, etc. If it can be avoided, then do not allocate and free stuff in a single function like you would carelessly do with automated GC. Structure the data such that you don't have to release stuff individually - put it in containers (such as vectors or maps), such that you can release everything at once at certain points in time, or such that you can quickly figure out what can be released at central code locations (that's much like automated GC, but it's staying in control and retaining room for optimization). I don't think "multiple distributed teams" makes the challenge any harder. You certainly want to (and I'm sure you easily can) contain each ownership management domain wholly in one team.
  - pjmlp 7y ago
    > You certainly want to (and I'm sure you easily can) contain each ownership management domain wholly in one team. That doesn't work in enterprise projects with heavy dosis of consulting.
eru 7y ago
> By far, most code doesn't allocate or free (and that's a good thing). Depends on the code you write. If, like in C++, non-stack memory management is painful, programmers tend to react like you suggest. In pure-by-default languages, you are creating new and destroying old objects all the time. (At least conceptually. A sufficiently smart compiler can eliminate most of that.)
- MauranKilom 7y ago
  Obviously depends on the use case, but since C++11 there is little to no pain involved in manual non-stack memory management. You clearly express the ownership semantics through things like std::unique_ptr and std::shared_ptr and if those make sense then everything works (minus problems like circular shared_ptr references, which exists in similar forms with GCs).
  - eru 7y ago
    > (minus problems like circular shared_ptr references, which exists in similar forms with GCs) Most GC can deal with circular references just fine?
    - MauranKilom 7y ago
      Yeah, I didn't elaborate this enough (because it wasn't really the main point). When I said "similar" I meant "things holding onto things they should no longer be holding onto", not circular referencing in particular. I realize that the kind of bug that leads to effective memory leaks with GCs has its own equivalent in manual memory management, but my overall point was that neither manual memory management nor GCs make you immune to leaks from badly designed or incorrectly implemented data structures. Each takes some aspect(s) of pain away.

pjmlp 7y ago

On single developer projects as long as one doesn't stay too much away from them, scale it up to multiple sized distributed teams, add binary libraries, and you end up with double frees, leaks and ownership issues all over the place.

gpderetta 7y ago
Purely anecdotally, I spend very little of my time thinking about what passes for manual memory management in C++. For me the big attraction of GC is memory safety not convenience.
- bitwize 7y ago
  Try Rust. Proven memory safety, no GC.
  - gpderetta 7y ago
    no opportunity at $CURRENT_JOB, but in the future, sure, it is definitely on my radar!
  - pjmlp 7y ago
    Until one tries to do GUI programming, then it is Rc<RefCell<>> everywhere, or arrays with vector clocks for managing old entries.
jstimpfle 7y ago
Of course there will always be some issues somewhere. But, ignoring perfect memory safety, the issues are widely overblown, to the extent that I find manually managing memory a lot easier than dealing with GC once a project grows beyond a couple KLOC. It's all about proper planning and code organization. Use pooling, central manager structures, etc. If it can be avoided, then do not allocate and free stuff in a single function like you would carelessly do with automated GC. Structure the data such that you don't have to release stuff individually - put it in containers (such as vectors or maps), such that you can release everything at once at certain points in time, or such that you can quickly figure out what can be released at central code locations (that's much like automated GC, but it's staying in control and retaining room for optimization). I don't think "multiple distributed teams" makes the challenge any harder. You certainly want to (and I'm sure you easily can) contain each ownership management domain wholly in one team.
- pjmlp 7y ago
  > You certainly want to (and I'm sure you easily can) contain each ownership management domain wholly in one team. That doesn't work in enterprise projects with heavy dosis of consulting.

eru 7y ago

> By far, most code doesn't allocate or free (and that's a good thing). Depends on the code you write. If, like in C++, non-stack memory management is painful, programmers tend to react like you suggest. In pure-by-default languages, you are creating new and destroying old objects all the time. (At least conceptually. A sufficiently smart compiler can eliminate most of that.)

MauranKilom 7y ago
Obviously depends on the use case, but since C++11 there is little to no pain involved in manual non-stack memory management. You clearly express the ownership semantics through things like std::unique_ptr and std::shared_ptr and if those make sense then everything works (minus problems like circular shared_ptr references, which exists in similar forms with GCs).
- eru 7y ago
  > (minus problems like circular shared_ptr references, which exists in similar forms with GCs) Most GC can deal with circular references just fine?
  - MauranKilom 7y ago
    Yeah, I didn't elaborate this enough (because it wasn't really the main point). When I said "similar" I meant "things holding onto things they should no longer be holding onto", not circular referencing in particular. I realize that the kind of bug that leads to effective memory leaks with GCs has its own equivalent in manual memory management, but my overall point was that neither manual memory management nor GCs make you immune to leaks from badly designed or incorrectly implemented data structures. Each takes some aspect(s) of pain away.