4 ms·
We use D a lot at work, we genuinely can only laugh at people who refuse to entertain the idea of a GC. The GC allows our code to exist without extensive memory
by mhh__ 5y ago
We use D a lot at work, we genuinely can only laugh at people who refuse to entertain the idea of a GC. The GC allows our code to exist without extensive memory book-keeping.
When we want to avoid the GC we know how, when we want the productivity we use the GC and fuggedaboutit
- 0dyl 5y ago> we genuinely can only laugh at people That's perhaps not the best wording. Nonetheless, I do agree with you. D can be very flexible in that regard.
- mhh__ 5y agoI don't know how else to word it. Every thread about D has people going on and on and on and on about the GC, and they aren't always wrong (there is always good information here) but fundamentally it doesn't matter. Many D programmers come from PHP rather than C++ - D isn't attractive to them because of systems programming but rather high level programming e.g. metaprogramming.
- deleted 5y ago[deleted]
- jhgb 5y agoThere seems to be at least one reason to have a non-GC option: You want to write code that integrates with an environment that already has its own GC and you want that to decide things. For example you want to integrate existing libraries in C/C++/D/Go/Rust/whatever with a Lisp process, since there's lots of those libraries and they do useful things, and you don't have a Lisp library for that (yet). In that case having one point of deciding when to deallocate things seems to be better than having two of them.
- gwbas1c 5y agoUsing GC basically locks you into a particular memory model or framework. Having spent 20 years mostly working in GC languages, it's totally worth it! However, writing portable libraries like SQLite or libpng are very difficult to do without bringing in unacceptable overhead for your consumers.