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.

[7sharp9]

vscode is pretty good, but lacks a few things like metadata viewer but not much more. I don't use VS or XS at the moment.

[21c-HK]

@dsyme

Could you write this up in a suggestion on fslang.uservoice.com please?

I think what @cartermp wants are interfaces that support retroactive extension of existing types since this is what is special about Clojure's protocols, which dispatch dynamically on the type of the first argument. Swift's protocols also support this through a run-time extension mechanism they call "extensions", which also dispatch dynamically on the signature of the member. Haskell's type classes are also very similar, but dispatch statically on the type of multiple parameters and the return type, which is even better.

There are already feature requests on fslang.uservoice.com very similiar to this:

• Allow extension interfaces (89 votes)
• Support for type classes or implicits (347)

pattern match --> dispatch function

I am not sure what exactly the requested feature has to do with pattern matching. Could you elaborate?

[7sharp9]

The big question everyone is thinking is who is the secret identity of @21c-HK :-)

[bryanedds]

Clojure protocols are the best! Unfortunately, I don't think they can be statically typed :(

[cloudRoutine]

@21c-HK

a new F#-only project system instead of VS project systems (which was holding back VFPT),

While I would certainly love a new project configuration file format (preferably TOML based), as a maintainer of VFPT I'm not sure what you're referring to being held back.

VS Code with ionide seems to have overtaken Visual Studio with VFT in terms of usability and functionality in a very short time(!)

As one of the Ionide maintainers I'm sorry to say this really isn't the case (although it is the long term goal). Features for managing your projects and solutions is sorely lacking and a huge headache for us and our users, the startup time of completions can be fairly finicky, it requires a fair amount of perquisite installations due to upstream dependencies, the REPL support is read-only, the build integrations with FAKE require a fair amount of setup which isn't great for someone totally new to F# and .Net, we're forced to rely on regex based language parsing so the syntax highlighting is nowhere near as good, we don't have any record stub or interface method scaffolding, no scope based outlining, and the list goes on.

Quite frankly Visual Studio + VFPT or Xamarin is (at the moment) the best starting experience for a new F# developer. When Ionide reaches a better level of feature parity with them it'd be great to have a page on MSDN too about getting started with F# in vscode, but I don't think we're there yet.

And even then it won't always be the best tool for the job, there are some projects and tasks where I use vscode + ionide and others where I prefer VS + VFPT, it's about using the right tool for the job while weighing the requisite trade-offs. I think the important thing is to make it easier for new users to see what those options are and when they might use them while making the experience as frictionless as possible for ALL of them. Which isn't an easy task and there aren't a lot of people working on it, but I think about where we were a year ago in terms of F# tooling and we've definitely come a long way.

[21c-HK]

@cloudRoutine

as a maintainer of VFPT I'm not sure what you're referring to being held back.

The Folder Organization page of VFPT says the following:

This feature is disabled by default. Because there are known issues with F# Project System in Visual F# Tools, folder organization may not work 100% correctly in all cases.

• We do not advice you to introduce complicated folder structure within F# projects.
• You should keep number of folders within your project as low as possible.

I have used this feature and had me scratching my head for a while because the VS project view sometimes did not match what was being written to the F# project file. I find folder support to be an essential feature for non-trivial projects.

we're forced to rely on regex based language parsing

Is this because it needs to be compiled to JS? Does that prevent you from using FParsec for parsing?

[cloudRoutine]

@21c-HK those Folder organization issues are also related to dealing with internal VS APIs for solution and project management, so I wouldn't blame the msbuild xml configuration format for all of it.

Is this because it needs to be compiled to JS? Does that prevent you from using FParsec for parsing?

It's because of how the editor extension API is designed and right now we're forced to use the old textmate approach. If it let us apply CSS tags to spans in the editor pane and define a CSS style for syntax highlighting we could use the same approach as VFPT by connecting VFPT.Core to FSAC and using it's lexer, but at the moment we can't. We wouldn't use FParsec.

[7sharp9]

Folder support in XS is also slightly buggy on the edge cases, file ordering seems to be a sticking point on tooling.

[21c-HK]

There are obviously different opinions on what is currently the best development environment for F#. Could we gather a few opinions on what your ideal F# development environment would need to feature? I'll start with my wish list:

