On 11 December 2011 15:15, maarten van damme <maartenvd1994@gmail.com> wrote:

2011/12/11 Paulo Pinto <pjmlp@progtools.org>
Am 10.12.2011 21:35, schrieb Andrei Alexandrescu:
On 12/10/11 2:22 PM, maarten van damme wrote:
Just for fun I
wanted to create a program as little as possible, compiled without
garbage collector/phobos/... and it turned out that compiling without
garbage collector is pretty much impossible (memory leaks all around the
place in druntime). dynamic linking for the d standard library would be
a great new option for a dmd release in the future :).

Using D without GC is an interesting direction, and dynamic linking
should be available relatively soon.


Andrei

As a long time beliver in systems programming languages with GC support
(Modula-3, Oberon, Sing#, ...), I think allowing this in D is the wrong direction.

Sure provinding APIs to control GC behavior makes sense, but not turn it
off, we already have enough languages to do systems programming without GC.

I was only trying it "for the fun of it", not to be used seriously. D should always have it's GC support built-in and have some functions to control it's behaviour (core.memory). But I think that D, beeing a systems programming language, should also be able to be used without GC. I don't mean phobos to be writtin without a GC in mind but druntime should be compilable with something like a -nogc flag that make it usable without GC.

There are a lot of users out there who think that a GC produces terribly slow programs, big hangs while collecting,... (thank java for that. Right now the java GC has been improved and it's extremely good but the memory stays :p)
Letting them know that D can be run without GC can be a good point. If they don't like it, they can turn it off.

That's got nothing to do with it. People who seriously NEED to be able to use the language without the GC enabled are probably working on small embedded systems with extremely limited resources. It's also possible that various different resource types need to be allocated/located in different places.
Also, In many cases, you need to able to have confidence in strict deterministic allocation patterns. You can't do that with a GC enabled.
I'm all about having a GC in D, obviously, but I certainly couldn't consider the language for universal adoption in many of my projects without the option to control/disable it at times.
If I can't write some small programs with the GC completely disabled, then I basically can't work on microprocessors. It's fair to give up the standard library when working in this environment, but druntine, the fundamental library, probably still needs to work. Infact, I'd personally like it if it was designed in such a way that it never used the GC under any circumstances. No library FORCED on me should restrict my usage of the language in such a way.