>It’s designed for high-performance, low-memory, safe computing. Meh. If it had been designed for low-memory computing, it wouldn't have had an implicit static

>It’s designed for high-performance, low-memory, safe computing. Meh. If it had been designed for low-memory computing, it wouldn't have had an implicit static global allocator, or a standard library that panics on allocation failures. Currently you have to choose between having no upper bound on your program's memory usage, or using an allocator with an upper bound and accepting that you'll crash on OOM, or giving up on almost the entire third-party crates ecosystem and write with no_std. The upcoming effort to stabilize std::alloc::Allocator and the A in `Vec<T, A>` etc doesn't help, because every piece of third-party code that currently uses `Vec<T>` is implicitly using `Vec<T, GlobalAlloc>`, and using other allocators in your own code will do nothing to change that. Heck, libstd's own std::io::Read::read_to_end requires a `Vec<u8, GlobalAlloc>` Maybe someone in the future will invent some bastard child of Zig's comptime, Zig's explicit allocators and everything else from Rust, and that will be the language to rule them all.