F# as a first-class .NET language - future

[denis-dbm-inactive]

This question could be already answered, but I have not found a concrete and direct answer.

What is the future of F#? Does it remain, in long-term, as a first-class a language like C#? Did Microsoft pronounce oficially about the F# future?

I am interested in F# as an option to develop .NET applictions, suggesting it in enterprise scenarios, introducing functional programming for some teams. Do you have examples of companies that are using F# and them having a good experience and performance? I wish hear real experiences, from experienced engineers and developers: this is why I am posting here.

Thanks.

[vzarytovskii]

Converted it to a discussion, rather than an issue.

[Happypig375]

https://fsharp.org/testimonials/

[smoothdeveloper]

as a first-class a language like C#

What, according to you, makes F# not "a first class language like C#"? I think it is important to have an assessment of why it isn't considered as such.

Historically, I've found that "first class language" concept is a moving target, according to specific desires of people learning it coming from C#, expecting a 1 to 1 match in terms of features in the IDE, long time back, I was hearing "no refactoring support", etc.

Historically, even C# had poorer tooling than F# nowadays enjoy and it didn't hinder adoption, so I tend to take those "pet peeves" with a grain of salt as the fundamentals of the language are a sounder base IMO than "tooling du jour", for evolution of codebases.

but I have not found a concrete and direct answer.

https://devblogs.microsoft.com/dotnet/the-net-language-strategy/

We will make F# the best-tooled functional language on the market, by improving the language and tooling experience, removing road blocks for contributions, and addressing pain points to narrow the experience gap with C# and VB. As new language features appear in C#, we will ensure that they also interoperate well with F#. F# will continue to target platforms that are important to its community.

[zyzhu]

Check out the conference agenda
https://focus.dotnetconf.net/agenda
And this thread about industry applications
https://twitter.com/dsymetweets/status/1412811144113410048

[kspeakman]

We have used F# in production about 5 years now. Mainly building cloud-based products on AWS, deploying F#-based SPAs assets to S3, running F# services in linux containers (ECS). In addition to myself (dev for 20 years), there are 2 other developers who had no prior programming experience. They learned on Elm initially, then made the switch to F# -- their syntaxes are quite similar.

The last time I surveyed the getting started material for F# a couple of years ago, it's not that great for my purposes. It is one of the reasons I had folks start on Elm even though we don't use Elm for new products. Most people learning F# will already be familiar with an OO language, and most F# material has this implicit assumption. But my folks had no prior programming jobs. They were committing basic UI code in a month. (MVU-based UI is pretty safe for learners.) Though both would say that first month was like drinking from a firehose. One is now 5 years in, another 2, and they both write back-end as well as front-end code and do routine ops stuff.

Can you write practical code to get real work done and professional products created? Absolutely. Do you have the ecosystem of C#? Yes, the exact same ecosystem since you can use C# libraries. What about tooling and aids like refactoring? We found we don't need as many aids because there's not as much ceremony to get things done. We use/prefer VS 2019, although I've observed online that some prefer VS Code which works on Linux and Mac.

Does it perform as well as C#? Yes, similar code can compile to the same CIL as C#. However, functional code will have you using different data structures than you would in C#, like immutable records/unions/collections, which have different characteristics from their stereotypical C# counterparts. But this has never been an issue for us performance-wise, and has big benefits for maintainability. And there is always the option of writing performance-sensitive code as mutable/imperative in F#, or writing in C# and calling from F#.

My advice when trying F# and functional programming is don't over-complicate it. Don't try to base all your code on category theory elements. Don't try to create Computation Expressions for everything, just use the built-in ones at first. Treat it like a procedural language but with immutability (return new values instead of mutating inputs), discriminated unions, and pattern matching. IMO this is the core of the language that really shines in maintainability and usefulness. Plus it's just simpler to get started that way. Once familiar with these fundamentals, you'll be in a good spot to decide what else to add in the mix. We still don't bother with most of the advanced features such as custom CEs or SRTPs -- just haven't needed them or liked the direction it would take our code.

I can't answer what the future holds. But MS does invest in F# at least in salary of the team, in packaging F# with .NET, and probably other ways I wouldn't know. And even failing that, F# is open source. We'd probably all like MS to promote F# more. (Although "be careful what you wish for".) We're starting to see that with events like the Focus on .NET F# Conf that is happening tomorrow.