I agree with you, the language design implications are just as interesting / important. What I imagine the problem statement as is to make a definition like th

I agree with you, the language design implications are just as interesting / important. What I imagine the problem statement as is to make a definition like this: // layout.h struct MyRecord { ... } #define N 1024*1024 MyRecord myarray[N]; And then suppose you have 1000 translation units that #include layout.h So whenever you change N, you have to recompile a lot of code. And then you want to compile myprog quickly, and run the following quickly: cat 2gigs.txt | ./myprog It's an interesting problem, but I think from the perspective of an interactive language, it does make sense to have some kind of fast mode and slow mode ... the classic debug/release build split is precisely that. I would settle for an interactive C++/Rust, with a good incremental build system, where you can choose the build variant! C++ build systems suck, and Rust often has to interface with them. And both C++ and Rust are not designed for fast interactive use. They have a lot of syntax that allows the control over memory, and that's perhaps a bigger problem. I also don't really like typing code into a REPL -- I use an editor and a shell (and Ninja, which turns out to be crucial for fast C++ dev).