Some of us essentially want "C++ done right".... D does is currently the closest thing to this that I am aware of.
On Mon, Dec 12, 2011 at 4:34 AM, Paulo Pinto <pj...@progtools.org> wrote: > Am 11.12.2011 19:18, schrieb Manu: > >> On 11 December 2011 15:15, maarten van damme <maartenvd1...@gmail.com >> <mailto:maartenvd1994@gmail.**com <maartenvd1...@gmail.com>>> wrote: >> >> >> 2011/12/11 Paulo Pinto <pj...@progtools.org >> <mailto:pj...@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. >> > > In my experience programming embedded systems in highly constrained > environments usually means assembly or at most a C compiler using lots > of compiler specific extensions for the target environment. > > I fail to see how D without GC could be a better tool in such enviroments. > > >
