>>664
まあメモリーの少ない環境で処理のピークとなるようなメモリー確保を行うのは迷惑かもしれんが、現状だって
多くのアロケーターはvec![1, 2, 3]やmake([]int,5)としても断片化させないために2^Nの確保を行うからね。
逆を言えばメモリーの使用量効率が圧倒的に（現在の理論の範囲では）良いのはRust/C++だろうけども使用量が
ピークに耐えうる環境で無ければ、実行できないか例外やパニックになり目的の動作を達成しえないわけで
逐次の動的確保と解放を完全否定するものではないが、アロケータのメモリープールは実装され実証されていて
GCというか確保と解放をプログラミングから切り離す事は正常な発展の道だとも思える

GCであるないの話はお気に入りの特定の言語でそう呼ばれたくない人がいるだけで、それを全員認めて広く世に
一般化がなされても自己満足以外に何か得られるようなものではない