Kotlin as well as a less radical departure from Java.

Some people would take CLR over JVM, so YMMV

Ok but why? There are a few low-level performance-oriented programs that benefit from struct types (which the JVM now has too) or reified generics. For ordinary day-to-day programming, though, F# is underwhelming by comparison with Scala, and C# is better than Java but not by enough to be worth migrating platforms for. What's the USP of the CLR? When it first came out I thought it was more friendly to foreign languages, but that doesn't seem to have been borne out in practice e.g. Jython felt like it saw way more use than IronPython.

I think one reason jvm has so many more languages is because the need for java substitutes is higher. C# is a pretty good language. And it's hard for better languages to make up for the lack of tooling.

I'm not convinced; C# has some usability improvements over Java (particularly earlier versions) and VS is maybe a bit better than the Java options, but it's not a huge margin. And, I mean, IronPython existed and had an audience. But I suspect Python is a much bigger leap for Windows developers than it is for *nix developers. More than that, third-party languages were never really a big thing on .net - F# and Scala fill very similar niches, but one got the sense that F# was only ever developed by Microsoft Research, whereas Odersky worked on Generics Java and then Scala as a professor not directly affiliated with Sun/Oracle.

I think that today c# and java aren't that far apart. But Scala was created in 2004, c# got lambdas in 2007,and java got them in 2014. So there were a lot of years when the c# java gap was pretty large, which gave Scala lots of time to grow to a critical mass.

I think you're right another factor is that there are more Python and Ruby devs looking to write Python and Ruby on the JVM then the clr.

The most compelling reason I have for choosing CLR and C# over virtually anything else (and ESPECIALLY Clojure and Scala) is availability (and consequently cost) of skilled resources. Availability both today, and 5 or 10 years from today, depending on the project or program.

In my world (Fortune 500) boutique tech carries inherent risk.

This sounds as if skilled Java developers are harder to find that C# developers. Is this indeed so?

For me, Oracle is not as good of a stewart of Java as Microsoft is of .Net.

I wouldn't waste my time converting from a Java infrastructure to a .Net infrastructure and if I were a Linux shop, I probably would stick with Java for awhile, but if I'm already using Windows servers or have my choice today of using Windows only for the backend, I would definitely chose it because of the number of devs and network people available.

I know why you said Java. But I pretty expressly didn't, because BigCorp won't know or care why you said Java. Technical smugness doesn't change the fact that Scala and Clojure are exotic, and that exotic carries risk.

> F# is underwhelming by comparison with Scala

Please elaborate. This is the first I have heard from someone experienced in both F# and Scala to assert this.

I like F# but the lack of higher kinds means F# is mostly just C# with a teaser grammar. It doesn’t really allow for a fundamentally different library envronment.

Disagree as someone who has programmed in both Scala and F#; I found F# pretty much could do the same things just in different ways. In F# I found more ways to squeeze performance than in Scala which by comparison is bloated. For the data applications ive written F# wins usually especially with ad-hoc tactical apps and in my experience was easier to teach than Scala which is not as coherent of a language.

> could do the same just in different ways

Write a function that works with any monad? No?

Write a function that works with any numeric type? No?

You can fake type-classes, but it’s in no way a first class citizen. You can’t easily fake higher kinds.

You may not need those features, it doesn’t make my original statement any less true.

I agree with the first missing feature as you state; I just don't know how much value-add those features actually add in real world apps - often people use them in weird and unintitutive ways as well. F# has other features that other languages don't have as well. I find the workflow syntax eliminates some of the need for the first; and I find I can write functions that work with most numeric types at least a lot more so than C#/Java/etc. As a simple example the in-built F# library comes with functions that work on most number types (e.g SumBy works with anything that supports (+) including my own types). Sure there might be advanced examples that I wish I could do but they don't come often. I do find F# more concise, generally less "smart" and more explicit than Scala code which I think is a good thing. I've seen some funky Scala code in the past. Ease of code/learning/etc, and a maintainable codebase at least for me trumps features most of the time.