Compiler scalability. Question inspired by OOM errors seen by Crystal language

[Nicholas Wilson via Digitalmars-d]

On Wednesday, 30 August 2017 at 01:30:30 UTC, Pradeep Gowda wrote:
> I'm referring to this thread about Crystal --  
> https://lobste.rs/s/dyitr0/its_fun_program_crystal_is_it_scalable
>
>> Crystal is strongly typed, but overwhelmingly uses type 
>> inference, rather than explicit types. Because Crystal aims to 
>> be spiritually—and frequently literally—compatible with Ruby, 
>> that’s a problem: to accomplish that, Crystal relies on 
>> sometimes-nullable types with implicit structure and implicit 
>> unions, such that, frequently, the only way to even begin type 
>> inference is to load the entire program’s AST into RAM all at 
>> once and then start your massive type inference pass. What 
>> you’re seeing in this thread is how a “simple” fix to a YAML 
>> parser error reporting hit that problem, causing Crystal to 
>> use a critical amount too much RAM and OOM.
>
> How does D compare in this regard, especially in cases where 
> `auto` storage class specifiers are used liberally throughout 
> the code base?

Auto is not the problem you can easily figure out the return type 
of function that return a primitive type, and aggregates have to 
be specified.

The problem with D is the memory hogging nature of CTFE and the 
sheer number of templates that get instantiated when compiling 
big codebases. Symbol length is also a problem but that eats you 
dose space not your RAM.