It scales, and you don&#x27;t have to use NASA-like process. The article fairly clearly says that making this work is a learned skill. And it is.<p>If course it&#x27;s possible to write stuff using manual memory management in a manner such that it&#x27;s nearly impossible to do well. Doctor, doctor, it hurts when I do that...<p>I wrote a &#x27;C&#x27; based thing around 2012 that:<p>- is about 50,000 lines; 50ish by 1000ish lines. 
- uses no dynamic memory.
- does very &quot;dynamic memory&quot; things.<p>Each type&#x2F;shape&#x2F;class has its own statically allocated &#x27;C&#x27; array of structs that is declared to worst-case, and has a &quot;new&quot;. Behind the &quot;new&quot; is a lot of behavior, including pointing to other such things&#x2F;objects.<p>A set of &quot;delete&quot; operations would be also relatively easy.<p>But because it&#x27;s an array and it is in &#x27;C&#x27;, this is relatively little code. Yes, there is duplication involved but the object creation code is probably 20% of the total thing and each object creation is darn near provably correct.  It&#x27;s built on RAII principles ( perhaps foolishly, since there&#x27;s no deletion ). Dependencies between objects are completely explicit in the code. Object creation must be in the correct order to manage dependencies<p>The magic happens because scripts* are used to create all things, once at startup. it also helps because by its very nature, the system is fully serialized - after a creation script, the state of the tables of objects can be written to a text file.<p>*scripts are, in this case nothing but sequences of verbs which send text files full of XML to a service at a TCP port. It could have been JSON or attribute-value pairs, but instead it&#x27;s XML.<p>I do take extra care to make a very comprehensive test suite or it.<p>but since the allocation scheme is 1) cheap and 2) fully exposed as state in the system, there&#x27;s nothing actually opaque about it. I don&#x27;t have to do &quot;trust falls&quot; with a garbage collector or even the heap. You can&#x27;t have a malloc() or new() failure - it&#x27;ll violate a constraint and quit&#x2F;exit(). You then make the table larger.<p>From the frame of reference of the other objects, it&#x27;s abstracted and opaque - after the initial setup. From the &quot;scripting&quot; interface, it&#x27;s fully transparent.