How to drive F# Adoption - Part 4

[21c-HK]

I was just about to reply to issue "How to drive F# Adoption - Part 1" (#798) when I noticed that it disappeared. Same for Part 2 (#803) and Part 3 (#809). Why do issues get deleted?

Edit: Part 1 - 3 are back up again.

Anyway, I know I am late to this discussion, but I find it still very relevant. There is a great presentation on mainstreaming a programming language by the creator of Elm. He seems to be right since Elm has become relatively popular in the web community in a really short time despite being completely different from what web developers are used to (e.g. Haskell-like syntax and semantics, new concurrency abstractions, new architecture). He did that with great tutorials, usable samples and a frictionless out-of-box experience.

I think @dsyme and @swlaschin have summarized the most important issues driving F# adoption. When it comes to mainstreaming F#, I feel that the following areas have the highest impact:

Awareness

Microsoft needs to put their money where their mouth is. F# should not be a second-class .NET language that is always put behind C# and VB in terms of priority, support and resources.

Microsoft and the F# community also need to change their sales pitch.

Not:

"F# is best for niche domains like data science, machine learning, or financial trading, etc."

But:

"F# is better than C# - for everything!".

For small problems. For large problems. For any domain. We need to make clear that F# is better than C# in every aspect as a language (which it is!). And this is why F# does not need as much tooling as C#, because it is simply more expressive and you can solve problems directly without fiddling around with XML or poorly designed imperative OO APIs. This is not about not-being-nice, but about being honest.

Out-of-box-experience

As Scrott Wlaschin said, the out-of-box-experience must be frictionless (single all-you-need install, no show-stopping compiler bugs or tooling bugs, good project system, working samples, and up-to-date tutorials). The F#-community has to take full control of the out-of-box-experience to make this a reality.

We need to force Microsoft to take F# seriously by making its out-of-box-experience better than C# (imagine that for a second). Only when Microsoft think they are about to miss the train on an opportunity, do they put their gigantic resources behind a technology (see iOS -> WinRT | cloud -> Azure | Docker -> Windows Containers on Windows Server | virtual reality headsets -> Holo Lens | Xamarin -> .NET Core). Only if Swift overtook C# in terms of usage, would they recognize that they have been sitting on an underappreciated gold mine.

Guidance

Don Syme makes a great point (as always) about the upstack technologies that drive F# adoption all being home-grown F# projects by the open souce F# community as opposed to .NET projects by Microsoft (where .NET is synonymous with C#). That's because these F# projects take advantage of F# as a language instead of being held back by C#'s shortcomings.

I actually think that F# needs to get away from trying to be just another .NET language that fits into the Microsoft technology stack of much-delayed and frequently dropped technologies that are unusable without amazing tooling (which C# has and even needs because it itself is not expressive enough).

Scrott Wlashin is right (again). Officially discourage legacy Microsoft infrastructure tools for .NET like VS project files, NuGet and MSBuild, which have already sucked before F# had to rely on them. F# has much better alternatives now (Paket, FAKE, but still needs a good F#-only project system). VS Code with ionide seems to have overtaken Visual Studio with VFT in terms of usability and functionality in a very short time(!). I have the feeling that Microsoft is actually holding the F# community back by diverting its limited resources and focus to integrating with existing Microsoft products instead of efficiently developing new and better solutions.

Target Audience

The target audience should not be existing C# programmers. C# programmers will only consider F# to be a serious alternative when Microsoft tells them to. Until then, most programmers that might be interested in F# are programmers that are already interested in functional programming, which might also end up with Swift, Haskell, Scala, Clojure, Rust, Elm, etc if disappointed with the out-of-box experience of F#. Again, the F# upstack technologies can only pull-in developers from other communities when F# has the best upstack technologies in a certain domain.

Portability

F# absolutely needs to run out-of-the-box on the future platforms of .NET that enable cross-platform development to stay relevant: .NET Core, Xamarin platforms and .NET Standard Library 1.0. This is why I think that it is a mistake that Microsoft.FSharp.Core.netcore will require .NET Standard Library 1.5 (#1217) as opposed to .NET Standard Library 1.0, which runs on .NET Core, Xamarin and every other .NET supported platform. There should be a single F# Core version that complies with .NET Standard Library 1.0 instead of having multiple versions for different platforms. Having a single F# Core version will make it much easier to maintain and avoid bugs like the inlining bug with F# 3.1 and PCL profile 259.

I also think that WebAssembly is going to change everything. What if WebAssembly becomes the primary execution target for F# in the future?

[dsyme]

@21c-HK I think something bad is happening to GitHub in the last few hours. Multiple historical pull requests have disappeared from https://github.com/dsyme/visualfsharp/pulls, for example

[21c-HK]

@dsyme Are you sure this is GitHub's fault? I find it curious that #797 and #799 are still there and only #798 (Part 1) is missing. #804 is also still there but #803 (Part 2) is missing. #808 and #810 are still there and only #809 (Part 3) is missing. This looks to me that these issues were deliberately removed.

Edit: Part 1 - 3 are back up again. By the way, does anyone know what happened?

[cartermp]

I have the feeling that Microsoft is actually holding the F# community back by diverting its limited resources and focus to integrating with existing Microsoft products instead of efficiently developing new and better solutions.

What new and better solutions do you have in mind here? For example, Azure is an existing Microsoft product where we could have significant integration with in the form of Fluent F# APIs for new services. I think this could help F# adoption significantly.

The target audience should not be existing C# programmers.

I find myself agreeing with the premise that we shouldn't be trying to cannibalize the C# development pool. I suppose there are plenty of C# developers out there who mesh quite well with the idea of Functional-First programming (as opposed to Object-Oriented-First), but I do think that the biggest bang for our buck in terms of attracting people to F# will be in the form of developers out there who already love functional programming.

This raises a question, though - of that crowd, who is best to attract? I'm not a strong believer that existing Haskell and Scala devs will come rushing to F# the instant it's got full support on .NET Core, for example. Things like the lack of Higher-Kinded Types might feel like a downgrade to people who are used to using them. Would it be an attractor to add more "Type Theory Features" to the language?

I've always seen F# as one of the best (if not the best) "blue collar functional programming language". It's dead simple to write good, clean functional code for solving real-world problems, and that's largely because the unique language features F# has and the tooling you can use are some of the best out there for functional programming (if not the best). How could this aspect of F# be made even more awesome?

Personally, I'm a lover of ad-hoc polymorphism, find F# lacking in this area (even compared to C#!), and would love to see some proposals on how to improve it. But that's just my own opinion - I generally prefer ad-hoc polymorphism to pattern matching (even though I love pattern matching). Is this true for other people? I have no idea. I'm kind of weird in that I love multiple ways to attack a problem - ad-hoc polymorphism and pattern matching - and will use one or the other when it "feels" right.

This is why I think that it is a mistake that Microsoft.FSharp.Core.netcore will require .NET Standard Library 1.5 (#1217) as opposed to .NET Standard Library 1.0, which runs on .NET Core, Xamarin and every other .NET supported platform.

This isn't a strategic decision - it's a point-in-time technical decision. The guidance for any kind of package authoring is to pick the lowest version of the .NET Standard that you can get away with. We're certainly not putting this one in the bag as complete. I'd love to see this get lowered to the lowest .NET Standard version that we can have. This is something we'll look at again - but right now, the top priority for FSharp.Core is getting 100% of the APIs working on .NET Core and bringing it out of alpha.

[21c-HK]

@cartermp

What new and better solutions do you have in mind here?

I was referring to the home-grown F# technologies mentioned earlier. For example:

• Paket instead of NuGet
• FAKE instead of MSBuild
• Suave or WebSharper instead of ASP.NET
• MBrace.Azure instead of some fluent F# wrapper around an OO-API of Azure
• a new F#-only project system instead of VS project systems (which was holding back VFPT), project.json (which was dropped by Microsoft recently) and the new Common Project System (which is C# and VB only, and not open source)

I'm not a strong believer that existing Haskell and Scala devs will come rushing to F# the instant it's got full support on .NET Core, for example. Things like the lack of Higher-Kinded Types might feel like a downgrade to people who are used to using them.

You are right. This is also a worry of mine. Higher-kinded types is probably the only language feature that would have an effect on F# language adoption, because Haskell and Scala programmers think that a language without higher-kinded types cannot be taken seriously.

Personally, I'm a lover of ad-hoc polymorphism, find F# lacking in this area (even compared to C#!), and would love to see some proposals on how to improve it. But that's just my own opinion

How do you find F# lacking in this area? As far as I know, the only feature missing from F# is implementing the same interface multiple times on the same type with different type arguments. This situation was slightly (but not satisfactorily) improved in F# 4.0. I personally find ad-hoc polymorphism overrated. Operator overloading and method overloading have their uses cases, but instead of using interfaces there is usually a better type-based or functional solution (depends on the concrete problem). And member constraints in F# provide extremely powerful and flexible structural ad-hoc polymorphism, if needed, that C# does not even have.

This isn't a strategic decision - it's a point-in-time technical decision.

This is what I find confusing. F# Core today has a version for PCL profile 259. PCL profile 259 will comply with .NET Standard Library 1.0. .NET Core 1.0 will require .NET Standard Library 1.6, which means that projects compliant with .NET Standard Library 1.0 will run on .NET Core 1.0 (because .NET Standard Library 1.6 will be backwards-compatible with .NET Standard Library 1.0). So transitively, F# Core today should be able to run a .NET Core that is compliant with any version of the .NET Standard Library. Could you please elaborate why this does not work?

[cartermp]

• Paket instead of NuGet
• FAKE instead of MSBuild
• Suave or WebSharper instead of ASP.NET
• MBrace.Azure instead of some fluent F# wrapper around an OO-API of Azure
• a new F#-only project system instead of VS project systems (which was holding back VFPT), project.json (which was dropped by Microsoft recently) and the new Common Project System (which is C# and VB only, and not open source)

Why the dichotomy? I want to live in a world where I can pick between a variety of options, not just the handful of tools blessed by some members of the community. Using the web as an example, I'd probably pick Suave if I had the choice because I think combinator-based routing is brilliant for building a web API, but if I had to choose ASP.NET Core in the workplace for whatever reason, I'd be a lot happier if there was some story for F# in place for that rather than having no option at all.

That's the key value proposition here - choice - not being forced down a path away from Microsoft tech.

But I think there's two sides to that coin. We at Microsoft have to do a better job of acknowledging the fact that there are great OSS projects out there, and we can attract people to .NET and .NET languages by highlighting that. Microsoft has been traditionally awful at this, and it's something I'm personally pushing for internally, with some success already (such as suggesting Ionide in our official documentation). It's a matter of keeping momentum for OSS going and trying to snuff out any perpetuation of that nasty NIH syndrome.

How do you find F# lacking in this area?

Long story short, every time I write a pattern match --> dispatch function, I end up missing Clojure protocols. This is purely my own opinion and my own preferred way of doing things. I'm happy to start a discussion elsewhere so as not to bog down this thread with opinionated discussion about potential language features.

So transitively, F# Core today should be able to run a .NET Core that is compliant with any version of the .NET Standard Library. Could you please elaborate why this does not work?

Unfortunately, the interplay between the .NET Standard and various implementations isn't quite baked, so it's kind of confusing. Yes, any of the versions of netstandard1.x run on .NET Core, but we're choosing not to optimize that at this time because we don't have all of FSharp.Core in working order on .NET Core yet. The easiest way to get everything running there is to have access to the most APIs on .NET Core, thus the highest version of netstandard1.x is chosen for now. We want to lower this once we can bring FSharp.Core out of alpha.

[21c-HK]

Edit: Emphasizing that defaults matter and more details why Visual Studio Code with ionide would be a good default development environment.

Why the dichotomy? I want to live in a world where I can pick between a variety of options, not just the handful of tools blessed by some members of the community.
[...]
That's the key value proposition here - choice - not being forced down a path away from Microsoft tech.

I think we have lost context here. My posts in this thread are not about OSS vs. Microsoft. My posts are about what I think would have the most impact in driving F# adoption. One factor was a frictionless out-of-the-box experience that is competitive with or better than C#. Microsoft in the past has not been willing to make this happen for F# (while it seems that F# on .NET Core might be another story). This is why @swlaschin and I suggested that the F# community needs to take full control of the out-of-box experience to achieve this goal.

As Don Syme said earlier:

It's well known that the defaults matter. They really, really matter.

Part of this would be giving new F# developers guidance on how to have the best development experience with F# by making Visual Studio Code with ionide (or Atom with ionide, but Atom is not that great) the default development environment. Here is why:

1. Cross-platform (removing resistance to reach more developers)
2. Leverage (more developers means more improvements)
3. Speed (less dependence on VS means faster improvements)
4. Integration (already integrates the best infrastructure tools available for F#: Paket, FAKE)
5. Familiarity (featuring a pimped up command-line probably appeals to many open source developers)

Compare this page with this one. Which one looks more appealing to open source developers or developers in general? Even Microsoft would benefit from this because Visual Studio Code is still branded with "Visual Studio" and is living proof of the "new Microsoft".

And Don Syme has pointed out how attractive home-grown F# upstack technologies have become. It's not that they compete directly with Microsoft products, but that they stand on their own as really elegant solutions to certain problems. Projects like these are what create the required attention in the open source community to pull-in developers from other functional languages to grow the F# community. The still small F# community has nothing to gain from diverting its limited resources to integrating with existing Microsoft products; unless we do have something to gain from it in which case we do integrate with them (e.g. MBrace <-> Azure, Paket <-> NuGet). On the other hand, F# does have a lot to gain from Microsoft's efforts in bringing .NET to more platforms (e.g. .NET Standard Library, .NET Core, purchase of Xamarin) and making F# run on these platforms. So this is definitely appreciated by the F# community, but at the same time we need to be focused (and selfish) while we are small.

I'm personally pushing for internally, with some success already (such as suggesting Ionide in our official documentation).

Thanks! That's awesome.

[dsyme]

The .. .F# community has nothing to gain from diverting its limited resources to ...;

I generally recommend not taking a single point-of-view on what's worthwhile for a diverse community.

The F# contributor and user base is made up of many different perspectives and interests. For some, indeed many, integration with other .NET technologies, tools and commercial products is key and they are willing to put a lot of time into this. This helps to grow adoption and mindshare, and is part of the bread and butter of life in the software world. So there are definitely people with a lot to gain from putting time into working with standard .NET toolchains. Not everyone, but many.

There is definitely also a growing "F# centric" point of view with matching tools, which is also helping to grow F# adoption and mindshare.

[dsyme]

@cartermp

Long story short, every time I write a pattern match --> dispatch function, I end up missing Clojure protocols. This is purely my own opinion and my own preferred way of doing things. I'm happy to start a discussion elsewhere so as not to bog down this thread with opinionated discussion about potential language features.

Could you write this up in a suggestion on fslang.uservoice.com please? Or send me private email. Or a link.

thanks!

[7sharp9]

I think the point on FSharp.Core targeting .Netstandard one is a really good one, F# should make arrangements to make FSharp.Core hell go away.

[7sharp9]

Personally, I'm a lover of ad-hoc polymorphism, find F# lacking in this area (even compared to C#!), and would love to see some proposals on how to improve it. But that's just my own opinion

Row polymorphism aka duck typed record semantics? That would my my vote. (If I had any left :-) )

[Krzysztof-Cieslak]

VS Code with ionide seems to have overtaken Visual Studio with VFT in terms of usability and functionality

Just no.