I think part of the problem is that, while the CLR is vastly better than the JVM at supporting languages other than its flagship, I also think that the cost of using languages other than C# or VB.NET is higher than a lot of developers are willing to admit.
We just allowed some F# code into Kiln. On the one hand, it was vastly simpler than the C# code it replaced. On the other hand, we had to rearchitect our solution layout to handle changing the build order, which we in turn had to do so that the F# code could be sanely usable from the C# code and vice-versa, which in turn required writing a lot of call-site boilerplate and type converters (from C# to F# types). Add in that the CLR is simply not as optimized for F# as for C# (or vice-versa, depending on how you want to view things), and it's not exactly a situation where you can simply say, "Well, F# is better than C# at expressing this problem, so let's use it here."
I want to be really clear on this: I don't think these problems are any worse on the CLR than they'd be on the JVM or with native tools (e.g., OCaml calling C or vice-versa). In fact, they're better in many ways: you have the BCL for your primitives, rather than the native C ABI (for native), and you have a VM that is legitimately much less tied to an individual language than the JVM, which makes things like tail-recursive languages a lot simpler. But I think the right way to regard Foo# languages is more-or-less the same as any other language: unless you can write the entire project in Foo#, think hard about whether the cost of interfacing between Foo# and C# is worth it to your project. Most of the time, it isn't.
Also consider that it is hard to hire people to work on your project if you use F#, whereas c# has enough similarities to other languages that it is easy for people to get up to speed. It's too bad, F# is a really great language.
> Also consider that it is hard to hire people to work on your project if you use F#, whereas c# has enough similarities to other languages that it is easy for people to get up to speed.
Also consider that HR departments and some engineers falsely assume that it is hard to hire people to work on your project if you use F#, whereas c# has enough similarities to other languages that it is easy for people to get up to speed.
Do you disagree that C# has similarities to other languages? C# is based on Java, which is somewhat based on C++. Basically anyone who does a CS course learns one of these. In comparison, I don't know any programs that use Haskell, oCaml, scala, or ML (I had a single class in which I had to use ML fora single project). What I mean to say is, functional programming is not widely taught. I don't think this is controversial.
Do you disagree that any person that is reasonably smart and that you'd want to hire could become productive in c# within a few days, given that they've used java or C++ before. This is a super-low risk gamble. I don't think this is controversial.
The only indicator that someone can become productive in F# is that they have experience in one of F#, Lisp, ML, Haskell, etc. I don't think this is controversial.
Hiring people is hard. Maybe you haven't been involved in the process, but you have to interview hundreds of people just to find that one person who is smart, is a culture fit in your company, and has enough self-discipline and a high-enough level of consciousness to go about their work in a pragmatic and intelligent manner.
Now imagine that you are CTO of a new company and you are deciding between c# and f#. If you startup becomes successful, you'll have to quickly ramp up in hiring engineers. If your startup doesn't become successful, you'll quickly have to ramp up in having someone else hire you.
Assuming we are a rational person, that is we are doing a startup in the hopes that it will be successful, then our plans will facilitate the hiring of many engineers.
Fast forward to when we need to hire many engineers. Also, remember you don't have loads of time to spend doing this, because you're the CTO of a startup and you have shit to do. Also, remember it's hard for startups to hire because 1) risk and 2) you aren't google.
Now imagine taking your pool of candidates and reducing it by 99%.
We just allowed some F# code into Kiln. On the one hand, it was vastly simpler than the C# code it replaced. On the other hand, we had to rearchitect our solution layout to handle changing the build order, which we in turn had to do so that the F# code could be sanely usable from the C# code and vice-versa, which in turn required writing a lot of call-site boilerplate and type converters (from C# to F# types). Add in that the CLR is simply not as optimized for F# as for C# (or vice-versa, depending on how you want to view things), and it's not exactly a situation where you can simply say, "Well, F# is better than C# at expressing this problem, so let's use it here."
I want to be really clear on this: I don't think these problems are any worse on the CLR than they'd be on the JVM or with native tools (e.g., OCaml calling C or vice-versa). In fact, they're better in many ways: you have the BCL for your primitives, rather than the native C ABI (for native), and you have a VM that is legitimately much less tied to an individual language than the JVM, which makes things like tail-recursive languages a lot simpler. But I think the right way to regard Foo# languages is more-or-less the same as any other language: unless you can write the entire project in Foo#, think hard about whether the cost of interfacing between Foo# and C# is worth it to your project. Most of the time, it isn't.