I work on F# for a living, and the total number of contributors to the F# compiler (not counting trivial changes) is a very tiny fraction of a percent of our measurable user count. I imagine that fraction gets smaller for the real user count, since F# is used a lot in finance and other analytical domains where machines tend to be locked down and product telemetry is turned off. I can't comment on figures like 25% or 5-10%. Once the sheer number of users involved is too big to conceptualize (I can only picture about 1 thousand people in my head before it turns into nonsense) numbers like that don't really hold much meaning to me.
The F# compiler codebase is smaller than that of the C# compiler, but only in line count. F# code is massively more compact than C#, which is another way of saying that the concepts are dense too. There are some unique aspects of F# - custom metadata format for things not representable in C# or VB but must be carried over across F# projects, type inference and the massive number of rules for typechecking, a core library acting as a de facto replacement for a subset of the .NET libraries, custom IL reader/writer (this predates System.Reflection.Metadata), and many more - that lead to an enormous concept count that is anything but simple. Luckily, the codebase is quite maintainable and despite countless qualms I personally have with how things are organized, it's proven to be an excellent foundation for continually adding new features over the years.
While I don't get to use it nearly as often as I would like, every time I have it's been really fun to play with/use.
One of the nicest things is that I find is that every time I get to play with it, the language is intuitive enough and IDE support is rich enough that I'm never feeling like I've forgotten how to work with it.
The F# compiler codebase is smaller than that of the C# compiler, but only in line count. F# code is massively more compact than C#, which is another way of saying that the concepts are dense too. There are some unique aspects of F# - custom metadata format for things not representable in C# or VB but must be carried over across F# projects, type inference and the massive number of rules for typechecking, a core library acting as a de facto replacement for a subset of the .NET libraries, custom IL reader/writer (this predates System.Reflection.Metadata), and many more - that lead to an enormous concept count that is anything but simple. Luckily, the codebase is quite maintainable and despite countless qualms I personally have with how things are organized, it's proven to be an excellent foundation for continually adding new features over the years.