A lot of people who don't like musl just prefer not to have the slowest memory allocator on the planet, especially when multiple threads are involved which they

A lot of people who don't like musl just prefer not to have the slowest memory allocator on the planet, especially when multiple threads are involved which they usually are in modern code. I've watched release-optimized builds with musl run orders of magnitude slower than unoptimized builds with mimalloc, and this was on only 20 cores, it wasn't exactly pushing the envelope of big iron scaling. Even after waiting years for its mallocng, which is better, it is still the slowest. It's no longer just that it wasn't a priority, it's inherent fallout from musl's practice of reinventing everything without learning nearly enough about why other implementations were built that way in the first place. With memory allocators there were several legendary implementations to learn from. My pick would be mimalloc because it's not just fast, it's also hardened, which seems relevant in a thread about security. At least once you know this, you can substitute the allocator for your program even if you otherwise use musl. That's common practice when producing static binaries from Rust code. The problem remains that far too many people just use musl without actually benchmarking their program under a real workload to see just how much they've sacrificed in return for, well, what exactly, because it also wasn't hardening.