• editor with basic support for F# (auto-completion, tooltips for inferred types, solution-wide renaming, indentation guides, auto-indentation, auto-bracket-completion, syntax highlighting, real-time error highlighting, search/replace with highlighting of current matches)
• navigation (tabs for open documents, find references, go to definition, go do identifier, visual map of current document)
• REPL (with same features as editor and ability to generate references and opens for selected project)
• integration with essential tools like future F#-project system, Paket, FAKE, Git, FsCheck, FsUnit and FSharpLint
• integrated command-line to invoke external command-line tools
• folder support
• open source
• cross-platform
• code generation (snippet expansion, pattern matching stubs for unions and records, interface implementation stubs, suggesting to open modules for unqualified types)
• project scaffolding
• collapsable document structure
• markdown preview (with support for rendering markdown in code comments)
• debugging (maybe even for REPL)
• support for Xamarin

So basically the best of Ionide, Visual F# Power Tools and Visual Studio ;-). And of course, all of these features need to be so fast as to not slow down my typing or train of thought ;-).

Have I forgot anything? Is something missing that you find essential?

@cloudRoutine and other IDE extension maintainers: Are there technical limitations in Visual Studio Code, Visual Studio or Atom that prevent the implementation of any of these features?

[cloudRoutine]

@21c-HK There are different limitations for Atom and vscode and we've already planned to implement all of your list that's possible at the moment. As the vscode and atom extension APIs evolve and expand we'll fill in the remaining gaps.

These kinds of comments/suggestions are better directed at the individual tooling project repos as that's where most of these features will be implemented.

[7sharp9]

The limitations are mainly people spending there time doing the work. aka oss

[7sharp9]

I don't see Microsofts limited investment as a problem as long as community contributions are not held up due to bottlenecks in merging pull requests. I mean there hasn't been much change in the 6 or so years I have been involved, I don't see this changing anytime soon.

[HoraceGonzalez]

Linux support is the linchpin, IMO. Porting the existing community ecosystem to .NET Core (ie. Paket, Fake, Suave, etc...) is even more critical to adoption than the language itself.

[7sharp9]

With MS dragging their feet on a full viable release of dnc and ultraslow uptake within F# I reckon come back in 2017 to check progress.

[HoraceGonzalez]

Yes. I'm optimistic that some of the beta/ctp/rc dust will settle after the 1.1 release this fall, especially since project.json will be retired.

[gulshan]

Lots of issues being discussed here. I think there should be separate issues for discussion. And this or a new issue tracking them.

[21c-HK]

