F# still has rather crippling limitations imposed on it by its inherited .NET CLR type system (for example F# union types must have their own hierarchy: you can't have an F# union with a POCO from another assembly).
F# skirts-around some of the limitations with just-in-time design-time type generation ( https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/typ... ) though Microsoft pitches it as a "better T4" for F# specifically, I think it's far more powerful.
The way things are looking, C# is set up get some form of higher-kinded-types in the next 3-5 years (hurrah!) - but from what Mads and the design-team have said it seems like they'll be implemented without significant changes to the CLR's type-system - so be prepared for everything to be implemented as glorified structs (and don't expect struct inheritance either...) with excessive amounts of implicit-conversion.
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.
Yeah it's not perfect. I might need to look into another functional language. I find it a good gateway. I can use familiar tooling and lean on C# libraries.
F# skirts-around some of the limitations with just-in-time design-time type generation ( https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/typ... ) though Microsoft pitches it as a "better T4" for F# specifically, I think it's far more powerful.
The way things are looking, C# is set up get some form of higher-kinded-types in the next 3-5 years (hurrah!) - but from what Mads and the design-team have said it seems like they'll be implemented without significant changes to the CLR's type-system - so be prepared for everything to be implemented as glorified structs (and don't expect struct inheritance either...) with excessive amounts of implicit-conversion.