I've generally seen it for embedded systems due to smaller size and you can statically link it.
But there are some compatibility drawbacks for non musl binaries as well as source that intentionally or unintentionally relies on glibc behavior or non standard functionality.
You don't want to mix and match your libc's on a running system.
Buildroot may be a good way to start to play with musl (or uClibc, another small c library).
apt install musl
Binaries that don't use libraries, i.e. complied with "-static" option on GNU/Linux run just fine on musl/Linux (and vice versa).If you like to copy statically linked binaries between musl and glibc systems, some day you will learn about libnss.
"Alpine Linux is good candidate, as Glibc static compilation is broken for political purposes, and Musl Libc allows static compilation."
"The GCC/Linux developer community is sold on shared library executables. They like shared libraries due to the reduced memory and disk footprints, as well as the concept that upgrading one shared library eventually automatically upgrades all applications which use that library. Consequently, information on statically linked programs is rather sparse."
https://web.archive.org/web/20170306062400/http://www.static...
Interestingly there is an sssd package in alpine but it cannot work. https://gitlab.alpinelinux.org/alpine/aports/-/issues/16969
https://github.com/rustadopt/uzers-rs/issues/20 ("Now the bad news: I poked around a bit and believe the problem is that MUSL does not support sideloading the NSS plugins needed to retrieve things from SSSD like GLIBC does and thus does only ever read users from /etc/passwd, see: SSSD/sssd#6586")