All languages have their issues though, and they all make different tradeoffs. After using a number of languages compared to say C#/Java/Scala/Ocaml/etc I don't

All languages have their issues though, and they all make different tradeoffs. After using a number of languages compared to say C#/Java/Scala/Ocaml/etc I don't find F#'s limitations that crippling. In fact I think F# when you look at the swathe of languages with a big enough library ecosystem it makes a lot less tradeoffs than other languages in its class. At least for me it seems to be a good balance between simplicity, conciseness, expressiveness and performance - in some ways it seems nicer to code in and bring teams up in than some other functional languages I've seen. I've seen many teams adopt and then go back to Java from Clojure and Scala for example due to the complexity of the code that arises from people being too smart with the language. The feature you state (F# unions) - that simplification has some positives as well. I can exhaustive pattern match for example. I can always use composition/pattern matching/active patterns to mix in other assemblies types cases. Is it really limiting that it doesn't do this? Would changing this mean more complexity and make other language features harder to deliver? All features introduce some additional complexity, and it more than linear typically. F# also has some interesting patterns that were either introduced first there en masse (e.g Async) or are easier to use there. I'm a fan of static checking, and conciseness with performance close to the platform it is hosted on and is easy to reason about. I'm also a fan of easy to read and clean code that isn't "scary" to look at. F# seems to strike that balance well compared to other JIT functional languages, at least from where I’m sitting. Too much complexity and you start scaring people away and/or too much abstraction in the codebase starts to occur trading off maintainability.