← Back to context

Comment by ajdude

3 years ago

Coincidentally, Ada optionally supports garbage collection in its specifications but it's up to the runtime to implement it.

And since no implementation has ever supported it, it has been deprecated in ISO Ada 95 and further removed from it on ISO Ada 2012.

https://en.wikibooks.org/wiki/Ada_Programming/Pragmas/Contro...

  • There was this project though.

    https://github.com/Roldak/AGC

    The best part is that it's faster than manual management. People will tell you they need do to malloc and free manually for performance, but when you actually run the numbers GC wins for a majority of use cases.

    • Tracing garbage collectors don’t generally win against reference counting connectors, especially when those reference counts are automatically elided via ARC (eg swift and objective C) or because they’re rarely used by means of composition (c++ and rust). Additionally, different kinds of application strategies are better depending on the use case (eg a pool allocator that you bulk drop at the end of some computation).

      What papers are you referencing showing tracing GCs outperforming things? If it’s just the website, I think it’s an artifact of a micro benchmark rather than something that holds true for non trivial programs.

      44 replies →

  • > and further removed from it on ISO Ada 2012.

    and in that precise moment Ada proved it had garbage collection all along

    • By that measure same applies to C++, as C++20 removed the GC API introduced in C++11.

  • There was an Ada implementation on the Lisp Machine, that might have been using GC.

    • As for .NET and JVM implementations, but that is a consequence of underlying platform, just like C++/CLI and C++/CX, and none of them have been that big into the Ada compiler market.

Which means no library can depend on it, pushing memory management responsibilities into calling code.