Repository navigation
How to drive F# Adoption Part 2 #803
Description
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:
- More Microsoft Evangelism / Requiring other product groups to make their stuff F# ready
- Better Tooling (E.g Make Power Tools available for VS, Folders in the project system ...)
- CoreCLR support
- Revive FSI ...
- ASP.NET v.next support (Not sure if this is coreclr or tooling or both)
- Language Improvements (Various suggestions)
- Compiler Performance.
- 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#) - Steffen said we should logically add curly braces .... (I'm guessing that was irony or sarcasm :-) )
Activity
KevinRansom commentedon Dec 17, 2015
My prioritisation: 3, 2, 5, 7, 4
Community best for: 2, 4, 7, 6
plepilov commentedon Dec 17, 2015
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 commentedon Dec 17, 2015
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 commentedon Dec 17, 2015
My prioritisation: 1, 2, 7, 4, 8, 5
Community best for: 10, 2, 4, 5 (:wink:)
mavnn commentedon Dec 17, 2015
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 commentedon Dec 17, 2015
My prioritization: 2, 7, 1, 3, 8, 9
Community: 2, 6, 7, 8
gsobocinski commentedon Dec 17, 2015
My prioritization: 1, 3, 5, 9, 7
Community: 1, 2, 6, 4
forki commentedon Dec 17, 2015
@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 commentedon Dec 17, 2015
@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 commentedon Dec 17, 2015
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 commentedon Dec 17, 2015
@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 commentedon Dec 17, 2015
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.
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:
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 commentedon Dec 17, 2015
1, 2, 3, 9 (Improved F# => C# interop bit), 5, 6, 8, 7, 4
vasily-kirichenko commentedon Dec 17, 2015
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:
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.
20 remaining items
tpetricek commentedon Dec 17, 2015
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 commentedon Dec 17, 2015
@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 commentedon Dec 17, 2015
My prioritisation: 7, 1, 2, 3, 5
Community best for: 2
haf commentedon Dec 17, 2015
@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 commentedon Dec 18, 2015
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 commentedon Dec 20, 2015
Prioritization: 1, 2, 4, 3, 9
Community best for: 2, 4, 3, 6, 9, 7, 8
ovatsus commentedon Dec 20, 2015
Prioritisation: 3,9,5
Community: 4,2,7
lambdakris commentedon Dec 20, 2015
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 commentedon Dec 20, 2015
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 commentedon Jan 7, 2016
Roslyn infrastructure integration. Refactorings and analyzers must be available in F#.
Kurren-N commentedon Mar 19, 2016
My priority: 2 1 3
Community: 2 4 8
carlpaten commentedon May 16, 2016
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 commentedon Jul 12, 2016
Closing as we have a Part 3 and Part 4 to this discussion.