I've been influenced by Rich Hickey's "Simple Made Easy" presentation (I'm sure most will be familiar with it.) After taking some time to learn React & Angular 2, I think I've reached my bullshit threshold and I'm not willing to take it anymore.

Clojure got a large usage uptick due to how Rich Hickey managed to verbalise many contemporary concerns in software development.

Since he was mentioned here twice and since he also had a huge influence on me:
Rich Hickey's talks should be required watching if your bullshit threshold is (too) high. Even though he is clearly a strong advocate of dynamic typing - which is a source of lots of bullshit - (ironically) his views/ideas are even more true/valuable in the context of the kind of static typing and type inference that F#, Haskell and ML-derived languages offer. Rich Hickey's greatest talent is telling mainstream developers what they don't necessarily want to hear without offending them - unlike me 😉.

I disagree with his opinions on dynamic vs. static typing, but he is clearly a genius and an amazing communicator, whose influence on developers in pain is invaluable - only surpassed by @dsyme since we still need a language that implements all those great ideas 😁.

[THeK3nger]

After reading tons of comments in this thread, probably I can contribute to the discussion highlighting my first steps into F#.

I am not a .NET developer, but I code in C# often in Unity3D and I am very into functional programming. Therefore, as you can imagine F# is a natural attraction. However, my main point of conflict with F# is in the build system. I find it confusing and "unnecessarily" complex. I can feel Visual Studio leaking everywhere in my command line experience and I not comfortable with this.

I know that this is mostly because of my inexperience and the need for Visual Studio compatibility (and, probably, because of my OCD), but I'd really like to have a more straightforward build tool, such as cargo from Rust, or hex from Elixir, or the Go one, or... well you got the point.

[21c-HK]

@THeK3nger Thank you for sharing your first-hand experience of getting started with F# as a non-.NET developer and confirming that the build-system is one of the first major issues encountered.

[GiorgioG]

@cartermp How do we convince/persuade Microsoft to put more resources on the F# team? As a C# .NET dev, I'm giving up (yet again) on learning/using F# because the developer story is non-existant for .NET Core / MSBuild 15 / VS2017...at least through Q3 of this year realistically and by then C# 8.0 will probably be in alpha/beta ;)

Moving the adoption needle is a pipe-dream at this pace of development. Despite the fact that Microsoft has committed to open source, the open source community has not embraced the F# projects in meaningful numbers to support the level of effort required to keep F# development at anything beyond a snail's pace. This is not a dig at the herculean efforts that are being made by those in the community and at Microsoft. The team is obviously understaffed.

What kind of confidence will potential adopters have considering Microsoft treats F# like a red-headed stepchild?

Let's consider the number of contributors on various open source language projects on github:

F# (this repo): 87
Scala: 314
Elixir: 535
Haskell Compiler (ghc/ghc): 350
Erlang: 394
Roslyn: 209
Clojure: 125
golang: 779

The momentum is not in F#'s favor and the actions that Microsoft have taken seems to indicate it has little interest in F# being anything more than a niche language, and a playground for future C# features.

[Krzysztof-Cieslak]

because the developer story is non-existant for .NET Core / MSBuild 15

I know pretty good way of developing F# using those.

[GiorgioG]

@Krzysztof-Cieslak VS Code is a nice lightweight editor, but it's not Visual Studio.

"Visual Studio Code is a streamlined code editor with support for development operations like debugging, task running and version control. It aims to provide just the tools a developer needs for a quick code-build-debug cycle and leaves more complex workflows to fuller featured IDEs."

[Krzysztof-Cieslak]

but it's not Visual Studio

That's the biggest advantage.

[GiorgioG]

but it's not Visual Studio

That's the biggest advantage.

You're obviously entitled to your opinion...even if you're wrong ;)

[21c-HK]

Disclosure: I haven't actually used F# 4.1 yet. I also haven't tried VS 2017 (yet, or may never).

This comment is not supposed to be fuel for one side in the discussion on F# with VS 2017 vs. VS code and other IDEs, but the information presented in #2400 (“2017 Status and Roadmap for F# and the Visual F# Tools”), #1096 (“F# Support in .NET Native and UWP”) and Announcing F# 4.1 and the Visual F# Tools for Visual Studio 2017 with regards to missing MSBuild 15 support for F# in VS 2017, limited support for .NET's cross-platform efforts (.NET Core, .NET Standard) with F# in VS 2017 and no native support for Microsoft's future platform (Windows Store / UWP via .NET Native) with F# is a “little” (read as: very) discouraging. Especially since AOT compilation via .NET Native and .NET CoreRT could make F# even more attractive since you could (in theory) target iOS and other native-only platforms without having to use Xamarin.

Here are a few comments from #2400 that summarize my concern pretty well:

This roadmap makes it appear that, for my purposes, VS 2017 RTM is really more of an alpha release for F# support, at least wrt .NET Core.

PackageReferences work with command line tools and ionide - just not in VS
yet.

F# will be using CPS in Visual Studio and adopt the new MSBuild PackageReference and other goodies. I highly recommend using the CLI and VSCode to experiment with it today.

So, F# ended up being a second-class citizen in VS 2017 / .NET Core again (in addition to not being installed by default in VS 2017). I guess the real issue is the following, which has already been mentioned:

How do we convince/persuade Microsoft to put more resources on the F# team? As a C# .NET dev, I'm giving up (yet again) on learning/using F# because the developer story is non-existant for .NET Core / MSBuild 15 / VS2017...at least through Q3 of this year realistically [...]. This is not a dig at the herculean efforts that are being made by those in the community and at Microsoft. The team is obviously understaffed.

