Does F# have a future?

Let me share a different point of view. I work with F# on daily basis (yeah, lucky guy, I know :slight_smile:) 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).

10 Likes

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).

Is F# an objectively better “backend scripting & micro-service writing” language than let’s say Java, C#, and Python? In terms of managing your code base (compiler enforced type safety, high-level & abstract code with elegant semantics like pattern matching and computation expressions, etc)-- then yes. But that isn’t the be all end all of choosing a language. It’s also about ecosystem, libraries available, cloud infrastructure, and portability. For example, OCaml has a better module system, but cannot do parallelism. JavaScript is terribly dynamic and mutable, but the library ecosystem is more developed than F#. But success in a stack is really about use case.

That’s my two cents anyway… stacks are just about trade-offs.

3 Likes

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.
Further edit:
I’ve read some more and watched the 2018 Build session, and am reassured about the situation, so sorry to bother you all.

– Mike

2 Likes

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.

If you look at programming in general, functional programming is still a niche approach. Most programming still seems to be C, C++, JavaScript, Java, C#, PHP, Ruby, and Python. Granted, some of those languages sport some functional elements, but I’d consider it a stretch to call any of them functional languages.

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:

  1. Java Scala
  2. Ruby Scala
  3. 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 :wink:

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.

9 Likes

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.

5 Likes

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.

2 Likes

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.

ReasonML did a really smart thing in making their functional language look like JavaScript on the surface but under the hood it’s OCaml https://reasonml.github.io/ but their tooling and ecosystem is not on par with F#

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)
    • reasonml
    • reactjs
    • elm-lang
  • 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
    • Vim
    • 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

1 Like

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.

1 Like

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.

  1. http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end
  2. http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
3 Likes

I started on my path to learning F# because I was looking for a way to write a backend for my elm client app, I just decided to give it a try , and I haven’t turned back since. The language just gets a lot of things right to me, it’s about as practical as you can get in terms of an FP language used for general purpose programming. One thing to note though, is that IMO, the popularity of F# in the future will rest largely on how popular Fable becomes. Javascript is literally everywhere, “Isomorphic” stacks is the new trend (not really new at this point) and the main driver for the popularity of node is the use of one language for the entire stack. FP is hot right now in the JS community, and this is where F# can really shine and show it’s worth, just look at how popular elm is, but guess what? You can’t use elm on the backend, and this is were F# wins.

Safe Stack is cool, but there’s still tons of work to be done in regard to tooling around it, and also the dependency on react needs to be removed. On the backend, .net core is well developed and things keep getting better, but on the client, it’s a different story, I am reasonably experienced with javascript, so using bundlers, module loaders , and setting up various aspects of the toolchain is fine for me, (though i’m not a fan of webpack), but this is not an attractive option for someone new to F# who wants to do full stack development, All of a sudden, for one program to run you have packet.dependencies, package.json, yarn run, fake build, and so on. The whole process should be more seamless and streamlined, the entire scala.js workflow is a part of SBT , gopherjs - everything is built using gopherjs commands, elm has the best tooling there is on the client to me, better than JS itself! If this becomes the story for Fable using fake, and the overall ecosystem around fable continues to grow (more bindings “ts2fable needs more love”, an actual home for fable packages ala package.elm-lang.org ) things could start to spread more. As for me, I’m really happy with F# so far and I definitely plan to contribute to the community as much as time permits , .net core + fable is just to cool for “full stack cross platform functional development” <— ( The current appeal of F# ) not too!

3 Likes

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: dplyr, ggplot2, and data.table. dplyr and 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 dplyr and 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:

  1. 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 data.table and kdb+
  2. 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
  3. 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
  4. 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.

8 Likes

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.

I find that F#ers are pretty pragmatic. This might mistakenly come across as lower energy. And this is compounded by 1) a drastic influx of new programmers who are chasing excitement and enthusiasm and 2) FP presents a barrier to entry in the form of a mental shift, moreso than popular choices like Javascript and PHP.

