Languages Without Garbage Collection

In GarbageCollection, there is a list of garbage collected languages. It made me think: how many languages are not garbage collected? I'll try to make a list here:

2 parts:

• languages where garbage is never created in the first place (i.e., languages without "malloc()" or any other way of creating new objects on the heap) -- a language without GarbageCreation? -- all memory used is fixed at compile time.
• Languages where garbage can be created, but there is no built-in system for collecting it -- requiring manual garbage collection.

no-new-objects:

• AlgolLanguage
• AssemblyLanguage (?)
• CeeLanguage using the MISRA recommendations for embedded automotive systems
• FortranLanguage
• SlideRule (ha ha, very funny...)

new objects, but no automatic collection:

• AdaLanguage (originally)
• CeeLanguage
• CeePlusPlus (but see GarbageCollectionInCpp)
• CobolLanguage (prior to OO-COBOL)
• ForthLanguage
• ObjectiveCee (but the standard frameworks and runtimes use ReferenceCounting [and optionally GarbageCollection in MacOsx 10.5+ and GnuStep])
• PascalLanguage
• PliLanguage
• ExtendedObjectTcl
• RustLanguage
  • no runtime automatic collection - calls to malloc/free are handled at compile-time

---

It seems that garbage collection is a very common technique, and is maybe even more popular than other kinds of memory management methods.

That's true for languages designed after around 1985. Before then, it was more common for languages to not have automatic garbage collection. Garbage collection was prevalent in "academic languages", (Lisp, Scheme, ML) but tended to be missing in the languages commonly used for commercial software development. The prevalent (mis)conception was that garbage collection was too slow and unpredictable for "real programs". Also RealProgrammers are sure that they can manage memory better than any automated garbage collector, leading to widespread belief that garbage collection is a crutch for unskilled programmers. Thankfully, those attitudes are changing, primarily due to the acceptance of Java in the corporate world.

Lisp wasn't particularly 'academic' in 1985; CLTL1 came out in '84, and it was heading towards ANSI

---

Note that ReferenceCounting is considered to be a form of GarbageCollection.

Seems to me there should actually be more categories of languages, not primary based on memory management but on resource management. Basically you have: 1) Languages that neither support nor offer (semi) automated resourc management (for example C). 2) Languages that have or support fully automated resource management, but just for memory (for example Java). 3) Languages that support semi automated resource management for any resource (for example C++). 4) Languages that support both fully automated resource management (for memory) and semi automated resource management for any other resource (for example cPython).

---

CategoryGarbageCollection