Many safety critical systems in Ada ban the usage of dynamic allocation and Unchecked_Deallocation by adding "pragma Restrictions (No_Heap);" and "pragma Restrictions (No_Dependence => Ada.Unchecked_Deallocation);" at the top of the file where the main subprogram is located (application entry). The tradition when these pragma are in effect is to define the entities used in the application in arrays. The sizes of the arrays need not be defined at compile-time but can be determined at application startup (run-time). It means the sizes of the arrays can be specified in configuration files and vary depending on the hardware support the application is installed upon. Just because the entities/objects are located at indexes in an array it doesn't mean that they need to know about it and can point to other objects using access-to-object type variables (references). The problem with dynamic allocations is the risk of memory fragmentation and the performance of the application may "mysteriously" degrade over time. One also runs the risk of running out of heap memory unless the application checks for example there is at least 5% memory left on the device for the heap allocation to be successful.

Also note that one can run into memory leak problems using automatic garbage collected languages. I've personally needed to track down memory leaks in both C# and Javascript applications. Thankfully this rarely happens. It indicates that even when working in an automatic garbage collected language a developer needs to be aware of potential memory issues and think carefully about architecture.

Glad to hear you were successful in the project (with 100s of developers)!