It's pretty insane how much work the little F# team is doing (and supposed to be doing). The F# team is definitely understaffed (in relative and especially in absolute terms). I don't who would be the right person to address this (@dsyme?, @cartermp?), but please consider hiring some/most/all of the people mentioned at the end of Announcing F# 4.1 and the Visual F# Tools for Visual Studio 2017 to expand the F# team. These could even be remote positions since this is how they made their contributions so far anyway. I know that at least one of them works full-time for a company that does not appear to even use F# to develop their products, yet this person somehow manages to make huge contributions here and to other major open source F# projects. Imagine how much these people could accomplish for the F# ecosystem if they were paid to work full-time on it (including VS and open-source projects).

And as long as the F# team is understaffed, F# releases should not be tied to release cycles of VS and other Microsoft efforts, otherwise the F# releases may be rushed and put off developers for good who were genuinely interested in using F#, but disappointed in the current support in VS. Incidentally, this is the way it was done before and it seems to have worked better.

I know pretty good way of developing F# using [.NET Core / MSBuild 15].

@Krzysztof-Cieslak Please do share.

[GiorgioG]

...limited support for .NET's cross-platform efforts (.NET Core, .NET Standard) with F# in VS 2017 and no native support for Microsoft's future platform (Windows Store / UWP via .NET Native) with F# is a “little” (read as: very) discouraging.

This.

These could even be remote positions since this is how they made their contributions so far anyway.

I don't think it's a matter of finding people who are capable of working on the platform so much as it is Microsoft's unwillingness to spend additional resources ($, time, etc) because it sees F# as second-class citizen (or just a niche language.)

There seems to be little point in trying to discuss improving the adoption rate until Microsoft takes F# seriously. "Microsoft does take F# very seriously" someone will say. If MS's budget F# can't handle adding enough staff to keep up with the rest of the .NET stack/toolchain, then it doesn't take F# very seriously - despite lip service to the contrary.

[cartermp]

Something to note about .NET Core:

It's changing. Tremendously. .NET Core 1.0/1.1 and .NET Standard 1.x is unsuitable for the vast majority of code in the world, and the number one feedback the .NET team was given was to revert the breaking API changes they did and add as many APIs back as possible to .NET Core. What this means in practical terms is that there will likely be a split in .NET Core much like the initial split in .NET Framework: 1.0 vs 2.0.

F# was fundamentally crippled by .NET Core 1.0 due to these breaking API changes. We're stakeholders, in addition to the millions of .NET developers who cannot adopt .NET Core, in making sure that .NET Core 2.0+ accomplishes the goals of cross-platform without sacrificing existing code. I suppose adding 10 new developers to rewrite the F# compiler, Type Providers, and FSharp.Core to account for this would be one way to make it all work fully on .NET Core 1.0, but no reasonable business would do this when it's clear that the platform in the current state has too many problems for people to adopt. Hence, .NET Core 2.0 is where it's all at. It's the clear future platform for .NET.

From a tooling standpoint, one thing to point out is that the C#-only tools for .NET Core in Visual Studio also suffer from numerous bugs and issues due to the (some may say rushed) switch from project.json to the new MSBuild. We had MSBuild, .NET Core SDK, .NET CLI, and Visual Studio work all still in-progress and starting to come together right at the last minute. We could have either taken part in that, or directed our efforts to rebuilding our crippled infrastructure to allow our prolific open source contributors to add value and get their bits into VS. We chose the latter, which has resulted in a ~24 hour turnaround time from when a feature is checked in to when it is available in Visual Studio. This nightly process makes our cadence for pushing features out faster than any other component in Visual Studio, and more importantly, it allows us to rapidly and easily just do some more validation on a build and ship it in an official update to VS. We're already scheduled for on such update in roughly a month's time. The work to get into that was very minimal on our end because we (and so many people in the F# community) have effectively been running on those bits for the past 1.5 months.

In terms of VS support for .NET Core projects, it's already been underway for a while, and you can see the progress right now. The initial support has already been checked in. This work is scheduled for the 3rd update for VS 2017, which timing-wise is equivalent to the old "Update 1" timeframe. Considering that this and .NET Core 2.0 support for the tools (yup, .NET Core 2.0 is different from .NET Core 1.0 and requires quite a few tooling changes again) are the two big areas for that team, I think it's safe to say that F# is not a second-class citizen here.