On that last point, the FP mental-shift track looks like this.

  • Expression syntax
    This was a difficult transition for me personally, having only statement-based language experience. Early on, I was especially confused by if statements, because side effects like printfn and optional unit else clauses still made it appear statement-based.
  • Immutability
    For experienced OO programmers, I call this “automatic defensive copying” to hopefully give them an understanding of its value.
  • Pure functions
    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.

4 Likes

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.

1 Like

As I read through this thread again, after a month or so of playing around with various other up and coming technologies, I can see more clearly where I believe F# is failing, and imo, it is a lack of focus. F# cannot be a “general purpose language” that runs on .net, c# holds that crown. I notice a lot of community effort going into F# on the client, but after using reasonml for the past 3 weeks, it has become quite clear to me that if anyone wants to do functional mlish programming for the client that’s what they’re going to be using , or maybe elm, especially since reason is created by Facebook and tied tightly to react, Fable isn’t offering anything significantly better that I can tell since everything in the safe stack is using react anyhow.

The languages that are thriving these days have all found their niche, dart is rising again because of flutter, Kotlin has Android, Typescript had angular, Go because of the whole devops movement (docker , Kubernetes, etc) , python with machine learning, rust for low level systems stuff, but what is it that F# is going to be known for, there’s nothing viable drawing people in so they HAVE to use it? It’s such a lovely language that CAN be used for just about anything, and because of that, it seems like people who like it try to use it for everything. I don’t see F# having that one “killer app” anytime soon because nobody is building it, not Microsoft, not the community, F# is a piggyback language, it piggybacks off C# libs on the server, react on the client, and in both cases , I guess most people don’t see the use in using it as opposed the languages/frameworks it’s piggy backing off of.

At the end of the day, it all boils down to the question of when is something going to be made with F# that draws people to it? Something they cant get anywhere else? Sad to say it, but Language features alone isn’t good enough for most. Me personally, I’m using reason more on the client, but I still think F# is super slick so I’m sticking to it because there’s nothing better on the backend imo. I just hope to see the Fsharp community grow and continue to thrive in the future, because the language deserves way more attention.

6 Likes

While it’s true that languages can facilitate reasoning about and coding for certain specific problem spaces, requiring a project to pigeonhole a language is just the sort of narrow branding that killed LISP, as has been documented.

Isn’t the answer to your question what specific focus the F# language has, the SAFE stack? I don’t know any other (strongly typed and functional) language that will enable you to develop a full stack web app with a single language. I have been using a mixture of Elm and F#, and found Elm really impressive. Still, being able to use one single functional language like F# for all of your code seems a pretty strong selling point. What keeps amazing me is how relatively unpopular F# still is.

3 Likes

And if there is need to develop mobile apps you can use Fabulous and share your web code with mobile app, so you end up reusing a lot of code.

2 Likes

Elixir has a full web stack. Phoenix for the web application, Ecto for the data layer and if you want to use GraphQL you can throw in Absinthe. I have been using it a little here and there and I love it. You can pair it with Elm and have a very nice stack or use the views that Phoenix provides.

I came to here looking at F# as I’ve been a developer using the MSFT stack for 20+ years and want to move into functional programming more than just dabbling and I’m very interested in SAFE.

At least in my work environments I think I’m more likely to do something with F# in my career than in Elixir. However, the Elixir community is growing very fast.

4 Likes

This was tweeted by Scott Wlaschin and sort of summarizes C#: image
Maybe the killer app is F# and Bolero, especially if it takes less code to create a Blazor app?

2 Likes

Actually, that’s what worries me.

MS has a tradition of creating bad technology and pushing it into companies, forcing them to use while all independent community complains about it, until MS just goes and says that tech is dead and tells everybody to leave it. Just to leave these companies with legacy software to support themselves.

That happened with IE lack of standard, DHTML, MSJVM, J++, asp, Silverlight, and is happening with Reporting Service and Sharepoint.

No wonder companies avoid anything created or pushed by MS. And anything they support makes ppl skeptical.