"there is tremendous value in non-monoculture of libc
implementations, or implementations of any important library
interfaces or language runtimes. Likewise there's tremendous value in
non-monoculture of tooling (compilers, linkers, etc.). Avoiding
monoculture preserves the motivation for consensus-based standards
processes rather than single-party control (see also: Chrome and what
it's done to the web) and the motivation for people writing software
to write to the standards rather than to a particular implementation.
A big part of making that possible is clear delineation of roles
between parts of the toolchain and runtime, with well-defined
interface boundaries. Some folks have told me that I should press LLVM
to make musl the "LLVM libc" instead of whatever Google wants to do,
but that misses the point: there shouldn't be a "LLVM libc", or any
one library implementation that's "first class" for use with LLVM
while others are only "second class"."
> there is tremendous value in non-monoculture of libc implementations
> any one library implementation that's "first class" for use with LLVM while others are only "second class"."
I agree with Zachary here. LLVM's really good at mixing and matching w/target libs IMO (and linkers too, while we're at it). FWIW lld and libc++/abi have been a part of the llvm project for a long time now and BFD ld and libstdc++ are still the defaults for the linux clang driver.
Correct. clang is always going to default to targeting whatever the platform ecosystem is. I don't see linux distros moving away from glibc any time soon.
The notion that a LLVM libc would in some way make other libc's "second class" is completely unfounded. libc++ vs. libstdc++ is proof of this.
Monocultures are easier to control. Control is easier to monetize. People thus seek to create Monocultures so they can make money.
If you think about it, one of the reasons to avoid Monocultures is because it reduces your control, and that's often seen through being price gouged in some way.
Consumers and workers prefer it when it matches what they want to a high enough degree. Too much variation means too many decisions that either do not matter or you have to be careful to get right. That's less of an issue when there's less choice.
The problem is that this requires the group controlling ecosystem to accurately follow the needs of the masses. If what they provide starts mismatching what people want, more and more people begin to be unhappy, and it's very easy for the goals of the public to misalign with the goals of the controlling group over time. Just because people seem to prefer it now doesn't mean they will a decade from now, but a decade of control can cause real problems when trying to make changes. It's very easy to get into a local maxima type situation, where it takes a lot of time and resources to just come to parity with an alternative, much less capitalize on where it can exceed the status quo.
Imagine a situation where Firefox didn't exist. Since all the other major browsers have moved to Webkit (or Webkit forked) engine, what would the cost be in time and effort of highly skilled people to make a browser engine from scratch? I'm not sure any project would succeed, or if it did, it might be a decade in the making.
People like ease of use, but people also really dislike being stuck without a choice. I think people realize this, which is why even though they often vote for convenience with their dollars, they also express a preference that alternatives exist, even if they don't use them, because they recognize both the benefit of having that option as well as the pressure it puts on their preferred choice.
I think if you ask, most iPhone users would say they prefer their current phone. I also think if you asked them if they think they would be better off without Android existing, they would say no, for exactly the reasons above; it makes Apple move forward with advancements, and it provides an alternative if they ever decide they really don't like something Apple is doing.
Loved the third point in Rich's reply:
"there is tremendous value in non-monoculture of libc implementations, or implementations of any important library interfaces or language runtimes. Likewise there's tremendous value in non-monoculture of tooling (compilers, linkers, etc.). Avoiding monoculture preserves the motivation for consensus-based standards processes rather than single-party control (see also: Chrome and what it's done to the web) and the motivation for people writing software to write to the standards rather than to a particular implementation. A big part of making that possible is clear delineation of roles between parts of the toolchain and runtime, with well-defined interface boundaries. Some folks have told me that I should press LLVM to make musl the "LLVM libc" instead of whatever Google wants to do, but that misses the point: there shouldn't be a "LLVM libc", or any one library implementation that's "first class" for use with LLVM while others are only "second class"."