[GiorgioG]

@cartermp if F# is no second class citizen, where are the ASP.NET Core project templates in Vs2017? ASP.NET Core is supported by the full .NET framework. So Microsoft's official position on this is that .NET Core isn't ready for prime time in general, so there was no point in trying to support 1.0 with F# in the short term? Adding 10 developers to the team would be a drop in the bucket for Microsoft in their dev tools division, reinforcing the notion (right or wrong) that Microsoft has zero sense of urgency around F#.

[cartermp]

@GiorgioG All I can say is this: if you go hunting for reasons why something isn't what you wish it to be, you'll always find something.

Meanwhile, many F# developers are quite happy with first-class Azure Functions support (recently announced GA), being the only .NET language which works on Azure Notebooks, revamped F# tooling in VS which is ~1 month away from a major update which unblocks loads of people, nearly first-class support in Xamarin, support for building all sorts of great things with Fable, the ability to use every major Azure service for all kinds of apps, and an OSS ecosystem which is bigger and more active than ever before. Not to mention cross-platform tools in VSCode and the .NET CLI and first-class support in Visual Studio for Mac.

Most of what I mentioned is built entirely by Microsoft and is representative of investments from Microsoft, but what I personally love is that it also involves heavy open source activity. It's becoming increasingly vital for development platforms to have a healthy open source ecosystem, and F# is a leader in the .NET world in that regard. Such an example is MBrace, which to my knowledge is the only innovative big data + cloud framework unique to .NET and not just some binding to an existing JVM thing. The open source community can create more things and, in general, move more rapidly than Microsoft can. That's why it's so important and why I'm so positive that F# is moving in the right direction.

Now if you look at all of that and think, "I just don't care. I want .NET Core support on VS right now for F#, and the fact that it's not here right now is bad", then I'm sorry, but there's nothing that can be done about that. The support is coming, it's scheduled, and it's a priority for more than just the F# team. It's just not available right now.

[enricosada]

@GiorgioG F# and .NET Core doesnt work in VS. That's it atm. it's logged in the roadmap. it's WIP, with expected release date too. What's vf# can do more? That's just a normal feature/scenario missing.
Let's wait a bit.

that .NET Core isn't ready for prime time in general

no, he just said, to convert existing libraries and use case, take some time using .netstandard1.0 (because some breaking changes). netstandard2.0 will help about that.
for example for F# the 1.6 mean no Type provider. if you need that, you cannot. for other things is really good.

where are the ASP.NET Core project templates in Vs2017?

Why add .NET core or .NET Standard templates, if these will not work after creation? that will annoy dev more.

@GiorgioG if you want asp.net core mvc template, just do dotnet new mvc -lang f#.
Or wait until VF# support .net core sdk.

[GiorgioG]

@cartermp:

if you go hunting for reasons why something isn't what you wish it to be, you'll always find something.

I'm not hunting for anything, getting F# to parity with the rest of the .NET stack is not a high priority for Microsoft. I don't understand why it's such a big deal to say that. What matters is not your (or Microsoft's words,) but Microsoft's actions. If the C# team had missed a Visual Studio RC cutoff date, the RC would have been delayed. With F#, they basically said "meh, not important, let them release it out of band as an extension/package." Releasing VS2017 RTM without proper F# support for web dev, .NET Core, also not that important.

@enricosada

no, he just said, to convert existing libraries and use case, take time. .netstandard 2.0 will help about that.

I'm pretty sure that's exactly what he meant when he said:

.NET Core 1.0/1.1 and .NET Standard 1.x is unsuitable for the vast majority of code in the world.

.NET Core is plenty suitable for new projects, which by the way is where F# would fit in nicely. But guess what? Most of them aren't going to even consider F# because it has no VS support.

You guys can continue to spin it how you want to, but the fact remains: F# is treated as a second-class citizen by Microsoft. No shame in that, just own it.

[cartermp]

@GiorgioG I'm not sure what you're referring to here:

With F#, they basically said "meh, not important, let them release it out of band as an extension/package."

