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.
