Why does D rely on a GC?

[Ary Borenszweig via Digitalmars-d]

On 8/19/14, 12:01 PM, Ary Borenszweig wrote:
> On 8/19/14, 11:51 AM, bearophile wrote:
>> Ary Borenszweig:
>>
>>> Then here someone from the team says he can't say a way to improve the
>>> performance by an order of magnitude:
>>>
>>> https://www.mail-archive.com/rust-dev@mozilla.org/msg02856.html
>>>
>>> (but I don't know how true is that)
>>
>> Can't they remove some type inference from the language?
>>
>> Type inference is handy (but I write down all type signatures in
>> Haskell, sometimes even for nested functions) but if it costs so much in
>> compilation time then perhaps isn't it a good idea to remove some type
>> inference from Rust?
>>
>> Bye,
>> bearophile
>
> Crystal has *global* type inference. If you look at the compiler's code
> you will find very few type annotations (mostly for generic types and
> for arguments types restrictions). Compiling the compiler takes 6
> seconds (recompiling it takes 3 seconds).
>
> D also has auto, Nimrod has let, and both compilers are very fast.
>
> I don't think type inference is what makes their compiler slow.
>
> Here are the full stats:
>
> $ time CFG_VERSION=1 CFG_RELEASE=0 rustc -Z time-passes src/librustc/lib.rs
> time: 0.519 s    parsing
> time: 0.026 s    gated feature checking
> time: 0.000 s    crate injection
> time: 0.170 s    configuration 1
> time: 0.083 s    plugin loading
> time: 0.000 s    plugin registration
> time: 1.803 s    expansion
> time: 0.326 s    configuration 2
> time: 0.309 s    maybe building test harness
> time: 0.321 s    prelude injection
> time: 0.363 s    assigning node ids and indexing ast
> time: 0.023 s    checking that all macro invocations are gone
> time: 0.031 s    external crate/lib resolution
> time: 0.046 s    language item collection
> time: 1.250 s    resolution
> time: 0.027 s    lifetime resolution
> time: 0.000 s    looking for entry point
> time: 0.023 s    looking for plugin registrar
> time: 0.063 s    freevar finding
> time: 0.126 s    region resolution
> time: 0.025 s    loop checking
> time: 0.047 s    stability index
> time: 0.126 s    type collecting
> time: 0.050 s    variance inference
> time: 0.265 s    coherence checking
> time: 17.294 s    type checking
> time: 0.044 s    check static items
> time: 0.190 s    const marking
> time: 0.037 s    const checking
> time: 0.378 s    privacy checking
> time: 0.080 s    intrinsic checking
> time: 0.070 s    effect checking
> time: 0.843 s    match checking
> time: 0.184 s    liveness checking
> time: 1.569 s    borrow checking
> time: 0.518 s    kind checking
> time: 0.033 s    reachability checking
> time: 0.204 s    death checking
> time: 0.835 s    lint checking
> time: 0.000 s    resolving dependency formats
> time: 25.645 s    translation
>    time: 1.325 s    llvm function passes
>    time: 0.766 s    llvm module passes
>    time: 40.950 s    codegen passes
> time: 46.521 s    LLVM passes
>    time: 0.607 s    running linker
> time: 3.372 s    linking
>
> real    1m46.062s
> user    1m41.727s
> sys    0m3.333s
>
> So apparently type checking takes a long time, and also generating the
> llvm code. But it seems waaaay too much for what it is.

Also, the list seems way too big. It's ok from a purist point of view, 
to make the compiler nice and clean. But that's not a good way to make a 
fast compiler.

The sad thing is that Mozilla is behind the project, so people are 
really excited about it. Other languages don't have a big corporation 
behind them and have faster compilers (and nicer languages, I think ^_^).