F# isn't an out of band extension/package. This doesn't underscore the massive issues in RC1, which we own (not some lofty entity), but it is shipped in-band with good adoption already. I'm not allowed to show adoption numbers, but it's proportional to all-up VS adoption at release compared with total usage (which shouldn't surprise people). And as a counterpoint, F# is getting an update in VS 2017 Update 2. C# and .NET all-up aren't (modulo super critical issues, like crashing VS), even thought I'm quite positive that those teams would love to get changes in there.

To address this:

You guys can continue to spin it how you want to, but the fact remains: F# is treated as a second-class citizen by Microsoft. No shame in that, just own it.

I don't think this isn't helpful. There are multiple, demonstrated cases where F# is first-class in Microsoft products and clearly moving towards first-class in the near-term. This also does not mention the incredible efforts of the open source community, who are pushing F# into new areas that it's never been before. I'm sorry if you cannot do precisely what you would like to do with F# today with Microsoft-authored tools and templates, and please don't think that we're not taking this seriously. But statements like this are not helpful towards anyone's goals. I won't comment any further on the position of whether or not F# is "first-class".

[GiorgioG]

@GiorgioG I'm not sure what you're referring to here:

With F#, they basically said "meh, not important, let them release it out of band as an extension/package."

#2276 - "The latest VS2017 RC3 will not include updates to the F# tools over RC2. This is due to a mistake on our part, causing us to miss the update window for the new bits."

This also does not mention the incredible efforts of the open source community, who are pushing F# into new areas that it's never been before.

The issue is not the incredible efforts of the open source community, the issue is Microsoft's continued understaffing of the F# team. Looking at the github pulse graph it's hard to tell how many Microsoft devs are working in the visualfsharp project, but it looks like it's a handful of developers at best.

[7sharp9]

@21c-HK >since you could (in theory) target iOS and other native-only platforms without having to use Xamarin.

Whats the problem using Xamarin and F# for that?

[21c-HK]

Xamarin.

[7sharp9]

@21c-HK Thanks for that. I guess you here for the troll factor rather than adding anything meaningful.

[GiorgioG]

@7sharp9 how is @21c-HK 's comment any more/less constructive than Krzysztof-Cieslak's comment about VS Code which was cheered & up-voted earlier in this thread?:

but it's not Visual Studio

That's the biggest advantage.

[Krzysztof-Cieslak]

Yeah.... i totally wonder what's the difference.

[GiorgioG]

Yeah.... i totally wonder what's the difference.

Another non-trolling, constructive response.

So I'll follow up and finish with my own: F# is doomed to remain a footnote in the functional programming world due to Microsoft's half-hearted interest - which is sad because it's so much better than the more popular languages. Take care folks.

[Krzysztof-Cieslak]

See you!

[21c-HK]

I'll summarize what happened since my last (serious) post:

• @GiorgioG made a few examples to explain why F# is treated as a second-class citizen by Microsoft.
• @cartermp made a few examples to illustrate how much Microsoft has invested into F# and that it is therefore not a second-class citizen.
• @GiorgioG emphasized that this does not disprove the fact that the F# team is still understaffed (regardless of the impressive results due to the incredible productivity of the F# team and open source community).
• I couldn't resist commenting with "Xamarin." to the question why Xamarin and F# could not be used to target iOS and other native-only platforms 😄. I was (rightfully) called a troll. I apologize. I was only half-trolling: It was meant half-jokingly and I was hoping that it would not be taken seriously. Half-jokingly because I do hope to target iOS and other native-only platforms without lots of additional tooling in the future. But it was not meant to criticize Xamarin. Xamarin is definitely the best mobile platform for .NET and F# right now and what the Xamarin team is doing is really amazing. Xamarin are actually really F#-friendly (i.e. in terms of spirit and actual F# support in their tools) and seem to have a lot more resources. Example: They have AOT compilation of F# code already working.

And that leads me to my other (actually serious) suggestion: @dsyme, @cartermp or who ever can manage to pull it off should go to @migueldeicaza and borrow a few (read as: 10 or more) of his developers in his team while the F# team is understaffed. Then also hire the open source developers that were partly responsible for making F# 4.1 happen and put them on @migueldeicaza's pay roll. I don't think Xamarin would notice 😄 .

[KevinRansom]

I think this thread has run it's useful course.

Thanks for all of the contributions, suggestions and Ideas.

Kevin