I don't want to disparage any project or guess the motivation but there have been some undercurrents of anti-GPL sentiment at times and anti-complexity. Folks have sort of backed it up by posting some links to things that aren't as you might think. GLIBC in particular looks nothing like how you might imagine it. You can look at strlen in the K&R book and it's beautiful, like a textbook: int strlen(char s[]) { int i; i = 0; while( s[i] != '\0') ++i return i; }

then you look at: https://sourceware.org/git/?p=glibc.git;a=blob;f=string/strl...

and your mind will sort of explode for a bit. The difference is the GLIBC version is dramatically faster; take the comments away and most of us wouldn't even know that's strlen. It's more complex, no question, but it's much faster. GLIBC is full of stuff like that. qsort and memcpy are non-obvious to many folks. It's not complexity for no reason, you'd be challenged to build a better qsort than the one in glibc, it's not easy.

You'd have to use a pretty esoteric platform to get that version. For most platforms you'll have a handle-rolled assembly version that's dramatically faster than that one (the x86_64 one is here[1]).

[1]: https://github.com/bminor/glibc/blob/master/sysdeps/x86_64/s...

This reminds me of a classic blog post:

    http://ridiculousfish.com/blog/posts/old-age-and-treachery.html

All of those old Unix programs aren't fast by being simple and clean on the inside. Old age and treachery...

And this guy also https://news.ycombinator.com/item?id=14543536 (which comes with this: https://www.gnu.org/prep/standards/standards.html#Reading-No...)

It's much simpler and more oriented towards POSIX compatibility than performance.

* musl prioritizes thread safety and static linking over performance * most software is written and optimized against glibc, not musl