Please excuse me for bringing this up, I’m not trolling. I was very excited to find F# as the language speaks to me more than C#, but the more I read about it the larger sense I get that it has been sidelined by the programming community (not MS certainly)? I’ve been interested in Elixir, but Erlang is not in my organization at all, so finding a .Net functional language seemed like the answer. Any reassurance would be most welcome. If this violates the community standard I will be glad to delete.
Perfectly valid question.
Do you have some examples of where you feel that F# is sidelined by FP communities? I can think of a few reasons why some people would write it off:
- Lacking some of the higher-level abstractions that Haskell/Idris/Scala can express
- Being delivered by Microsoft, who are viewed as evil by some people for not entirely unreasonable reasons
- Being traditionally tied to Windows or Mono, with the latter having a bad reputation for quality, and Visual Studio as the only option for editors
However, I think there are numerous people in different FP communities who think F# is great due to:
- Pretty ubiquitous tooling that is very feature-ful
- Supported editor tooling by Microsoft and JetBrains
- Vast .NET libraries to use
- Certain features (Computation Expressions, Type Providers, Units of Measure) which are unique in their bundling which enable things you cannot do as easily in other languages
- Super friendly, “let’s go build practical things” community at conferences and meetups
Though that may just be my own bias leaking a bit
I like F#, I hope I can use it in most of time in my next job in Shanghai China.
The language being from Microsoft sure didn’t help promoting F# in my company as Microsoft technologies are generally viewed as unreliable and unscalable… That’s why I try to emphasis the role of the FSSF and the community at large in the language and the platform. I hope this will work someday!
Also as I already talked about on slack, it seems like there’s a lack of killer open-source apps written in F# that we could point to. Great libraries and frameworks are not enough…
Let me share a different point of view. I work with F# on daily basis (yeah, lucky guy, I know ) and fact, that F# is connected to Microsoft actually helps. For some type of customers, mostly big corporate ones, having strong company like MS behind is must. They do not care about real quality of language - try to sell to management level currying, immutability,… They care about not buying some one-year hipster already-dead technology. And showing them MS got our back just helps.
Anytime Phillip or anyone from Microsoft mentions F# support in VS release notes, this creates message: “we care, not dead for us, do not worry”. And from perspective of CTOs and other people making those decisions, THIS is the most important thing they want to see.
No, not dead. The opposite, I would say. We just need make successes more visible to anyone (I am about to work on it personally).
Can we get a sense of what you’re comparing F# to? For example, could you reword your question to be, “Is there a future for F# in ___ space?” Whether that’s web, ML, IOT, etc. Because I think when discussing futures you have to understand the technologies competing in a space and compare their tradeoffs. A lot of people think Rust is the bees-knees, but I’ve seen later versions of C++ being more appealing in polling Systems Languages on Twitter (anecdotal, but still compelling).
That’s my two cents anyway… stacks are just about trade-offs.
I’m not really in a position to be specific about the areas that F#'s vitality might be in question as I’m just learning it. I am also learning Elixir, and in comparison that community seems more vital (this is totally subjective). That being said I like the syntax of F# a little better than Elixir, I like that I have the .Net framework if I need it. I ask this question because I noticed this messages on reddit indicating that the heyday of F# was in the past; I found that the Try F# website, maintained by MS wouldn’t work in Chrome or Edge (really???), and the gist of the Build sessions seem like they are just trying to remind the MS community that F# is still here like VB.
I’ve read some more and watched the 2018 Build session, and am reassured about the situation, so sorry to bother you all.
As far as I can tell, F# is being sidelined by the larger programming community to the same degree that most other functional programming languages are. It’s hard to get numbers, but for years, I’ve been keeping an eye on various information channels that claim to provide a pulse on programming language popularity. These include sources such as Stack Overflow, Github, TIOBE, and just my general sense of things. Take the following for what it is: informed opinion.
Of the functional programming languages, Swift and Scala seem to be the most popular ones, but for different reasons. I should point out in advance, though, that I can program in neither Swift nor Scala.
Swift is becoming popular because the alternative for iPhone development (Objective C) is generally loathed by all. (See, incidentally, also the interesting article Why your F# evangelism isn’t working; by juxtaposition, it indirectly explains the popularity of Swift.)
Scala is another interesting entry. It’s popular, but it’s difficult to say how many Scala programmers actually use it for functional programming. Being a multi-paradigmatic language, it supports more than one style of programming, and if I understand things correctly, there’s at least three tribes of Scala programmers, each with their own style:
- Java Scala
- Ruby Scala
- Haskell Scala
Historically, this may have something to do with Scala programmers’ original backgrounds. I haven’t seen any qualified guesses at how large each of these sub-communities are, but I hear that they find each others’ styles fairly incomprehensible, so it’s almost as though it was three languages in one.
Beneath Swift and Scala, you typically see a cluster of three or four functional languages that seem fairly close in terms of popularity: F#, Clojure, and Erlang (and Elixir). Of these, F# seems to have an edge on at least Clojure.
Haskell is the de facto gold standard of functional languages, but it’s less popular than the languages I’ve already covered. It’s been around for 25+ years, though.
Then there’s a rising star like Elm, and and a lot of other nascent languages (I’m particularly keeping an eye on Purescript).
Personally, I often choose F# for greenfield development. In my opinion, it’s superior to C#, but it still runs on .NET, which isn’t going to go away in my lifetime (I’m 47, though).
I often recommend F# to other people as well. It’s never going to be as popular as the big languages, but it’ll be around for a long time. It’s officially supported by Microsoft, which often implies decades of support. Besides, you’ll learn functional programming and an ML-style language, and I think that that knowledge will have a long shelf life. It can, for example, be a nice step towards learning Haskell
Ultimately, I believe that functional programming has a bright future, but it’ll be decades before it becomes mainstream, and the functional languages that will eventually become popular will be none of those that are popular today. Those languages may not even exist yet.
This is an excellent view, and one that I mostly share. I’ll add one additional thing w.r.t Scala: size of ecosystem.
Java/JVM is more widespread than .NET. The Google Trends comparison between C# and Java gives a hint as to how much larger Java and the JVM are. This should be taken as a grain of salt, especially when you consider that university students worldwide are learning Java as their introduction to OO programming, whereas very few schools use C#. But I believe that even if you could somehow get a graph that excluded all students, it would be far larger.
Thus, Scala has a larger pool of developers to pick from in terms of getting people interested in FP. Learning a new language and paradigm is challenging already, but having to also learn a new ecosystem can make it feel daunting. And that’s ignoring the reality that an individual programmer is unlikely to change the platform their organization chooses for writing code.
Does that mean the size and growth of F# is necessarily tied to that of .NET? In a way, yes. Which is why it’s good that .NET Core is the future of .NET, and the team is hard at work in ensuring it’s a good next stack for developers to consider. I believe that F# may be able to reach developers who would otherwise never try .NET, but I also feel that number is rather small.
The fact of the matter is that F#, by virtue of being a functional programming language, is a niche as you’ve stated. But it’s an officially supported niche (example: we took a look at a customer’s issue with F# 2.0 earlier this year). And it has a healthy community that feels cohesive and excited to me. That’s crucially important to its future.
Not sure if it has a future or not but it depends on how existing developers react to it. In .NET world C# developers haven’t jumped on to it and are reluctant to adopt it, I have been thinking about why it is so and I think I have an inkling that it might have something to do with them having to unlearn what they have spent their time at universities or courses or a lifetime of learning, it is hard to let go of so much knowledge, it is just the way human nature is. I don’t see existing C# developers to adopt it in large numbers, so the hope of F# getting adopted in large numbers is with students at universities around the world who are willing to learn new things - another thing lacking in current C# developers.
I have tried to tell how good F# is to C# developers and they seem excited but do nothing about learning F#. It is like me telling them about how good the Alphonso mangoes are but I just can’t describe the taste in words, it’s for them to make an effort to taste it and see for themselves or realize what I am talking about.
The next step is for Managers to push F# but they are not bothered as their primary concern is to deliver a working solution on time and excellence is secondary. Other excuse (not reason) that the managers make is the lack of F# developers in job market, and they are not wrong but again it is the existing C# developers I would blame(might be too strong a word), and I have told my managers that if a developer is not willing to learn a new way or working or learning a new language then they should not be hired. The argument with managers does not go too far and never has a good outcome as their primary concern is to deliver a working solution on time.
My 2 cents.
It fails to gain traction in my mind for the same reason most functional languages are maligned, it’s “hard” and by hard I mean unfamiliar, the concepts are dead easy to learn (with a few exceptions) but functional languages often have syntax that is not C like and unfamiliar
Learning a new thing for most programmers is a cost that they’re not willing to pay, and most projects once started last for decades there won’t be a switch mid project.
Most the F# doc sites look like they were designed by people who are 30+, or even worse a 30+ year old idea of modern https://safe-stack.github.io/ though I’d like to clarify I have the upmost respect for people who dedicated their time to make those sites
F# needs to be cool, it needs to be familiar in syntax and in tooling (visual studio code helps massively here)
I would focus on these areas:
- Redesign most doc sites to have a similar structure to the home page of these sites (you’ll quickly notice the structure similarities between them)
- Invest in tooling heavily outside of visual studio, F# should feel usable and accessible in, and these methods should be linked to in docs to make it clear F# is not Visual Studio
- Sublime Text
- Visual Studio Code
Templates need to be more accessible outside of Visual Studio, there should be a site in the design of packagist or NPM where I can browse templates, template discovery is hard
There have been a lot of other very detailed, accurate, and informative posts on this thread already.
I would add that F# is probably one killer app or library away from more widespread adoption. Larger communities and more widespread adoption have both advantages and disadvantages, so be careful what you wish for.
I will say that the governance and community standards being put in place now are setting the stage to make that transition more positive than negative.
There are no guarantees that this will happen and I am not forecasting it. I’m just saying that the ruby and python communities were probably of a similar size and composition before their killer apps arrived.
F# offers so much good stuff while also comparatively easier to learn than Haskell. I came from years of programming in Java, Ruby, Elixir, and now F# is my favorite language (Haskell too I guess).
I highly recommend the following posts if you are still programming in OOP.
I wanted to throw in some thoughts here. I concur with the sentiment that F# is poised to break out but we are needing that killer application which accelerates it into the mainstream. I think this is similar to how Ruby became widespread. Ruby as a language was not that big of a deal until Ruby on Rails happened which solved a difficult problem at the time, rapidly developing web apps. F# needs a similar story to really go mainstream. I think the two most likely candidates are Data Science and EventSourcing/CQRS. I have worked in both of these domains.
People think that Python has the corner on Data Science and in some ways this is true. I think what happened was that Python had the ecosystem to be productive with Data Science early on so it won the initial adoption. As the scale of our problems change I think we will see a migration to other platforms though. The Pandas library is inefficient with it’s memory usage. There is a lot of work going into Pandas2 which will be a massive overhaul. There will be a new computation backend (Arrow I believe) that will have lazy computation and the ability to parse the expression tree and optimize the computation. The whole idea is be able to swap out where the computation is happening (local or remote) so that you can work with massive datasets.
Python also has NumPy which allows you to perform computation on NDArrays at a high level of abstraction. Many Data Science algorithms are expressed in terms of Linear Algebra or Tensors so being able to use NumPy to express these is incredibly valuable.
The other heavy hitter in Data Science is R. In terms of the number of libraries R is light years ahead of F# and somewhat ahead of Python. The most killer libraries (apart from a discipline specific ones) are:
data.table make it incredibly easy to import and analyze tabular data. The
dplyr syntax allows you to write out a series of computations in a powerful, concise, and simple syntax.
data.table has a more difficult syntax but it is incredibly fast. It is significantly faster than both
Pandas. It also has a powerful join syntax which allows for complex overlap joins that nothing outside of the kdb+ database allows for.
data.table is still my go to weapon for complex data analysis.
ggplot2 allows you to create beautiful graphics with ease. I have not come across anything else which allows you to make as beautiful of a plot with as little effort.
For F# to compete with Python and R in the Data Science race I see it needing four things:
- A DataFrame library which…
a) Has zero friction for reading / writing common tabular data storage formats (CSV, Excel, SQL, etc.) I cannot stress how important this is for a practitioner. If the import/export of data has any difficulty no one will want to use it.
b) Has the ability to address massive datasets locally (100+GB) through lazy execution and stream processing
c) Has the ability to swap computation backend from local to a cluster of some kind (Ex: Hadoop, SQL Server)
d) Allows for complex overlap joins which to date I have only seen in R
- A beautiful Plotting library which…
a) Has a syntax which makes simple things simple but complex things possible
b) Has the ability to easily export to various image formats for projection on a screen or publication in a journal
- A NDArray/Tensor library which…
a) Allows someone to express computation in a syntax akin to Linear Algebra
b) Has an expressive syntax for slicing, sub-setting, iterating, and strides
- A more fleshed out set of libraries for statistical analysis
I know this is a crazy high ask but I was wanting to lay out what I thought it would take for F# to surpass Python/R. If we just reach feature parity there is no impetous for someone to switch platforms. These capabilities would make F# best in class and would create a powerful incentive to migrate.
When it comes to Event Sourcing / CQRS F# is awesome. The ability to model your domain with the algebraic type system is incredible. F# has really streamlined the ability to define dozens of different types to accurately model your domain. Combine that with units of measure and you can churn out a ton of high quality code that a Domain Expert could look at and reason about. The group I currently work with built their entire system on F# using an Event Sourcing / CQRS approach. The system is incredibly reliable and handles significant load. The really killer feature is auditability with Event Sourced systems and I think this is often overlooked. Being able to rewind a system to a moment in time is enormously valuable. I think that if more libraries came out for easing the development of Event Sourced systems we would see more adoption.
These are just a few of my thoughts. I would love for F# to become a Data Science powerhouse. I think the potential is there. I think these gaps need to get filled in and then for the community to put out a ton of learning content to help people come on board.
For my team, F# has a bright future. All of our new development is on F#. Even for the front-end, we will likely switch from Elm to Fable/Elmish once Fable 2 stabilizes. There are some minor things I wish for in F# (curried record constructors to support my event sourcing usage), but on the whole I find the choices made very practical, and the F# devs very professional in their interaction with the community.
On that last point, the FP mental-shift track looks like this.
This was a difficult transition for me personally, having only statement-based language experience. Early on, I was especially confused by
ifstatements, because side effects like
printfnand optional unit
elseclauses still made it appear statement-based.
For experienced OO programmers, I call this “automatic defensive copying” to hopefully give them an understanding of its value.
This is the main value to FP, in my opinion… since it leads to refactoring without fear. But it takes some effort to mold your mind into thinking of problems in terms of pure functions. And pushing side effects more to the edge of the program.
But despite the initial cost of this mental shift, I find that the trade-off is that most of my code goes to solving my problem. And very little of it is appeasing ceremonial mechanics. Nowadays, when I look at common OO code, I usually think… “that is way more complicated than it needs to be”. Yet, with F# I can still choose other methodologies (OO, procedural) in cases where it makes sense, such as performance optimizations or integration with other libraries.
Some observations around niche integrations and platforms:
PowerShell’s Add-Type cmdlet allows passing in C# strings to be compiled (VB and JScript used to be supported, too). This seems like something F#'s concise syntax would be particularly well suited to, but alas it is not supported.
F# classes or records seem like a useful output for the venerable xsd.exe SOAP/XSD proxy class tool for those of us working in that enterprise space to interface with ISVs. It looks like support has recently been added for F#.
F# ASPNET/WebAPI VS project templates took a long time to support F#, but thankfully those are available now, too.
There is a suprisingly powerful C# REPL/dev env for Android, C#Shell, which still has no F# counterpart. The Termux Android shell also has no F# (or any .NET Core) support yet. It seems to me that writing F# on a mobile keyboard would be much easier than any C-derived syntax, so I don’t know why there’s still a gap there.