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!
