Re: why malloc/free instead of GC?

Here are some reasons not to use GC in a new project written in C:

  * It's a very deep requirement which is not provided by the native
system.  The Boehm conservative GC may be very good and portable, but
it's unlikely to be 100% perfect.  And if anything goes wrong with
memory, now you have to suspect this piece of arcane magic in addition
to your own code.

  * There are network effects.  If you're writing a library, you may not
want to require everyone who uses your library to use GC.  If you're
writing an application which uses libraries, you'll have to
memory-manage those libraries' data objects anyway.

  * There's this finalization problem.  Finalizers aren't run on a
guaranteed schedule, so expensive objects like file descriptors can't be
trusted to finalizers.  But if you're not explicitly managing your
memory, you may lose track of when to deconstruct objects containing
expensive resources (e.g. if there is a "file-as-string" type which acts
like a string type, now you have to explicitly manage all strings in
order to explicitly manage your file descriptors).

The first two arguments don't apply to a language like Java with
built-in GC services.  The third argument does, but maybe it doesn't
come up very often in practice.

Of course, even if these are good arguments in opposition to GC, they
don't necessarily have much to do with the reasons programmers tend not
to use GC in the real world.  Most likely they just don't know much
about it.