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" #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:)

+ 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 😄

[isaacabraham]

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