Why you should use F#
This post was written by Phillip Carter and Mads Torgersen. Both work on languages on the .NET team.
At Build 2017, we presented a tech talk entitled “Why You Should Use F#”. However, not everyone can attend Build, and many attendees were unable to find a position in the room where they could adequately hear us. You can see the talk for yourself in video format if you haven’t seen it already.
In this talk, we cover:
- Adressing thoughts people have about adopting F#
- As Microsoft, we really do embrace F#
- F# is used for big things, including Jet.com, who you saw at the keynote
- The F# Open Source community is incredible and built many features
- Advanced Autocompletion for F#
- Rename refactoring using the same UI and underlying infrastructure as C#
- Type Providers are one of the best features of F#, especially for data wrangling and analysis
- F# is getting features that C# doesn’t even have
- Lots of F# documentation showing ways to learn F#
We recommend watching the talk to see much of the above points in action. If you haven’t tried F# before, there’s no better time than now! Functional programming is on the rise, and now is the best time to start learning. There are multiple ways to get started, written in the official documentation:
Getting Started with Visual Studio
Getting Started with Visual Studio for Mac
Getting Started with Visual Studio Code and Ionide
Getting Started with Command-line Tools
You can also get a thematic overview of F# and its features with the popular Tour of F# document.
Additionally, you can use F# for Azure Functions and Azure Notebooks. It’s fully supported in both services. Go forth and give it a try today!
Finally, F# is also backed by an independent foundation, the F# Software Foundation (FSSF). The FSSF is free to join, has an active community, and has a mentorship program that anyone can take part in. When you join, you get access to the FSSF slack, which has over 1200 members. If you’re interested in F#, feel free to join! It’s free and has no obligations on your part.
Did anyone from the UWP team attend, by chance?
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/9110134-f-support-in-net-native-for-uwp
This is a joke right? There’s no embracement from Microsoft at all. No uwp support, no .net core support in visual studio.
Hey onurg,
Have you been following our monthly announcements for F#? https://github.com/Microsoft/visualfsharp/issues/3069
Though we aren’t the masters of our own destiny for UWP, we are for .NET Core, and the work is very much close to being released. We’ve had .NET Core support in VS planned for the forthcoming Update 3 release for a few months from now, and it will be available in one of the Previews prior to the release. We’ve also moved to in-band for the .NET Core SDK and have support for .NET Core 2.0 and .NET Standard 2.0, and when that is released we’ll be there from day one on all OSes and with VS support.
Just to offer a bit of perspective, it’s only been since March that tooling for .NET Core in VS which was compatible with existing code has been available for people to use in a supported, RTW form. .NET Core is still very new, and you can use F# for it today outside of VS. The VS support will be there quite soon.
Don’t misunderstand, I personally appreciate your hard work. However F# is always treated some after thought language especially when it is about tooling. Such as, in addition to above, no live testing, no dependency validation support.
Or just Go to this page: https://docs.microsoft.com/en-us/dotnet/api/system.console?view=netframework-4.7
In the languages drop down on the right there is C#,VB and C++ but no F#.
Though I can’t speak towards Dependency Validation in the Architecture and Analysis tools (IIRC it’s using Roslyn Semantic Analysis, which means F# can’t take part without a rewrite of the compiler), Live Unit Testing and the new API Browser are all brand-new products that are evolving heavily as we speak. Just as an example, the API Browser’s language dropdown is a no-op for many things. Example: https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient?view=netframework-4.7 (this isn’t an indictment of the docs site, but rather an illustration that there is a lot of remaining work to do there).
You’ll also find that Live Unit Testing can pick up F# projects to build them, and if you’re using Expecto with runTestsInAssembly, they’ll be continuously ran. Instrumentation (the checkboxes/red x’s) will require work on the part of the F# team to support those APIs in our language service. We’re not doing this (yet) because we’ve prioritized other work around .NET Core.
These aren’t necessarily counterexamples, but I’m hoping to frame things in a bit of a different light. I’d like to dispel the notion that F# isn’t embraced. To the contrary, F# is now in a position where it gets significant work from other teams for free by nature of being on top of the “Roslyn Workspaces” infrastructure in Visual Studio, which has never been the case before. It has first-class, RTW-quality support in Azure Functions (with templates, and as one of the main three languages to select in the portal), it’s the only .NET language supported in Azure Notebooks right now, it runs extremely well on Azure, has solid support in Xamarin, has good support in VS for Mac, and very importantly, has a strong OSS community and ecosystem beyond what Microsoft provides (such as the amazing Fable compiler to write F# apps in the browser). We’re also currently working with the docs team to get the FSharp.Core API reference fully supported, in addition to adding F# to that pesky dropbox :).
Perhaps this is worth a blog post of its own, but everyone has different definitions of what “embraced” means. For some, it’s ubiquitous support across all offerings at a high level of quality. For others, it’s full support in only the things they care about/need to use right now. It’s probably impossible to please everyone, but I firmly believe that if you take a step back and look at what you can do with F# today, you’ll find that it’s in the best place it’s ever been. And it’s getting even better.
Just my two cents on top of what Phil has said. F# support in VS (and also across MS) is in a much, much better place than even 18 months ago. It’s not at the level that I want it to be, but it is getting there.
Not to mention no support in the PowerShell Add-Type cmdlet, or the code generation side using tools like xsd.exe.
Code generation is a bit unusual in F# though – tend to use type providers most of the time.
Or just write C# functionally today.
How does F# compare/compete with R language?
Perhaps Microsoft could position F# for similar scenarios as it does R… with SQL Server space.
+1 to Mike (hey, nice name!). I would really like to see an R.NET or R#. Even if F# is the “official” language used. It would also be nice to interface w/ it via C# as well. Or any .NET language, for that matter. You know, the way it was originally supposed to work. 😉
Hey Mike,
Stay tuned for next month’s blog post! Though SQL Server won’t be in it, expect some content that is _very_ aligned with what people use the R language for :).
Phillip, good to hear… Personally I find F# more intuitive than R, as a C# developer.
From my rudimentary R understanding, R has stats calculation library… If F# would get similar set of stats functions, F# would be in better position to compete.
Don’t forget there’s also the R Type Provider. So you can use the standard .NET libraries (Math .NET etc. etc.) and if you still need R stuff, just call it directly from F#.
I’d like to see F# integrated into SQL Server, the you integrated R with SQL Server 2016.
Now, that would be really cool 🙂
*…the way you…
Have you looked at https://github.com/BlueMountainCapital/FSharpRProvider ?
Is F# extended version of C# ?
It’s functional vs. object-oriented. Although you can translate some (a lot) of the principles in F# to C#. At least, I (try to) do. 🙂
Philosophically speaking, it’s a better (ala cheaper and lower TCO) approach to software design. Here is an excellent post that I send people to when discussing this topic (also be sure to subscribe to the blog, too):
http://blog.ploeh.dk/2015/04/13/less-is-more-language-features/
Thanks Mike i will go through link 🙂
Hello Nagaraj,
F# is a functional programming language which runs on .NET. It’s pretty great :). It interoperates well with C# (by being on .NET), and it’s used for lots of things. The most prominent example would be Jet.com, who use F# to power their billion-dollar business.
We have some documentation on F# if you’re interested in learning: https://docs.microsoft.com/en-us/dotnet/fsharp/
There is an extensive language reference, many articles (linked above in the docs) about getting started with your tooling of choice, and more.
thanks cartermp , the link you shared pretty much use full for me 🙂
I tried it and I quite liked it. I don’t use Windows and found the tooling and support patchy so I’ve stopped using it.
Since C++ can be represented as C艹 in Chinese slangs, C# can also be represented as C艹艹. So can F#.
The proper slangs for C# and F# are C井 and F井. C艹艹 only for fun.
C++ is C加加, not C艹. C艹 only for fun as well.
“F# has a higher percentage of code contributed by the community.”
“Microsoft is very committed to the language.”
Erm… Those are nice sentiments, but they don’t quite mesh together. If Microsoft is so committed, shouldn’t they be the contributing a ton?
This was interesting from a technical standpoint. I don’t mind the fact that certain things failed to work, that’s understandable, but two things could’ve made it better: First, the amount of background noise made it sound like they were presenting from a booth at the side of a busy trade show… Maybe that’s precisely what happened, but it was distracting. Second, you can’t just point to Wikipedia and say here’s a page with some “crap” on it? Ha ha! I mean, seriously! Call it “content” or call it “stuff” or “html”, but not “crap” as that cheapens the presentation further.
Sure they weren’t talking about the latest “improvements” by UWP?
After the way Microsoft pushed Silverlight, and then dropped it like a hot potato, I’m skeptical about investing too much into F#. (yeah, I’m still butt-hurt about that.)
To be fair F# has been growing quite nicely for several years with not a great deal of publicity from Microsoft. It’s only going to get better in the future.
When I hear F#, I hear C. We all know why we moved from functional programming to OOP, from C to C++. If the younger fox need a reminder, it’s because functional programming collapsed in large projects, and became un-maintainable. So why are you pushing a functional language again?
C is not FP. Think Haskell, Clojure, LISP, not C.
You are thinking of procedural programming not functional programming.
F# is functional-first language that can use OOP as well as FP when needed, F# compiles to same IL code as C# and underlying Assembly instructions are more functional then OOP so I find what you’re saying a bit bizarre. For large products that involve UI etc where OOP is preferred, it is down to mutable state and method convenience, all easily still done with F# with its .net OOP interoperability. FP Immutability preference is much better for Parallel and Async programming, a consideration not taken into account when there was move from FP to OOP, designed with single core/thread in mind. There is very little C# can do that F# cannot do much better with a lot less code, struct layout attributes and some other low level CLR/compiler target attributes are the only things that might be missing, loop break/continue are missing but I don’t miss them as using recursive functions, (that compile to loops), force and ensure the coder exits the looping cycle correctly. I will presume you have never used F# properly and are therefore trolling, if you had, you wouldn’t be asking.
Any love (support) forthcoming for F# Service Fabric projects & related tooling in VS 2017? Would love to try converting our stream processing engine from C# to F# but alas not currently supported for .Net Core projects in Service Fabric 🙁
Hello MedAnd,
Although the F# team isn’t responsible for authoring templates specific to Service Fabric, this is work we would happily accept as a pull request on our repository: https://github.com/Microsoft/visualfsharp
The ability to use F# code on .NET Core in VS is work that we are currently doing. The latest VS 2017 preview actually has this support already, but there is one outstanding issue preventing it from being a good experience . . . so we haven’t advertised it yet :). We don’t have a timeline for when that project support will ship, but we’re quite close.
As much as I get the arguments that F# has some “cool” features that C# doesn’t have and indeed some types of algorithm can in theory be implemented more efficiently using a functional paradigm rather than an OOP paradigm I’m still having a hard time seeing the argument that someone should switch to F# from C# when C# is a maturer platform, arguably (whatever the presenters may say) has better tool support and they know they can solve 99.99999% of the engineering problems they face using the C# language.
Really the decision seems to be one of taste – if you prefer the functional programming model then I guess F# is for you but for anyone who has invested a significant amount of time to become proficient in OOP it’s a tough sell to switch from C# to F# when C# pretty much does everything you’ll ever really need.
Having made the switch, I would have to be dragged kicking and screaming back to the old (that is, C#) way of doing things.
Mad, why not have overflow room where video is on screen and people could still watch the presentation
#2017