> F# explores new language possibilities and the community provides a rich experience across platforms.
There are several interesting observations to be had here. For one, F# already explored (past tense) new language features and has long been essentially feature complete. It gets little features here and there, which are generally quality of life type of things (like anonymous records, for example).
Another interpretation is that F# is just viewed as a .NET/CLR playground and prototype lab to bring features into C#. This is already a common sentiment, but it looks like Microsoft just came out and said it here.
I'll need to read their full strategy, but the blog post is just the same old story: C# is everything, we'll limp along F# with the community doing most of the work, and, oh yea, Visual Basic.
I read through the F# strategy documents, and there's not really anything of substance there. I'm also not sure it's in F#'s best interest to be forced to comply with new C# features (of course F# needs to adopt new .NET features though). F# already does not support several C# features, for good reason, maintaining only what it needs for interoperability purposes. This just furthers the idea that F# is C#'s playtoy.
It's all unfortunate. F# is one of the best designed modern languages around. I wish people would embrace it like Elixir has been embraced. F# could truly be one of the more popular languages and doesn't have to be used at just ".NET shops".
Latest the F# folks tried to pivot the language into data science and be a safer alternative to Python, only to have Microsoft hire Guido and being the company that finally managed to push the CPython devs to focus on performance, and JIT integration.
One is that C# has partial classes but F# does not. This comes up for all the XAML tooling that C# supports but F# doesn't. Also, F# only has null for use in certain situations only for interoperability. There are others that I've seen but don't know off the top of my head. I think they are usually OOP related and at the edges. I don't much know them because I don't really know C#.
I think F# is going to do well because it is driven by the community making it an open field despite being .NET. F# developers seem to have a higher than usual lower-bound.
Elmish.WPF, FParsec, so much there and still things to do...like better development tooling with VS Studio Pro.
If it were a sure thing it wouldn't be a challenge or quite as interesting.
I'm not sure about that given the amount of jobs I have had and found in Elixir, which also has a more vibrant ecosystem. I have strong confidence that I could get another Elixir job. I would be surprised if I could even locate an F# job.
There are several interesting observations to be had here. For one, F# already explored (past tense) new language features and has long been essentially feature complete. It gets little features here and there, which are generally quality of life type of things (like anonymous records, for example).
Another interpretation is that F# is just viewed as a .NET/CLR playground and prototype lab to bring features into C#. This is already a common sentiment, but it looks like Microsoft just came out and said it here.
I'll need to read their full strategy, but the blog post is just the same old story: C# is everything, we'll limp along F# with the community doing most of the work, and, oh yea, Visual Basic.
I read through the F# strategy documents, and there's not really anything of substance there. I'm also not sure it's in F#'s best interest to be forced to comply with new C# features (of course F# needs to adopt new .NET features though). F# already does not support several C# features, for good reason, maintaining only what it needs for interoperability purposes. This just furthers the idea that F# is C#'s playtoy.
It's all unfortunate. F# is one of the best designed modern languages around. I wish people would embrace it like Elixir has been embraced. F# could truly be one of the more popular languages and doesn't have to be used at just ".NET shops".