It works, but the memory allocator implementation is way too slower compared to glibc. This especially becomes a performance bottleneck if application does a lot of heap allocation/deallocation.

I think Musl is a better choice when you work on embedded, low-end devices, or statically linked/self-contained applications. For high performance workstation usage, I still prefer glibc.

Saying musl is preferable if speed is important is a bit...loaded. It's not always untrue, but it often is.

As a libc, musl has a much smaller footprint than glibc, so a computer which is short on memory capacity, memory bandwidth, or cache size could absolutely see a performance benefit. The flipside to this is that a lot of the 'bloat' in glibc are performance tricks including lots of architecture specific code.

As others have mentioned, the malloc implementation is less than ideal and can slow down highly threaded & memory intensive applications.

I work on a musl-based embedded distribution for my day-job, and also quite like using it personally for arm boards and my old ThinkPad. I wouldn't really use it for my workstation though.

As far as applications working with musl, it's not uncommon to see glibc-specific code which would need to be patched out of some applications (systemd comes to mind).

It works. Go ahead, try it.

but is this currently the case

sorry, is what the case?

My distro is based on MUSL. I seem to remember finding something that would not build on it but I do not recall what that is. In addition to the thousands of packages I am using, I have compiled hundreds of applications. Compatibility is very high.

Certainly it is clear the “most applications” work with MUSL.

That is, the source code does.

gcompat is when you want to run something that is already a binary that wants to call into Glibc. I try to avoid that so I cannot comment much.

There is the odd time I have had a binary built for Glibc that I could not avoid. For example, bootstrapping .NET or the version of vcpkg that the Ladybird browser uses in its build system. To be honest, in those cases, I just reach for Distrobox and drop into a distro that has Glibc natively, like Arch. Or I might use a RHEL Distrobox for a commercial binary meant to target that distro.

Clearly running a binary without one of the dependencies it was built against is a problem no matter what library you are taking about. But if we are just asking what works on MUSL, I would say almost everything.

Chimera Linux uses musl libc, Void Linux has the option of musl libc, and of course Alpine uses musl libc.

Gcompat is not very effective but most open source software works with minimal patching.

This doesn't answer your question, I'm sorry, but I will say Void is an endlessly fascinating project

musl is very cool and has very specific use cases. workstations are not one of them. you won't be able to install drivers for gpus for example.

Btw, is it possible to chroot into a glibc sub-distro from a musl distro?

I don't recommend it because of the allocator but if you want to switch to musl, start by checking if the distro you will switch to has the software you need. Signal for example does not work. I have to use the flatpak.