How to drive F# Adoption Part 2

[KevinRansom]

F# is great programming language and yet it is under utilized. I would like to understand what you the enthusiast F# developer believes are the top four things we can do to drive adoption: As a developer I believe they are features, if someone has already suggested your top thing, repeat it in your list anyway. Please keep discussion to a minimum for this exercise. We can discus the results elsewhere, later. I just want to get a feel for everyone people thinks.

In "How to drive adoption part 1" https://github.com/Microsoft/visualfsharp/issues/798

We collected some data here is the summary. Please review the summary and let me know if I missed something you intended to be added.

Please try to rank the 10 items in the order you think will be the most effective in converting curious F# investigators into consistent developers. Please try to rank the 10 items in the order you think are the ones the community can best deal with. When ranking, if you feel some items are not significant just leave them out of the ranking.

I know this seems school maam'ish of me, I apologise, but in order to get to actionable items, we need to figure out what we need to do. Your input is valued, but digressions limit the value of this exercise.

To summarize:

1. More Microsoft Evangelism / Requiring other product groups to make their stuff F# ready
2. Better Tooling (E.g Make Power Tools available for VS, Folders in the project system ...)
3. CoreCLR support
4. Revive FSI ...
5. ASP.NET v.next support (Not sure if this is coreclr or tooling or both)
6. Language Improvements (Various suggestions)
7. Compiler Performance.
8. Better dependency management. 9.. UWA support for creating truly universal apps .... for Windows.8. Improved F# => C# interop ( enables F# libraries to be better consumed from C#)
9. Steffen said we should logically add curly braces .... (I'm guessing that was irony or sarcasm :-) )

[KevinRansom]

My prioritisation: 3, 2, 5, 7, 4 Community best for: 2, 4, 7, 6

[plepilov]

Prioritization: 1, 2, 3, 5, 9, 7 Community best for: 1, 2, 4, 9, 6, 7

Minimum discussion: without MS support F# simply has no future.

[smoothdeveloper]

Prioritization: 1, 2, 3, 8, 9, 7 Community can effectively contribute to: 2, 6, 7, 8

I think 3, 5, 9 and to some extent 2 (when it deals with VS) needs a major shift from MS and are hitting the bottleneck of 1 (F# team is small, other product groups don't have F#ers), internal adoption at MS (hire more F#ers) might help to advance/optimize the core product at a greater pace.

I wish MS would increasingly and consistently allocate resources to reach the same order as resources put on Roslyn/C#/VB/VS.

I'm satisfied with F# but I can't push it at my workplace on major products mostly due to tooling (R# and vanilla VS) and the fact that my colleagues don't want to learn it ("C# good enough/very good", "F# code is hard to read").

[sergey-tihon]

My prioritisation: 1, 2, 7, 4, 8, 5 Community best for: 10, 2, 4, 5 (:wink:)

[ghost]

+ F# Visual studio support for the new revolutionary package projects (DNX) in a way that allows mixed C# / F# solutions.

+ Improved F# interactive with code completion and much, much easier import of dependencies to projects inside current solution into F# interactive.

[mavnn]

For uptake: 1, 9, 7 From experience bring F# into several .net using companies, the gotchas of "missing methods" and implicit FSharp.Core dependencies bit hard

Community: 2, 4 ,6

[eriawan]

My prioritization: 2, 7, 1, 3, 8, 9 Community: 2, 6, 7, 8

[gsobocinski]

My prioritization: 1, 3, 5, 9, 7 Community: 1, 2, 6, 4

[forki]

@KevinRansom As you know I'm absolutely for better tooling. I also maintain projects that provide some tooling and that have been effective in bringing in lots of new F# users from the enterprise.

But I don't think all tooling needs to be done here. VS code, atom and many other projects use the plugin model. And even VS 2015 doesn't install F# by default anymore. As @dsyme already wrote there is the a great chance here to embrace the current situation and put the powertools into the VS box. I mean it would "just" be a tickbox in the VS installer that installs a blessed version of the plugin. I think the github stuff is a sample for a similar approach.

@vasily-kirichenko always says better tooling means we need a much faster compiler. My comment was more in the direction of that we should not waste time by merging PowerTools (and all it's dependenies) to this repo. Instead MS should consider to contribute to PowerTools, FsAutocomplete, FCS ... and do whatever is needed to make the compiler work everywhere and as fast as possible.

[bleis-tift]

@KevinRansom The 9th item should be separated into two items.

.9. UWA support for creating truly universal apps .... for Windows.8. .10. Improved F# => C# interop ( enables F# libraries to be better consumed from C#)

[dsyme]

Here's my ordering based on their effectiveness to drive adoption of the Visual F# : 1, 3, 2, 5, 4, 9, 7, 6

Caveat: This list is from the perspective of driving adoption of Visual F# on Microsoft platforms and the Visual Studio toolchain. For Microsoft Corp that's all that really counts, which is fine. The list is different for Xamarin, or for driving adoption of F# on Linux, or F# as an open source language independent of Microsoft.

Missing is "Better F# documentation for use on Microsoft platforms", especially the booming platforms like Azure, though perhaps it comes under point 1.

Missing also is "better F# support in other editors" including VSCode, Atom, Emacs, .... Not everyone used VS. But I think this area is pretty well covered by the community.

Again, there are other things to add for driving adoption on other platforms and toolchains. But they can be discussed elsewhere.

[eriawan]

@KevinRansom

I propose to amend item number 9 to: "UWP support for creating truly Universal Windows Applications ... for Windows 10"

Because Windows 10 has more broad support for device under Universal apps, including iOT, HoloLens, Xbox, tablet, Windows 10 (mobile). And we shall focus on .NET "Generators" instead of using portable PCL model.

[enricosada]

i think these points are a nice but really difficult to execute. It's the same list ( + coreclr/azure ) as usual It's difficult to fix problems if we as community and ms duplicate the work.

• ms (as visualfsharp team) doesnt have bandwidth to implement all features ( it's not roslyn team, @KevinRansom and others are doing lots of work for 2-3 people ).
• community can contribute, but up to a point. Now we can contribute, but bar is low and slow. and it's fragmented.

This repo is really entangled ( ide, compiler, compiler service, fsi, fsharp core library ), it's not needed to have like that. Roslyn is not in the same repo as corefx for a reason.

Duplicated effort:

• vs ide: visualfsharp vs fsharp power tools
• download and run: visualfsharp vs openfsharp
• compiler: visualfsharp vs openfsharp vs compiler service
• sync between repos ( 3 repos atm )

I think it's better to try to develop with community instead of accept contribution ( patch, features ) only. If that mean split responsability of repositories to have a faster loop ( that mean quality and features ) so be it. Leave ide code code in visualfsharp, but move compiler code in openfsharp repo only. Develop there the compiler service if possible. Move fsharp core to openfsharp, split core library as a simple nuget, so easier to develop, test and publish ( like FSharp.Core nuget now ) Have you visualfsharp team contribute to openfsharp compiler code and compiler service. Use compiler service instead of a duplicated version. Split project system vs language service in visualfsharp, try to merge language service with VFPT and develop there or add extensions point ala roslyn analyzer

My dream list :smile:

[isaacabraham]

1, 2, 3, 9 (Improved F# => C# interop bit), 5, 6, 8, 7, 4

[vasily-kirichenko]

I'm not a C# programmer anymore and I've not communicated with true C# programmers for a while (~3 years), so I have somewhat blurred ideas what they want these days, but still:

Better adoption (among C# programmers, to be clear): 2, 5, 1 (I don't know what CoreCLR and UWA really are, so maybe C# people want them, too)

Community: 2 (to some extent). Yes, I don't think other items from the list could be done by the community.

About tooling. I think the idea of pulling code from VFPT to VFT isn't good, it'd be just a waste of time. Yes, it'd be nice to have single instance of compiler service running in VS process (less memory usage, less CPU load), but this is the only (and minor) benefit.

BTW, this whole adoption problem could be viewed in a different perspective. Let's imagine that:

• the compiler is fast
• CoreCLR, asp.net and other stuff are supported
• VS tooling is on pair with C# ones
• ReSharper fully supports F#
• MS promotes F# as aggressively as C#

Now the question: would C# programmers switch to F#? I doubt. Because why? And because F# is unreadable for a typical "curly-braced" developer. I clearly remember what F# looks like for me several years ago: crazy condensed, unstructured mess (BTW, it's a general opinion that the famous pipe operator is extremely intuitive. No, it is not. I remember how I stared at a pipe chain for the first time and thinking: "what it is? another kind of match or what?"). So, I think the problem is that C-family languages rules the world and any ML language is not welcome.

[eiriktsarpalis]

3, 2, 4, 7, 9, 6

[enricosada]

f# core ( language, compiler, core library ) evolution should be separated from visualfsharp ( vside/tooling/msbuild/wpf/next big thing ). visualfsharp tooling (ide, msbuild) should build on top of f# core.

Like xamarin studio, vs code and all other ide. Like that we can all benefit from features. Msbuild can die ( it will soon ) but compiler will not. There is lot of more tooling now, when f# come out there was no nuget, so FSharp.Core was a special thing. now it's only a library ( ok language v4 require > v4 nuget, that's ok ) and making it special is complicating thing.

An example is roslyn/corefx/coreclr, it's easier to add ide extensions because there is a clean cut.

About c# dev, but lot dont want to use f#, is not c style, it's complicated. Ok c# integration, but better .NET integration. We need .NET, c# not so much

I like fsharp foundation approach to market f# as a standalone language (it is, but openfsharp repo is not), ms is marketing f# as class library for special case, there is no market for that, just use c# and resharper, integration is not worth it

[eiriktsarpalis]

I completely agree with @vasily-kirichenko. The main "problem" with F# is that it is an ML language: things like expression-based code, indentation semantics, currying and implied parentheses are simply too alien for your average C family developer. Even if some might try to learn the language basics, getting to the stage where you are fully convinced that F# is equivalent to C# in expressive power might take some time and commitment.

In other words, I'm not sure that much more can be done to improve F# adoption rates from the C# crowd. My hopes lie with CoreCLR: if it truly succeeds as a cross-platform framework, I anticipate that F# will have an influx of users with non-C# backgrounds (FP users, academics, pythonistas) who have so far been put off by the ugly cross-platform story of .NET (particularly in linux).

[vasily-kirichenko]

In other words, I'm not sure that much more can be done to improve F# adoption rates from the C# crowd. My hopes lie with CoreCLR: if it truly succeeds as a cross-platform framework, I anticipate that F# will have an influx of users with non-C# backgrounds (FP users, academics, pythonistas) who have so far been put off by the ugly cross-platform story of .NET (particularly in linux).

+500 on every word

[mathw]

For the curious, right now, I think 3, 2, 1, 7, 9

I'm also on the "for devs using VS on Windows" track, because IMO if you're developing on Linux to write Linux-hosted web applications (for example) you might as well just write in Haskell. F#'s primary value to me is bringing ML-family ideas into the .NET ecosystem, so I see its relevance as where .NET is already established.

I work in a C# shop, we all have Visual Studio and ReSharper and we write ASP.NET MVC applications and we have to continuously write a load of bloated nonsense boilerplate that F# largely eliminates. I've never succeeded in convincing anybody else to be enthusiastic about F# at my current job, because actually we don't do anything complex enough. The classic niche for F#, as I was told by an interviewer for a job which supposedly involved F# development, was for heavy maths, and they didn't even consider using it for any other part of their application. Since my current job don't do that, I've got no way in through that route, and never could get authorisation to build a prototype pure-F# web application to demonstrate the benefits.

After Christmas I start at another C# shop, this time a Microsoft gold partner. I asked about why they use C#, and the answer boiled down to "because Microsoft say so".

So: evangelism. It needs the tooling to back it up, it needs the project templates, it needs the VS experience to be something impressive, but it needs Microsoft to tell gold partners that F# is here, F# is good, F# can get you this and that and the other. F# can save you typing ridiculous boilerplate. F# will save you money on replacement { keys. F# can help you produce software that has fewer bugs in it. F# can eliminate the unexpected NullReferenceException. C# developers can learn F# in X days. Whatever it takes.

And, actually, mixed-language projects. Because you can't have circular project dependencies, you can't freely mix F# and C# code within a layer of your application architecture. Everything has to be carefully aligned so that no circular dependencies are required. If I could drop an F# module into the middle of a C# project and have VS just cope with it... that'd be awesome. I appreciate that's probably a massive change to the entire build system, but it's terrible anyway so I wouldn't mind! Of course the F# community can't do that themselves.

Community-wise, it's about tooling provision. If Microsoft aren't willing to commit the resources internally then Microsoft-supported open source F# tools are going to have to be the way to go. Eliminate the distinction between the Power Tools and the core tools, bring them all into the open and make regular releases with improvements, including the latest version with VS updates as they come along but primarily relying on out of band updates for active F# developers to get better features as they're ready.

And having said all that, I really should put some time where my mouth is and get involved - but I don't have a suitable environment for this work at home and my employer certainly isn't going to pay me for it if I can't convince them that F# itself is worthwhile, so I'm stuck in a cycle of C# dominance again.

But I'll try, when I get to the new place, because the evangelism can't just come from Microsoft.

[giacomociti]

1 and maybe 3.

[palladin]

My opinion is that successful platforms and Killer apps/libs drive the adoption of languages (Unix/C, Web/javascript, IOS/Objective C, Rails/Ruby). So F# needs a successful platform and a killer app/lib for that platform.

[plepilov]

@palladin Windows is more than successful platform with ~85% of desktop computers running it. But better support of WPF applications (missing in initial list) would greatly increase F# adoption rate on Windows (esp. in enterprise software) because so far WPF apps are what 99.9% of Windows users deal with.

[palladin]

@plepilov You also need breathing space, C# has great tooling for WPF and is already the de facto choice for client Windows/WPF development.

[plepilov]

@palladin Agree. But C# is also de-facto choice for .NET development. Functional full-featured and well supported library for building WPF apps (something like XAML type provider with VS tooling) would be in my opinion the killer library.

[isaacabraham]

@eiriktsarpalis @vasily-kirichenko interesting points. both of you either (a) do not come from C# background, or (b) don't actively work in C# for a number of years.

You're right that the ML-style syntax is alien for a C# developer. But then again I sat in a C# talk recently about proposed features in C# 7 like pattern matching and tuple syntax and there were a lot of confused faces there anyway.

I understood this thread to be really about Visual F# adoption, not F# adoption overall - surely the easiest target (and largest market) in that context is C# developers rather than e.g. Haskell / Scala / Java / Python devs?

[brianary]

⒋FSI: Something like the Android C#Shell app or PowerShell's ISE ⒌ASP.NET: Make trivial, one-file HttpHandlers much simpler; become the obvious choice for micro-services

[khmylov]

Did you guys consider the point that maybe the issue is with the platform (.NET)? I see 2 possible cases.

First, you have some existing long-running project which is already written in C#, so switching to another language does not make much sense for the business (you can argue about potential benefits, but I don't think that the majority of businesses are ready to switch).

Second, you are starting a new project. That's where the things start getting interesting. Of course, it may be different from your perspective, but what I see around here is that the thought "let's start our new product with .NET" is considered more and more crazy every day. You've got Scala, Go, Node, Clojure, etc. for the back-end, you are also probably doing you front-end with some JS flavor, and some projects don't even need a dedicated back-end these days. Of course the platform is not dead yet, but the trend is quite pessimistic IMO, backed by the unclear platform future and all those vNext stories.

So maybe it's not a not increasing adoption rate of F#, it's a decreasing adoption rate of .NET?

[forki]

the thought "let's start our new product with .NET" is considered more and more crazy every day.

That's what I meant in that other thread. People are leaving the platform and that are the people MS should try to win. Not someone who is happy with asp.net, WPF, EF, ... in C#.

[vasily-kirichenko]

@forki interesting point indeed.

[dsyme]

About tooling. I think the idea of pulling code from VFPT to VFT isn't good, it'd be just a waste of time....but this is the only (and minor) benefit.

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

Let's assume 20,000 C# developers try F# every month. I'd estimate only 1% of those install the Visual F# Power Tools. It's reasonable to assume that for most of the C# developers who reject F# the paucity of the tooling is a factor in the decision (and has been for many years). Another reference point is that at every training @tpetricek does he makes everyone install VFPT. Otherwise they wouldn't, and they would think F# has no tooling.

Putting the VFPT feature set into VFT by default would increase Visual F# adoption, I'm 100% sure of that. It would be a major benefit to the F# community as a whole. The efficiency angle is also important, allowing VFT/VFPT to scale to approx 2x the solution size.

[ptrelford]

Very interesting discussion, @khmylov's & @forki's are touching on an important point, context.

For C# devs coming to F#, fewer IDE features may be an issue (I think go to definition between C# and F# is probably the must have thing people crave in mixed solutions nowadays).

For Data Scientists coming to F# with experience of Python or R, looking to add a new tool to their box, perhaps the IDE story is less of a problem, and good documentation, examples, easy data extraction, compute story, etc. may be more important.

For web developers coming from Ruby, PHP or Go, perhaps easy set up on Mac and Linux with good documentation and examples and a simple opinionated web library (I think Suave fits here) could be important.

Overall I think there's a bunch of different contexts where there's different requirements, and perhaps we might also want to ask the question - how can we make F# more attractive for: a) Data Scientists b) Web developers c) Apps and Game developers d) Enterprise developers

2,3 & 7

[forki]

I think nobody is against putting VFPT functionality into VS, but personally I just don't think it should be developed here. And it seems that at least one maintainer of VFPT thinks the same. Again this is not a total blocker since MS found ways to ship github's plugins with the VS installer. There are very high restrictions on github (which lead to strange implementation details), but it might be possible. On Dec 17, 2015 16:57, "Don Syme" notifications@github.com wrote:

About tooling. I think the idea of pulling code from VFPT to VFT isn't good, it'd be just a waste of time....but this is the only (and minor) benefit.

It's well known that the defaults matter https://www.thersa.org/discover/publications-and-articles/rsa-blogs/2013/02/increasing-organ-donation--but-not-the-way-you-think/. They really, really matter.

Let's assume 20,000 C# developers try F# every month. I'd estimate only 1% of those install the Visual F# Power Tools. It's reasonable to assume that for most of the C# developers who reject F# the paucity of the tooling is a factor in the decision (and has been for many years). Another reference point is that at every training @tpetricek https://github.com/tpetricek does he makes everyone install VFPT. Otherwise they wouldn't, and they would think F# has no tooling.

Putting the VFPT feature set into VFT by default would increase Visual F# adoption, I'm 100% sure of that. And the efficiency angle is important, allowing VFT/VFPT to scale to 2x the solution size.

— Reply to this email directly or view it on GitHub https://github.com/Microsoft/visualfsharp/issues/803#issuecomment-165493269 .

[forki]

Maybe the fastest way is to depend on the VFPT nuget package. I mean maybe we can find a way to include it without moving all the code and the build process.

[MichaelGG]

1 is by far the biggest issue, period. If #1 happens, everything else basically sorts itself out.

Unwanted discussion: It's clear MS isn't fully behind F#. Look at, for instance, how Apple markets Swift[1][2]. It makes it unambiguous that Swift is not only a good choice, but that Apple is totally behind Swift: "Swift is ready for your next project — or addition into your current app...". The overall sentiment is very positive and reassuring.

Compare to MS's pages on C# [3] and F# [4]. C# is "general-purpose...for building apps" and allows "rapid application development". But F# is "to solve complex problems" and is suggested for "calculation engines and data-rich analytical services". This has always been MS's main public stance. F#'s for smart people doing complicated science-y things.

Adding to it, anyone remotely familiar with VS or other MS APIs will see F# is left out all over the place. From lack of ASP.NET support, to MS APIs that rely on C#-specific features via reflection instead of proper designs (looking at you MVC).

All this tells companies one thing: "beware". One startup I know of told me point-blank "We're afraid using F# will lower our valuation since it's not really supported." (Perhaps unfounded, but it's that kind of attitude I tend to see, a nervousness.)

Until Microsoft sorts out its internal priorities/politics/whatever and truly makes a stand on F#, adoption is gonna continue to be slow, at least with traditionally .NET/MS users. No opinion on those coming from e.g. Ruby.

1: http://www.apple.com/swift/ (Ignore that Apple put effort into design, just focus on messaging) 2: https://developer.apple.com/swift/ 3: https://msdn.microsoft.com/en-us/vstudio/hh341490 4: https://msdn.microsoft.com/en-us/vstudio/hh388569

[tpetricek]

Just to confirm the suspicion regarding Suave mentioned in Part 3 - I didn't post any comment about it because I think Suave is doing very well and doesn't need any F# core changes that need to be discussed here :). The fact that it exists and works great made me stop worrying about ASP.NET support.

[KevinRansom]

@tpetricek I like suave too, I think that so far it is an enthusiasts tool, and making it more discoverable would be beneficial. So I would think templates, and samples discoverable from within VS might help out:

VS has the new project dialog, not a suave template in sight:

We could ship templates in the box that grab suave from nugget and scaffold a simple web service, a web service that talks to a sql database etc...

I think we agree that people who want to try out F# should be guided to the right solutions, why not use the VS templates to make that happen? or perhaps you disagree ... and it should be obvious to someone who is just trying out the language to go and get Suave! I am interested in your thoughts on this ?

[CumpsD]

My prioritisation: 7, 1, 2, 3, 5 Community best for: 2

[haf]

@kevinransom I think Suave templates is a great way to make more people interested in F#. When I started using Suave it was not due to being an enthusiast, but rather because I was trying to solve a problem.

Besides that, from running a functional programming group, working as architect and CEO who interview prospective F# devs I would say 4 and then 3.

[panesofglass]

1, 3, 4. Don't bother with 5, at least for the next year. My doubts have exponentially increased as work on ASP.NET vNext has progressed.

Community best for (unlisted) documentation and samples. Community could be useful for templates, too, so long as we consider xplat templates.

With respect to templates, I think @Krzysztof-Cieslak's Yeoman template generator is a better solution for us going forward b/c it provides an xplat template solution. Build a Yeoman tooling into the New Project dialog, and you will score major points.

[andredublin]

Prioritization: 1, 2, 4, 3, 9 Community best for: 2, 4, 3, 6, 9, 7, 8

[ovatsus]

Prioritisation: 3,9,5 Community: 4,2,7

[lambdakris]

The 10 items in the order I think will be the most effective in increasing adoption. 2, 3, 4, 8, 6, 7

The 10 items in the order I think the community can best deal with. 2, 3, 4, 8, 7, 6, 1 (nudging, not nagging or judging)

[ctaggart]

I agree with @eiriktsarpalis, that the best way to drive adoption of F# is primarily though xplat support where you can bring in users with non-C# backgrounds. Related to what @enricosada was saying about organization, I think the F# Core Engineering Group should create a process like Rust RFCs process and then be given ownership of the compiler. You can see Scala is doing this and Swift has defined a Swift Evolution Process.

The XPlat success depends on CoreCLR and VisualStudio Code. Type Providers need to work on CoreCLR. Improvements to Type Providers would also really help. I think Ionide is a great start to the XPlat F# story and we should look at ways to improve it (I have been).

[xperiandri]

Roslyn infrastructure integration. Refactorings and analyzers must be available in F#.

[Kurren-N]

My priority: 2 1 3 Community: 2 4 8

[carlpaten]

Would love right-click -> Publish... for Visual Studio 2015. It seems silly to get hung up on this, but creating a new F# project it takes me all of ten seconds to realize I don't have it and consider going back to C#.

[dsyme]

Closing as we have a Part 3 and Part 4 to this discussion.