Hello, folks! Newbie to D, have some questions!

[timmyjose via Digitalmars-d-learn]

On Saturday, 18 February 2017 at 21:58:15 UTC, ketmar wrote:
> timmyjose wrote:
>> Thanks for the very comprehensive response! I think most of my 
>> doubts are cleared now. You're right though that I'm probably 
>> worrying too much about GC with my current use case.
>
> i can tell you that i'm doing things like, for example, ZX 
> Spectrum emulator and hobbyst videogames (everything in D, even 
> low-level gfx), i never really cared about "avoiding GC", and i 
> can maintain solid 35/50/60 FPS (depending of my needs) with my 
> code.
> i.e. that "GC-phobia" (i'm not talking about you specifiallly, 
> of course, sorry) is mostly based on nothing. as GC will never 
> fire "on it's own", and you can control it, avoiding GC is not 
> unnecessary (except some very special cases, of course ;-). the 
> key tech here (as usual) is to not allocate in tight loops, 
> plan your memory discipline and such. nothing new for people 
> used to systems languages. ;-)

No, you're quite right indeed! First of all, those sound like 
very interesting project! :-), and you're right about the GC 
part. I have some experience in systems programming in C++ and 
also application development in Java. Java's GC never really 
bothered me so much, but it's quite intriguing that you (and one 
more person before) mention that the GC does not fire on its own. 
So a couple of questions here (might be a bit premature, but I'm 
interested!):

a). So the GC is part of the runtime even if we specify @nogc

b). Do we manually trigger the GC (like Java's System.gc(), even 
though that's not guaranteed), or does it get triggered 
automatically when we invoke some operations on heap allocated 
data and/or when the data go out of scope?

c). Does Rust have analogues of "new" and "delete", or does it 
use something like smart pointers by default?

> sure, you can stop worrying about that and use D as some kind 
> of scripting language too, and still have all the features like 
> type checking. for things like IRC or email client i absolutely 
> don't care about allocations (i.e. doing it left and right) and 
> just letting GC to do it's work. my usual IRC client uptime is 
> several monthes (after that it runs out of memory, but this is 
> 'cause it never does any cleanup on it's data, keeping all logs 
> and db in memory. i am too lazy to finish it. note that is it 
> not a GC fault, it is my code. ;-).

I could not agree more about the type checking bit. It's bitten 
my backside more than I care to remember (even though LLVM and 
Clang do produce better warnings than gcc IMO), and so a stronger 
type checker is always welcome! :-)

Fascinating reading about the various use cases that you and 
others have put D to. It does give me a lot more contextual 
understanding now. Thank you!