Fsharp: How to drive F# Adoption - Part 1?

[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.

[KevinRansom]

My List:

• Support for coreclr
• Much better tooling --- I.e Incorporate Powertools and Compiler Service
• Templates for Web Programming / Azure
• Much improved library / extensions / type provider discovery

[jamessdixon]

UWA (ran into that again this AM - PCL doesn't cut it)
+1 tooling

[rodrigovidal]

• Better Folder support (C# devs love folders)
• Multi-pass compilation. (Most developers are not used to single-pass compilers)
• +1 for Incorporate Powertools and Compiler service
• asp.net 5 support

[eiriktsarpalis]

While C# to F# interop is pretty much flawless, the opposite story has many pain points. For example:

• F# optional parameters awkward to use from C#.
• Lacking an easy way to define F# functions in C#.
• F# extension methods are impossible to use in C#.
• The ever-present _implicit_ dependency on FSharp.Core.

Often when needing to make F# libraries consumable by C# code, I need to define lackluster C# wrappers that are mostly boilerplate. I think that this weakness may have contributed to some extent to the lack of success that F# libraries have had in the .NET ecosystem, which can in turn reinforce attitudes that F# is really just a toy language.

Other than that, +1 tooling/debugger improvements, +10000 CoreCLR support.

[SabotageAndi]

+1 tooling
support or better support for different platforms (coreclr, Univeral Apps, Xamarin)

[lefthandedgoat]

• Marketing and Evangelism from Microsoft (I can't even tell you the number of times people have told me that they have never heard of F#, including MS employees)
• coreclr love
• Slightly better tooling in VS, Resharper support

[jeroldhaas]

• F# on linux has much room for improvement. Problems working with older versions of mono, mainly, since a few distros don't keep mono up to date
• Editor support needs to be on equal ground, with respect to features (Emacs vs Vim vs Code vs VS vs XS...)
• FSI is _painfully_ behind when compared to other REPLs
  
  
  
  • save / restore session like RStudio
  
  
  • "workspace" view like RStudio where bindings can be viewed
  
  
  • intellisense / colorization
  
  
  • font customization / generall look & feel
  
  
• Project templates need love
• F# Web projects are _very_ difficult to work with in VS
• Roslyn and F#?

+1 on macros, compiler extensions

:star: Perhaps the ability to compile to something other than IL? (F#->JS-AST, LLVM, ELF, MinGW)

[7sharp9]

Add more value to the core language:

• Add macros to the language
• Add compiler extensions to the language

[forki]

Tbh with the success of powertools and ionide I would vote to get the IDE
tooling completely out of this repo. These two repos show really good
quality and fast release cycles if something goes wrong.
It's also much easier to contribute since everything is in a build script
and there are no hidden internal product builds.
I'd love to see Microsoft contribute to these projects in the future.

There is still lots and lots to do in this repo and coreclr + .NET native +
Azure are things that would belong here and in other MS repos.

But please don't kill the OSS effort of the other projects by taking
control.
On Dec 16, 2015 20:34, "Andreas Willich" [email protected] wrote:

+1 tooling
support or better support for different platforms (coreclr, Univeral Apps,
Xamarin)

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

[ploeh]

Here are my thoughts on how to make F# more attractive to 'mainstream' developers. Oh, dear, here we go:

Make F# a first-class .NET language

You may claim that F# is already a first-class .NET language, but it's not, really. IIRC, when you install Visual Studio 2015, you have to actively select F# as one of the optional languages; if you don't select it, it's not even going to be in Visual Studio.

Furthermore, look at how Microsoft talks about .NET and Roslyn: It's _C#_ here, _C#_ there, and then occasionally _C# and Visual Basic_.

This tendency is clear with the new ASP.NET stack, as well as with Universal Apps.

Outside of the Visual F# team, it seems like F# isn't really on the radar - not even in the rest of DevDiv, and certainly not in the rest of Microsoft.

The (open source) F# community is doing a great job of tooting the F# horn via other channels, but the .NET community (if such a thing exists) as a whole is still largely taking its guidance from Microsoft.

When there's no templates, no samples, no documentation, in Visual Studio, for most .NET developers it doesn't exist.

What's really been puzzling me for a long time is that Microsoft doesn't realize what a gem they're sitting on.

Programmers migrate towards better languages. When Java stagnated, many migrated to Scala (and Clojure). Programming languages _matter_. Microsoft as a whole sort of realises this: just look at the scramble towards JavaScript.

F# is a unique language offering, because it's the only(?) 'industrial strength' programming language that offers a Hindley-Milner type system.

• F#: Strongly-typed, Hindley-Milner
• Scala: Strongly-typed, but not H-M (AFAIK)
• Clojure: Dynamically typed
• Erlang: Dynamically typed (I think)

It may not be everyone's cup of tea, but if you want to be 'almost as Functional as Haskell', but can't convince your organisation to take a chance on it, F# is a great choice.

Furthermore, due to the interop with .NET, it's easy to gradually introduce F# into an organisation that already runs .NET.

Better tooling

All that said, better tooling is still needed. As @forki mentions, there's a lot of good to be said about F# Power Tools, but there are also areas where the Visual Studio editor seems too 'primitive' compared to the C# editor.

E.g. it'd feel more modern with

• Code Lens
• Peek Definition

I don't know if these can be built with F# Power Tools, but since it hasn't happened yet, I suspect these are some proprietary Visual Studio UIs that are locked down...

Better web tooling support

Web development is still a thing, and if the web development support is poor (e.g. lack of templates), you lose a lot of adoption right there.

ASP.NET vNext isn't making it easier to get started with web development on F#. While I'm aware of alternatives such as Suave (and perhaps Freya), they aren't going to win C# developers over if it looks like it's impossible to create an F# web project in Visual Studio.

Faster compiler

The F# compiler is, unfortunately, slow.

Whenever I'm back in a C# project, I'm surprised at how fast I can compile a much larger code base.

The slow compilation time hurts many development processes, e.g. Red/Green/Refactor, which should be faster than 10 seconds. In my experience, it's impossible to keep the cycle time under 10 seconds on a moderately-sized F# code base, because compilation alone can take 4-6 seconds.

Oh, and while we're talking about compilers, I'd like to downvote :-1: @rodrigovidal's suggestion for a multi-pass compiler (sorry, nothing personal). The single-pass compiler is F#'s most precious asset.

[gsobocinski]

I have to agree with @lefthandedgoat marketing and evangelism is the key. I'm also interested in Elixir and the way that they are engaging Ruby devs, amongst others, shows us the way F# needs to go.

[sergey-tihon]

• More love from MS on public events (people should know that F# a first-class .NET language)
• Better FSI with intelissense + some other features
• Better tooling (CodeLens & Peek Definition)
• Folder support in fsproj (Multi-pass compilation or super-intuitive compilation order management with single-pass compilation)
• Project.json should allow to plug external dependency manager, so Paket should be first-class .NET dependency manager

:+1: For FSharp.Core
:-1: For CoreCLR

[dsyme]

Awesome discussion.

Language

• Progress the language incrementally. I won't discuss that here. (That said, extra language features would make only a relatively small marginal difference in adoption compared to other things.)
• As an aside, I will mention the need to get the language/compiler bug count right down in this repo. I personally find it hard to do major new rounds of language work when I still see a bug trail. (Separating tooling bugs from language/compiler bugs would help with that, e.g. by putting the IDE tooling in a separate repo. My personal belief is that bug "weight" grows at O(n * log(n)) rather than linearly given the time to search and organize issues.)

Compiler and build

• Core CLR +1000. Amazing progress here recently and it's so important to be doing this during the phase when we can still get feedback to the CoreCLR design and surface area. Very, very exciting.
• Keep improving F# compiler performance incrementally.
• Keep incrementally enabling and improving F#-to-JavaScript compilation (not in this repo, but through WebSharper, FunScript, Compiler Service). In the long term it will only become more important to support some modicum of this in various scenarios.
• Keep making dependency management simpler and more sound. It was not happy that "Missing Method Exception" should have been so common for so many years with F# - we put a huge amount of work into making the language sound, only to have DLLs and dependency management bite us. I love Paket because it solved this problem most the projects I work on. Roll on Nuget V3 and Paket vNext, and full credit to Steffen for the huge influence he's had here in making the world a better and happier place.
• Move off MSBuild project files. These just don't cut it for the next generation of hipster programmers.

Visual F# Tools:

• The default Visual F# Tools are a really big place to make a large difference for driving adoption of F# . Millions of people use Visual Studio every day for Windows programming. They are all potential F# users. Many have tried F# and seen that the default tooling needs serious work. The Visual F# Power Tools are awesome. Every person giving a talk or demo of F# in Visual Studio should mention them and show them. Always.
• Given the importance of the default tooling for F# adoption, I think we need to consider again integrating the Visual F# Power Tools (VFPT) with Visual F# Tools (VFT). (Tactically, this could either be done in visualfsharp repo, or by making VFPT a complete replacement for VFT, and/or by making a new repo that holds the integrated combination. Microsoft would then ship this combination as the default tooling in Visual Studio. Either a repo managed by Microsoft (like this one) or one co-managed by a highly trusted community member and Microsoft. Quality and performance would need to be prioritised - I'm kind of assuming the absolutely awesome boom in VFPT functionality plateaus a bit)
• Start an initiative for better F# Interactive tooling in Visual Studio. Probably as a sister repo to this one initially, co-run by a Microsoft engineer and with some Microsoft PM oversight, but with a clear path to convergence & integration into VFT.

Upstack frameworks and tools (Web, Cloud, Client, Data, Data Science, Build, Test, ...)

• I'm a huge believer that the biggest area by which to drive more adoption is through better and greater "upstack" frameworks, meaning for web, cloud, client, data, data science, build, test etc.. People flock to languages with frameworks that suit a need and a purpose. F# has come a long way recently (e.g. Suave, MBrace, FsLab, FAKE, FsCheck and many more - sorry not to list your favourite). Supporting and growing a really compelling set of upstack technologies is crucial. Likewise, support in more canonical .NET frameworks is even more crucial too.

[rodrigovidal]

@ploeh Hey Mark, I really like F# single-pass compiler, I do know it's value. But I really think that it's something that harm's adoption.

As far as I undestand, Kevin asked about what could drive adoption, not what I would like F# to be. (That would be lots of language features like typeclasses but it wouldn't drive adoption). F# is the only language I know that has this feature, and it's very annoying when you are a beginner. That's one of the main complaint I have been listening from C# developers over years.

Maybe I'm wrong. :)

[lefthandedgoat]

I also think you need 2 strategies for 2 different types of developers. Two is probably an oversimplification.

Group 1 is the current .Net and C# developer. They need MS to give blessing. Its pretty much as simple as that.

Group 2 is the non MS Stack developer, data scientist, academics, and young people. For that you need awesome *nix experience.

[forki]

@mark I know what you mean with the Web remarks, but suave.io is working
really nicely inside of VS. There is just no asp.net vnext ootb, but that's
more an issue that needs to be discussed with the asp.net team. We asked
them very early if they have F#ers on the team (or if they are in direct
contact), but they said that wouldn't matter since it's all IL. ;-) Now
after everything is in RC it's much harder to make it work, but AFAIK some
people are still optimistic about it and there is even a repo which seem to
work somehow. So we will see.

Cheers, Steffen
On Dec 16, 2015 22:19, "Mark Seemann" [email protected] wrote:

Here are my thoughts on how to make F# more attractive to 'mainstream'
developers. Oh, dear, here we go:
Make F# a first-class .NET language

You may claim that F# is already a first-class .NET language, but it's
not, really. IIRC, when you install Visual Studio 2015, you have to
actively select F# as one of the optional languages; if you don't select
it, it's not even going to be in Visual Studio.

Furthermore, look at how Microsoft talks about .NET and Roslyn: It's _C#_
here, _C#_ there, and then occasionally _C# and Visual Basic_.

This tendency is clear with the new ASP.NET stack, as well as with
Universal Apps.

Outside of the Visual F# team, it seems like F# isn't really on the radar

• not even in the rest of DevDiv, and certainly not in the rest of
  Microsoft.

The (open source) F# community is doing a great job of tooting the F# horn
via other channels, but the .NET community (if such a thing exists) as a
whole is still largely taking its guidance from Microsoft.

When there's no templates, no samples, no documentation, in Visual Studio,
for most .NET developers it doesn't exist.

What's really been puzzling me for a long time is that Microsoft doesn't
realize what a gem they're sitting on.

Programmers migrate towards better languages. When Java stagnated, many
migrated to Scala (and Clojure). Programming languages _matter_.
Microsoft as a whole sort of realises this: just look at the scramble
towards JavaScript.

F# is a unique language offering, because it's the only(?) 'industrial
strength' programming language that offers a Hindley-Milner type system.

• F#: Strongly-typed, Hindley-Milner
• Scala: Strongly-typed, but not H-M (AFAIK)
• Clojure: Dynamically typed
• Erlang: Dynamically typed (I think)

It may not be everyone's cup of tea, but if you want to be 'almost as
Functional as Haskell', but can't convince your organisation to take a
chance on it, F# is a great choice.

Furthermore, due to the interop with .NET, it's easy to gradually
introduce F# into an organisation that already runs .NET.
Better tooling

All that said, better tooling is still needed. As @forki
https://github.com/forki mentions, there's a lot of good to be said
about F# Power Tools, but there are also areas where the Visual Studio
editor seems too 'primitive' compared to the C# editor.

E.g. it'd feel more modern with

• Code Lens
• Peek Definition

I don't know if these can be built with F# Power Tools, but since it
hasn't happened yet, I suspect these are some proprietary Visual Studio UIs
that are locked down...
Better web tooling support

Web development is still a thing, and if the web development support is
poor (e.g. lack of templates), you lose a lot of adoption right there.

ASP.NET vNext isn't making it easier to get started with web development
on F#. While I'm aware of alternatives such as Suave (and perhaps Freya),
they aren't going to win C# developers over if it looks like it's
impossible to create an F# web project in Visual Studio.
Faster compiler

The F# compiler is, unfortunately, slow.

Whenever I'm back in a C# project, I'm surprised at how fast I can compile
a much larger code base.

The slow compilation time hurts many development processes, e.g.
Red/Green/Refactor, which should be faster than 10 seconds
http://blog.ploeh.dk/2012/05/24/TDDtestsuitesshouldrunin10secondsorless.
In my experience, it's impossible to keep the cycle time under 10 seconds
on a moderately-sized F# code base, because compilation alone can take 4-6
seconds.

Oh, and while we're talking about compilers, I'd like to downvote [image:
:-1:] @rodrigovidal https://github.com/rodrigovidal's suggestion for a
multi-pass compiler (sorry, nothing personal). The single-pass compiler is F#'s
most precious asset
http://blog.ploeh.dk/2015/04/15/c-will-eventually-get-all-f-features-right
.

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

[bryancostanich]

+1 for the single pass compiler. makes it feel like a language from the 70s.

[7sharp9]

+1 on Removing the reliance on msbuild files, I hate thats stuff, its a common theme with the people I talk to as well.

• Smooth issues with FSharp.Core, there seems to be a lot of issues with FSharp.Core resolution in thw wild, whether that be not following the guidelines or whatever, there needs to be a better solution be that improved docs or awareness etc. (Better adoption as you don't hit painful FSharp.Core issues with the first oss repo you clone from github)
• Also more evangelism on other types of F# project such as mobile :-)

[misterspeedy]

By an amazing coincidence I just did a Twitter poll on exactly this.

"When you've seen people reluctant to use #fsharp, what has been the main reason?"

34% Seen as too hard
33% Office politics
11% Job-preservation
22% Limitations/tooling

(76 votes)

Although my poll was a little mischievous, it does give us some almost-facts to work with.

You'll note that 44% of resistance appears to be pretty much irrational. It's certainly my experience that there are groups of people out there who will actively sabotage F# projects. I think the only way this will end is if Microsoft starts making more public pronouncements in favour of F#. The open source effort for F# is utterly magnificent, but in the corporate mind this is still trumped by lack of MS buy-in.

Next up we have 'seen as too hard' (34%). I have definitely encountered truly talented developers who simply can't get productive with F#. Perhaps the technical fix is for the community to make a huge effort to extend the range of quality templates. There is an immense amount of quality training material out there but more can do no harm. I do have a book idea to address this if anyone out there wants to chuck me some budget. ;-)

Only a fifth of people thought that technical limitations and tooling are the main reason for resistance. So we shouldn't hope for too much here. That said, I would LOVE to see go-to-definition and find-references work between C# and F#. Every time someone asks for this it seems to fall into a political hole between the Visual F# Team, the Visual Studio Team and the Community. But solving it would make the biggest dent in that 22% in my opinion.

[forki]

By that same logic we should add more curly braces to the language. ;-)
On Dec 16, 2015 22:44, "Rodrigo Vidal" [email protected] wrote:

@ploeh https://github.com/ploeh Hey Mark, I really like F# single-pass
compiler, I do know it's value. But I really think that it's something that
harm's adoption.

As far as I undestand, Kevin asked about what could drive adoption, not
what I would like F# to be. (That would be lots of language features like
typeclasses but it wouldn't drive adoption). F# is the only language I know
that has this feature, and it's very annoying when you are a beginner.
That's one of the main complaint I have been listening from C# developers
over years.

Maybe I'm wrong. :)

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

[JonCanning]

+1 for evangelism

Your average corporate .NET dev will adopt F# when they get paid to. Many are not enthusiasts and don't have the time or inclination to learn anything outside of the 9-5. They're not waiting for that final language or tooling feature to drop before considering it.

[rodrigovidal]

@forki I think that's too far. :P

[rodrigovidal]

@gsobocinski Elixir was designed to be ruby friendly. And it's stealing developers mostly from the ruby community. Which community we are aiming if any? @dsyme

[TeaDrivenDev]

I know I sound like a broken record on this, and people generally disagree with me there, but from my limited perspective and in my environment, one of the biggest roadblocks for F# adoption will be something largely beyond the F# community's control - missing support in IDE tooling, primarily in widely used third-party software like ReSharper or OzCode.

The reason is simple: Initial F# adoption in .NET shops will very often start with single F# projects in larger solutions dominated by C#. The everyday workflow in C# is aided greatly by the available tooling, and when there suddenly are parts of the code that tooling doesn't cover or even _know_, that causes friction. When someone renames a symbol as they are used to, and then find that the code doesn't compile anymore because that change didn't get into the part written in a different language that one person in the team insisted on starting to use, it's likely not going to make them view F# any more positively, because it even disrupts their work elsewhere.

Yes, it's sad, because the most important thing should be the qualities of the language itself, but .NET development at large is a very tooling-centric affair, and for most people C# and the existing tooling are "good enough" and relatively low-friction, so F# will have a very hard time getting into many places without even rudimentary ReSharper support (say, at least not being blind to F# code for "find references" and renaming).

As for VFPT becoming a part of VFT - yes, it would be great to have all that "out of the box" with Visual Studio, but considering the pace of of the Power Tools and the relatively long release cycles of VFT, that might keep great new features out of people's hands for longer than we are used to having to wait.

[rojepp]

Getting people to try at all

• Evangelism - most devs I speak to have heard of F# once or twice, a couple of years back. Great to see such attention recently from the 'Week in .Net' blog. But mostly, F# doesn't exist, because MS doesn't say it does.
• F# is for math/finance - The initial message from MS really stuck, because no-one has heard anything different since then, see above. I hear this all the time.
• F# is _functional_ first - It simply is a big step from OO, it requires a curious mind to even give it a try. Not much we can do about that.
• CoreCLR

I find it interesting that Scala much more often is acceptable even though it, to me, is a pretty messy language. Maybe it is because Java is that much worse than C#?

When they do try

• As @dsyme mentioned, things like MissingMethodException is incredibly frustrating. I run into it all the time.
• Tooling - Even with VFPT, tooling feels old. Best tooling around seems to be Xamarin Studio.
• Compiler speed - Very slow compilation, and this extends to slower tooling as well.

[gsobocinski]

@rodrigovidal Elixir took a lot from many languages. What I think they've done well is too publicise and promote real examples of using Elixir over say Ruby. What hits home for people is relating it back to something they know and have had experience with. There are lots of war stories with Ruby dev which always get addressed when comparing the two making the decision easier. If we could the same with F# and say C# that would help alot. I think what the guys at jet.com are putting out there is definitely the way to go. Real world examples with proven results. Kind of makes it hard to disagree with.

[mathw]

Equality: when F# was first included in VS it was installed by default, it was going to be a first-class .NET language, things looked great. It's very clear now that this was never really the case. It isn't a first-class language, it's not installed by default, the tooling isn't as good, and _Microsoft don't even talk about it_. And it gets left out of the fun: ASP.NET vNext is all C# C# C#. Okay so I don't like MVC as a model for web programming anyway, it's a terrible fit, but if you want to lure .NET developers over you need them to be able to make an MVC project entirely in F# or they won't think it's a real language. Likewise we need to be able to make pure-F# Universal Windows Platform apps. Out of the box. Previously I would have said WPF (it always frustrated me that I couldn't do that when I was a WPF developer) but it's probably a bit late for WPF now! So we need the new build system for ASP.NET 5 to be able to handle F#, and for the tooling to support pure F# projects in this framework. Even though we know Suave is a better fit.

This also applies to developer comms, blog posts about new tech etc. - some of this content should just be in F#. Make it look normal. Start writing chunks of Office in it, or whatever giant .NET projects Microsoft has internally. Tell the world that Azure Logic Apps are powered by F# (I don't know whether they are or not, but it'd be neat if they were). Talk about design patterns in functional languages. Then step beyond equality as everyone realises C# is the last gasp of the old guard before the new(yet still old) comes in.

Evangelism: It's all C# and TypeScript that we hear about from Microsoft these days, yet they're sitting on a language that is better than both of them for both purposes!

Interoperability: There are some dodgy points in getting C# to talk to F# libraries. If that could be smoothed out somehow it would really help get some F# code into existing C# projects.

Tooling: The F# experience in Visual Studio is nothing like C#, even if you discount the influence of third-party tools like ReSharper, which is almost ubiquitous. While it's sad that ReSharper have never felt it necessary to add F# support, Microsoft could put more effort into the F# coding experience, and get it up to par with the out of the box C# experience, which is encroaching further on the classic ReSharper territory every release. Error highlighting needs to be better too - it frequently doesn't seem to be able to pinpoint the source of a problem and just splats wiggly underlines everywhere which is very unhelpful. Everyone, every single language, needs to look at Elm's error messages for the idea of what a compiler can do these days. And Elm shares heritage with F# and uses Hindley-Milner types and type inference, so surely F# could gain some of its diagnostic capabilities.

Performance: Okay so obviously the compiler is working harder to compile F#, all that complicated type inference etc. is what sets F# apart from C# and also makes it slower to build. But if it could be made faster - and surely there are ways to do that - it would help a lot with developers feeling productive. Similarly, the VS tooling needs to be fast. It's too slow doing its overly broad error marking and then removing them when an expression I was halfway through writing is now complete and typechecks properly.

[0x53A]

Regarding Tooling, one possible solution would be to include the existing PowerTools as a Third-Party Product in the Visual Studio Setup, similar to the Powershell-Tools.

I think for most existing .Net shops, the most likely point of introduction would be one developer liking F# and trying to integrate it into an existing product. For F# to be accepted by the other developers, you need great interop from C# to F#.

Getting started with F#:
I don't know about you, for me, wrapping my head about F# initially was hard. (I knew a bit C# at that point) I think I started the tutorial project three times over half a year, never really understood what was going on and then just closed it. To really motivate people to continue with that, you need to show them what is so special about F#. Not just how they can write in F# what they would write in C#, but also what they could do in F# but NOT in C#.

One great example is here:
http://www.codeproject.com/Articles/87294/Symbolic-Calculation-in-F
http://codereview.stackexchange.com/questions/11804/symbolic-derivative-in-c

You have some foreign looking code in F#, but even just looking at the code, it is more or less obvious if you know your math.
The C# code has so much noise that it's hard to see whats going on.

[moonmile]

• custom operator like scala.
  let x = a ∩ b

[KevinRansom]

Okay having collected some data. we can chat about it here:
https://github.com/Microsoft/visualfsharp/issues/803

Kevin

[bleis-tift]

F# code is not respected by C# (and maybe VB)

When I create two projects, one is F# (named ProjFS) and another is C# (named ProjCS),
and I invoke a method defined in ProjCS (let's say ProjCS.Class1.ctor()) from within ProjFS code,
ProjCS.Class1.ctor() doesn't count the invocation code in ProjFS.
So, if I try to find references of ProjCS.Class1.ctor(), I can't get any information about ProjFS code
(i.e. CodeLens tell me 0 references and "Find All References" returns nothing).
I think it makes potential F#ers sensitive, and they might avoid to use F#.

[ghost]

Good point on "F# code is not respected by C# (and maybe VB)" - very problematic!

[ForNeVeR]

Also we'd need Entity Framework support. Currently it's the most painful area for me when I'm trying to develop some "enterprise" project in F#: no code generation, no DB migrations :(

[Indy9000]

In addition to what's said about tooling,
support F# within a C# project, so that devs don't have to switch over wholesale to a different workflow initially when trying out F#.
For example being able to have a class in F# in a .fs file inside a csproj that gets compiled properly and be available to the rest of the C# project.

This could be sold as a C# feature :)

[KevinRansom]

Could you explain what you mean. Are you suggesting the C# compiler compiles F# code?

[Indy9000]

F# compiler compiles F# implicitly without the programmer having to do a dance about it. For example, in a VS C++ project you can compile .cu with a CUDA compiler. But there CUDA toolset have to be painstakingly installed, and compile target has to be set for .cu. So imagine the similar, without the pain points but with F#

[KevinRansom]

Yes, except the C# compiler is what creates its the assembly. The F# compiler creates an assembly for code it produces, that is very unlikely to change. C++ and cuda works because a linker is the tool that constructs the final binary.

But you can easily have an F# project and a C# project in a single solution, which is pretty much as good I would say.

[ploeh]

@rodrigovidal Good point about the single-pass compiler perhaps being a barrier. You may be right, but I _hope_ we can keep it a single-pass compiler! ...Also, it's slow enough already, doing that single pass :wink:

[Indy9000]

Yes, but F# Assembly can be automatically included and made available in C# project. My point is that, increase adoption by reducing this sort of separation and friction..

[KevinRansom]

@Indy9000 yes indeed there is a certain amount of friction due to that in cross language solutions. I wonder how we would measure the significance of it.

[KevinRansom]

@ploeh @rodrigovidal I'm with Don on this, F# is already a phenomenal language ... changes to the language may garner some additional adoption, but the hockey stick growth in adoption is not really held back by the lack of forward referencing. Additional slowness would certainly hold back adoption though.

[ploeh]

@Indy9000 Is it possible to have Visual Basic code files within C# projects, or vice versa?

[Indy9000]

@KevinRansom I guess the value could be - So many of F# lang features being shoehorned into C# lately, now you can have the whole hog inside your comfort zone :)

[ploeh]

@KevinRansom If I came across as advocating changing _the language_, that wasn't my intention at all.

[Indy9000]

@ploeh I don't know. But I personally like the utopian idea of being able to code in whatever language in a project and have the toolset deal with it implicitly.

[isaacabraham]

Sorry for late reply into this thread - been sick - my thoughts though do seem to lie along the same lines as most of the suggestions here.

1. .NET users are (IMHO) the easiest way to increase F# user base. They already know .NET, they already know the tooling and ecosystem. But they are also used to the rich tooling that C# gets in Visual Studio; even losing small features such as "intellisense appears as soon as I start to type" etc. and the user loses confidence in the F# tooling experience. As we've discussed in the past though, the cost of improving the tooling for Visual F# e.g. better tooltips, code lenses (AFAIK this API hasn't been opened up so VFPT can't hook into it) might be quite high for the existing Visual F# team compared to working on other areas. The same can be thought of for project templates for F# - not just for ASP .NET but e.g. Azure templates (there's quite a few of them now), WPF templates. etc. etc.
2. Evangelism / simply awareness of F# from Microsoft individuals is also something that could help. In just a few hours anyone that works in C# can get a feel for what F# is "about" without knowing the ins and outs of the language. Just doing this might help a lot. And yes, this whole "F# is just for maths and science" still hurts F# even today.
3. CoreCLR - this targets an entirely different sector of users, basically those that are not coming from a .NET background, and therefore not just those developers doing e.g. LOB apps but also data scientists and other areas not normally associated with .NET. I'm still not entirely sure how easy this will be - will people associate F# with Microsoft and be negatively predisposed towards it?
4. Better Azure support in general for F#. Lots of services on Azure do work with F#, but some of those require extra work, and others don't support it at all. This is a pity as F# is a great fit for working with distributed workloads.

I would say that I am completely non enthusiastic about spending time improving FSI. Why? Surely the fsx -> fsi experience is superior, more cost effective, and also repeatable.

[forki]

@isaacabraham better azure support is basically in MS own interest. It's a really nice language for the cloud and if MS wants to get users back from JVM based languages then this is the way to make that happen.

[KevinRansom]

@ploeh I got that. In fact, I would prefer removing the file ordering restriction myself. I expect we will get asked for compile a directory once C# developers get used to compile a directory and notice that F# can't support it, however that is a fight I have no desire to have until it becomes necessary.

@forki I think suave is probably the right approach for F#, I would love to see proposals for the necessary tooling to support that. Right now the clamour seems to be for ASP vnext tooling for F#. But if there is a way to make suave based tooling, I believe we should make that happen instead.

[enricosada]

F# as language is awesome, tooling need improvements ( real improvements, not only folder in projects )

My main paint point are

F# is targeted/marketing as a class library for .NET, not a real language to develop app/web

That mean, you need C# for WPF, Winforms, asp.net, and you can add F# as a library
Is a real big smell for me, when i tell people to used f#, i do a demo with F# only but is a showcase only ( like drag-drop from old ms demo ). That's a problem of tooling, but also marketing/targets

And going forward is worse (see xaml intellisense not working anymore, azure publish, etc )

It's from ms, but ms doesnt document/sdk F# for the main projects (azure/bi)

From outsite, f# seem unsupported. It's more supported nodejs or python for sure

Feedback from me as c# developer

The ide ( without VFPT ) has too much problems ( project system )
I need to know c# to use f# ( debugger for example )
I cant use for web asp.net or app. I can use that as a library, but lose a lot because of c# interop ( and i dont want need to do that )

[ploeh]

@KevinRansom @forki I have no personal need for ASP.NET support in F#, and I also stand behind adding support for other Web Frameworks like Suave.

No matter how good hypothetical Suave tooling is, however, I doubt it will win over many C# developers. C# developers come with the knowledge they already have. If they're curious, they wish to learn F#, but we can ease the pain of the transition by keeping everything else stable. It'd be reassuring to know that all the frameworks and libraries you already love, still work with F#.

Asking people to learn both a new language, and a new tool chain, all at the same time, is, IMO, a barrier to adoption.

Good support for ASP.NET would make the transition easier, because then newcomers would only have to deal with learning a new language.

Once they've learned the language, they may then discover that there are other ways of doing things that fit better to F# than the object-oriented frameworks and libraries they were used to.

One thing at a time, though :smile:

[forki]

I don't think MS wins if C# users go to F#. The only win is if users stay on the .NET stack and don't move to scala/clojure or whatever JVM language. Or even better if users from other stacks come to .NET because of the compelling F# data sciene on Azure story (or whatever story might do that).
Just recently I helped to port a web app from clojure to suave and they are super happy to finally have type providers for SQL Server access and easy Active Directory support, ...
That company is a new and happy .NET user.

Why would we want to win C# users that are happy with ASP.NET? From MS standpoint I don't see this as a goal. We should care about the unhappy people and show them alternatives.

[matthid]

One thing to add: F# Files in C# Project was already mentioned, but I think the reverse might even help a lot more -> This could make all the existing designers 'just work', but needs to carefuly designed to fit into the single pass F# compiler (which I think we should keep). This would eliminate the need to create C# projects for all the cool stuff, which I think is a huge problem to adoption. Why use F# if you need to use C# anyway? Needless to say that now with roslyn we even have all the APIs we need to realise this.

Just something to throw into the discussion :). I agree with almost all that has been said already, so no need to repeat 4 points.

[smoothdeveloper]

@matthid & others, both F# and C# support compiling netmodules which can be assembled together in a single assembly.

[dsyme]

(moved from https://github.com/Microsoft/visualfsharp/issues/803)

I'd like to make some comments related to "better upstack frameworks". I listed that as the highest priority but it is missing from the summary list (ASP.NET is mentioned - I'll get to that below)

While F# itself is in good shape for upstack frameworks today, I believe there has been a kind of structural problem in Microsoft's thinking about Visual F# over the years (aside: please see this blog entry for the distinction between the terminology "F#" and "Visual F# at Microsoft"). The problem is epitomized by the following, all of which have at times been themes for Visual F# at Microsoft since 2007 (on and off):

• "The preferred web stack for Visual F# must be ASP.NET, because that's Microsoft's main .NET thing"
• "The preferred communications stack for Visual F# must be WCF, because that's Microsoft's main .NET thing"
• "The preferred visualization stack for Visual F# must be WPF, because that's Microsoft's main .NET thing"
• "The preferred client side web stack for Visual F# must be Silverlight, because that's Microsoft's main .NET thing"
• "The preferred gaming stack for Visual F# must be XNA, because that's Microsoft's main .NET thing"
• "The preferred data stack for Visual F# must be Entity Framework, because that's Microsoft's main .NET thing"
• "The preferred cloud stack for Visual F# must be Azure (V1 circa 2010), because that's Microsoft's main .NET cloud thing"
• "The preferred app stack for Visual F# must be WinStore and WinRT because that's Microsoft's main .NET app thing"

You see the pattern. And at least half of these technologies are no longer seriously active.

For F# itself, it's only recently that it's begun to find clear water with the development of truly homegrown F# stories in various upstack areas. For example

• F# now has a fantastic cross-platform app and gaming story with Xamarin.
• F# has a great communications stack, via async programming over HTTP, TCP, etc using the .NET libraries. What we needed was there all along.
• F# has a number of great data visualization stacks, including those found in FsLab
• F# has good client-side web stacks in WebSharper and FunScript, as well as serving JS directly
• F# has a great data story: "F# type providers for everything" e.g. FSharp.Data
• F# has a great cloud story: .NET SDKs for all major cloud platforms, plus some great F#-friendly scalable technologies like MBrace.
• F# web programming looks good: Suave, WebSharper, type providers for data access, plus some ASP.NET support.
• The F# data science story now looks nice: the R type provider, Math.NET, Intel MKL, FsLab, FSharp.Data etc.

The list goes on. F# itself is now in good shape upstack. Further, you can use most of the technologies I listed with F# and use them well - just today a new PluralSight course went up about Test Driven Development with F# that includes using F# with EntityFramework. However these technologies don't dominate the F# programming world in the same way as for C#.

However, looking back, "upstack" has been a major issue for Visual F# at Microsoft and its adoption. Indeed, I would argue that it has been _the defining problem for Visual F# at Microsoft_. It's not tooling. It's not education. It was the upstack story, and in particular the dominant nature of certain upstack technologies within the .NET ecosystem.

Over the years, the Visual F# team (and sometimes other teams at Microsoft) have actually put quite a lot of effort into making Visual F# work well with some of these upstack technologies. There are still Silverlight templates shipping with Visual F# (though that looks wrong now) Honesty is needed and it is clear in many cases this may not have been the best thing to have been doing (though it's easy to say that in retrospect!). What did Visual F# really get out of support for Silverlight? Or WCF? Is Entity Framework really the right preferred data story for Visual F# in all scenarios?

Don't get me wrong: there was no fault with Visual F# or the Visual F# Tools team here. It's a structural problem to do with locating a language within an ecosystem. Other languages have similar problems. C# has had its own version of some of these problems.

Further, it's important to emphasize that Visual F# has been _very_ successful within its own area of providing a great functional language for .NET - "bringing functional programming to .NET, and .NET to functional programming" was always the guiding mantra for F# 1.0-2.0, with the added angle of "information rich programming" in F# 3.0. Interoperating with .NET itself has paid a huge dividend: .NET has gained a lot from F#, and F# has gained a lot from .NET.

However the same is not really true for these upstack frameworks. The dividend we got with .NET (and which we get when using "normal and well designed" .NET libraries) just didn't arise when it came to the above upstack technologies. To take one example, there was no real win-win between WCF and Visual F#. Little divided, little win-win. In that situation, more Microsoft evangelism wouldn't have helped, more tooling wouldn't have helped: people would still have asked "how to we do networking with F#" and the correct answer ("use System.Net!") would have been hidden behind a mass of other information.

Looking forward, some things are crucial for Visual F# at Microsoft and driving adoption of it: For example, I seriously believe in Azure platform as a growth platform at Microsoft. Thus I believe, from the Microsoft perspective, of the importance of arranging a "win-win" between Azure and Visual F#. The relevance and applicability of Visual F# for cloud programming is entirely obvious, but getting that message out there is not easy. (Also, as an aide, be aware that Azure adoption is not necessarily correlated with developer numbers: cloud platform providers may end up chasing relatively small numbers of upper-end developers who drive usage of the cloud platforms at scale using frameworks like Spark and MBrace)

In summary, F# itself is doing well upstack. And .NET is also changing: there is less emphasis on some of these technologies. But for Visual F# and Microsoft, the questions still remain: how does Visual F# fit with the rest of what comes out for .NET, and with Microsoft's platforms. This is one reason why CoreCLR and UWP support for F# are so crucial.

Finally, I think this is also a fundamental long term question for C# and .NET as well: to what extent do F#, C# and .NET get defined by these upstack technologies? There is a problem with .NET: when decision makers think "C#" and ".NET" they have often strong associations with all these upstack technologies. That can be good, that can be bad. For example, it can appear that .NET developers are not open-minded and independent when it comes to upstack choices. This hints at a fundamental tension of Visual F#: it brought a language that came from the *nix tradition of programmer independence, open-mindedness and expressivity into a culture that was all about affinity with upstack tech. In many ways we're still working through that tension today.

[swlaschin]

My belated two cents:

-1- Focus on the out-of-box-experience (OOBE).

The time from "Hmm, let me give a go", to "Wow, I have something useful" needs be measured in minutes.

That implies: quick start sample programs, easy to install libraries, no weird errors like "Missing Method Exception".

For an historical example of this, compare Ruby acceptance before and after Rails. Python also struggled for many years before a standard web framework was developed.

PHP is a classic example of the importance of OOBE. For all its failings, it is very easy to get started in PHP.

Python and Go and Elixir are also great models of OOBE, I think.

-2- Take complete control of the OOBE. This in turn may mean decoupling the eco-system from MSFT (or having a parallel ecosystem at least).

For example, not using .proj files, not using nuget, not using msbuild, etc. This is well on the way to being done although it's not an explicit strategy.

-3- Focus on people who are having pain.

I'm not sure that most C# developers fall into this category, because as Eric Sink pointed out,
C# is already good enough. One approach might be to focus on non-MSFT developers who would not seem to be an obvious target.

For example, Go ended up being surprisingly attractive to Python/Ruby people (much more than to the C++ people it was originally intended for) because, when Python/Ruby projects became large, dynamic languages started causing pain, and Go solved that.

I really think that there is room for F# to be a "statically typed Python"! Which in turn, or course, requires excellent cross-platform support.

And there may be many subgroups where the pain is felt even more: data science comes up a lot, for example.

-4- Focus on solutions not features.

The best way to ensure wide adoption is to help people make money, or to help people save time.
I'd love to have typeclasses, but in the big scheme of things it's trivial compared to solving real problems.

So, let's make sure that F# makes developing _solutions_ easy. For example, make sure it can integrate with anything (yea type providers!), make sure that the various web stacks are easy to use, make sure it is trivial to deploy to the cloud (including AWS), etc.

Some suggestions for turning these thoughts into concrete actions:

• Create an "OOBE" tagged issue every time we see that anyone has _any_ problem getting started, and then work to eliminate them.
  Also, in the quick starts show something mindblowing like type providers (which many already do, except that type providers have to be installed first, so you lose OOBE points there).
• Have an explicit strategy of developing all the tools we need to support a parallel ecosystem. That is, treat FAKE and Paket as key components of the F# experience,
  and if beginners have issues using them, treat that as a OOBE problem.
• To attract people who are not familiar with .NET, consider creating compatibility libraries for Python and Ruby so that someone experienced in those languages can import
  a file and then start coding straight away. Having to learn a whole new collection library is a big barrier to entry (see OOBE!).
• Build and maintain a collection of user guides (as on fsharp.org) and sample projects that demonstrate complete solutions in various areas
  (e.g. the Music Store app) to demonstrate that F# is ready for prime time.
• Even in the .NET world, some segments may be having pain and feeling pressure. For example: cloud stuff.
  For this segment, make F# the goto tool for deploying to Azure. Want a scalable, multi-agent system in 100 lines of code? Use mbrace and F#. This is a problem that F# solves better than C#.

By the way, I found this research very interesting and suggestive: "Socio-PLT: Principles for Programming Language Adoption" (Paper, Video).

Also, the "Innovators Dilemma" book has useful things to say about being an small startup in a big organization (tl;dr: bypass the usual channels, you'll never get acceptance from old-school managers).

[isaacabraham]

@swlaschin Some really good points. However, if we're assuming for the moment that we're talking about the OOBE for Visual Studio - I wouldn't personally want to move away from the "standard" ecosystem. Developers are, by and large, conservative. Introducing not just a new language but an entirely new build system would IMHO scare people off and make them think that they have to "give up" all the things that they already know before they can start using F#; this would only help in create, not remove, barriers to entry.

Having the Paket / FAKE etc. etc. story is an important one, and having that as a parallel story is a good idea, but IMHO it shouldn't be treated in place of an excellent F# OOBE experience using the tooling and ecosystem that e.g. C# developers know and trust.

[swlaschin]

@isaacabraham There's no reason not to have two OOBEs!

It seems that there are two potential user segments: VS users (more enterprise-y) and FP-curious users coming from other languages. Everything you say is good, but unfortunately it is hard to for us to control the OOBE for VS users.

However, we _can_ control the OOBE for the latter group, and so my suggestions are to remind us to do that.

Also, as I said, I think there is huge potential for F# to appeal to a wider audience than just C# devs. I think that if we put some effort in there, we might be surprised.

[isaacabraham]

@swlaschin agree with everything you say. That's why I said I think "having [an alternative OOBE experience] as a parallel story is a good idea". I simply don't feel that this should be the default one that is presented to existing VS users.

[panesofglass]

@swlaschin, I completely agree. Any focus on platform simply misses the point. CoreCLR (and .NET Native or LLVM) would enable F# to free itself of past misgivings about being tied to MS. Adopting and perfecting tools to aid development can only help.

I continue to only hear pushback and failure from those attempting to introduce F# into existing C# solutions. While they may prototype with F#, they seem to always finish with a C# implementation. Successful inclusion of F# is very rare. I question whether pursuing a different outcome is worthwhile.

Make F# desirable on its own, and people will find ways to interop. Let those attempts to interop drive improvements.

[7sharp9]

I suppose some of it comes down to whether you want to drive adoption to Visual F# or just F#, those are completely different things.

[enricosada]

with the new microsoft blabla, xplat coreclr i think visual f# and open f# are a lot more aligned than before.
core dotnet goals: xplat, multi ide support, native compilation, no lockin

visualfsharp team is trying to do that now (coreclr and xplat) so i think interest are going to converge with fsharp foundation.
Before xplat/mono was not a target so openfsharp ( and you @7sharp9 , really thx man ) have done the amazing work to make it happen

[7sharp9]

Maybe the best for of new adoption is to bring F# to new platforms and runtimes, be that V8, JVM, BEAM, LLVM. I mean full adoption not partial supported expressions via quotations, full bootstrap. Perfectly possible.

[enricosada]

ok @7sharp9 that's a new level of discussion, i really like the idea, that's should be really a fsharp foundation goal.

[dungpa]

What are F# Foundation's opinions on this? Losing hopes on Microsoft long ago, I would hope F# Foundation could do certain things wrt adoption. It seems nothing happened so far.

[7sharp9]

@enricosada Well thats why I spent a bit of time on that F# -> Elixir transpiler blog post to see the possibilities :-)

[drcrook1]

Wow, there is a lot going on here.. I’ll list out some of my top items.

Things to Improve from a Tech Standpoint

I have listed out what I believe needs to be improved in order of importance.

1. Microsoft Application and Data Platform Adoption of F#. F# is not supported in UWP, IoT Core, SQL CLR, Azure ML, U-SQL does not have an F# flavor. Data Factory supports C#, maybe F#, but has anybody tried it? If there are hard solution architecture blockers of this nature, support will be nearly impossible to gain. So you have to use a C# package to get access to that. As a business decision maker, why do I train my developers on F# if they have to use C# at the end of the day anyways? I am a big fan of F#, but at the end of the day, I end up writing a lot of C# because to write the same application in F#, I have to do a lot of interop and finagling to write my code idiomatically. F# becomes just another language that I have added to my skill sets with no real derived business value due to these hard solution limitations. Of course you can build support, but what business decision maker wants to support that? It’s another component you have to write and maintain.
2. Integration in top tier software for data and analytics in supported packages. Top software packages need to be identified, prioritized and integrated. Right now we have primarily wrapper based solutions in which more common languages are the first class citizen. F# has to compete with that. Reference: Hadoop, Kafka, ZeroMQ, things of this nature.
3. Idiomatic Entity Framework Experience. Enough said. Entity Framework type provider would be ideal. Last I used the SQL Type provider, there was a ton of yak shaving that had to happen.
4. Packages that accomplish simple common tasks. Time-Series, Linear Regression. There are packages out there, but who knows the quality of them? Bring those packages as core shipping components of F#.
5. Common Type providers shipping with the Microsoft blessing. I know that something on GitHub by Isaac Abraham or Thomas Petrick is likely safe. Those packages (particularly type providers) need to be adopted as core language capabilities that can be added as a reference that ships with the F# codebase and is supported by Microsoft. These type providers are the bell of the ball when I show off F# to my communities.
6. Better JSON Serialization of F# types to provide a standard the web UI devs expect. FSPicklr is ok, but try sending a Some/None or a discriminated union down to a UI dev and watch as your
7. F# adoption in Fun Stuff. IoT Core, Unity3D. Maybe an XNA flavor that is F# based. You need to tag the next generation of developers. You aren’t going to convince seasoned C# devs to change their ways, especially considering points 1 and 2 here. Even if you do, they are fighting an uphill battle for shop wide adoption.
8. Better C# consumption of F#. F# consuming C# is much better. Inverse is pretty harsh.
9. inbox flips out. There is extra work necessary on part of the F# dev to communicate on normal standards when taking advantage of the features that separate F# from the rest of the languages.
10. Better REPL referencing experience. I have to use #r to open something with a long path, and then I have to open it. If it is in my references, I should just do "open".

Things to Improve from Communications Standpoint

Again, I have listed these items out in order of importance.

1. F# does not compete with C#. F# and C# complement each other. C# if you look at it closely is built for the lowest common denominator in a developer shop, while F# is tuned more towards more advanced and capable developers. C# has its place, but at the end of the day there is code that is significantly simpler to write in F# than C#, the caveat is that F# has a learning curve to it that is higher. F# is filling a gap that C# has in it provides the language capabilities necessary for more advanced programming tasks. In many cases the community shifts to non-Microsoft technologies to fill this gap. F# is here to provide a very necessary component of the holistic Microsoft platform story in that we have a functional programming language which is geared towards advanced workloads that integrates with our common programming language and should integrate with all of our products. The distinction to note is that F# does not compete with C# but rather complements it such that the entire language platform is a holistic view on software engineering as a multi-faceted profession as opposed to an individualistic endeavor. F# should be viewed in a similar light as PowerShell.
2. F# does compete with Python, Haskell, Scala, Erlang. These are languages that folks are moving to. F# should openly compete with these. I have only spent time with Python in addition to F# and even then not enough to make a strong assessment. Focus communications on the positive aspect of using F# and the holistic view and not bashing other languages. I would like to see R added to this list, but today it can not.
3. Some top F# features to discuss: REPL, Type Providers, Discriminated Unions, Pattern Matching, Infix Operators, Immutability and Inline Types. I show these features every time I talk about F# and most of the advanced developers start drooling. Why? Because they are used to doing it the long way.
4. Talk Specifics. Regarding Conciseness, it’s not fair to do this by avoiding other languages features that are similar. Be open about that and discuss how and why the F# way is better. For example C# Linq vs F#. Use very specific examples. Also use specific examples with pattern matching.

Summary

F# I believe for a while has had an identity crisis. Today, F# has the ability to serve as a complementary language in the Microsoft Ecosystem as an option right along with PowerShell and C# to help Microsoft technologies remain competitive in the market due to its incredible features, capabilities and clean syntax. Unfortunately for F# to have this identity it needs to be accepted at a minimum into every single product at Microsoft as a first class citizen. If F# cannot do that, it is dead in the water. After full acceptance and integration such that future products are built with F# in mind, it can then begin integrating into other areas.

Post Note

My personal direction with F# due to the current ecosystem is: F# is becoming my general purpose programming language with C# thrown in there to fill many of my architectural and interop gaps while R is becoming my data science language. C# and C++ are my embedded systems languages. I would like to see my embedded systems language be F# and something better but just as performant as C++. R is replacing F# as my data language due to packages and adoption with SQL Server 2016, Azure ML, Data Factory and likely integration with Data Lake.

[ploeh]

@drcrook1 wrote:

Better [...] Serialization

This :+1: , only, not just for JSON, but _in general_:

• JSON
• XML (still quite popular, and necessary if you do _any_ serious integration work)
• Binary formats (protocol buffers?)

[WilliamOckham]

Perspective: I'm an enterprise developer with 20+ years on the MS platform (VB -> VB.NET -> C#) who started picking up F# about a year ago. I've done a lot of enterprise application integration (read that as the crap work nobody else wanted to do).

EntDevs are the center of gravity in the .NET community. We don't lead and we don't want to be left behind. By and large we are confused and worried about Microsoft's embrace of OSS. Not because we have any particular aversion to open source, but our bosses do and Microsoft put it there.

It's risky for us to go outside of the default stack (SQL Server on-prem, EF, C#, ASP.NET MVC, JSON.Net, JQuery and either Knockout or Angular 1.x). If we want to use anything else, we have to spend from our "we're techies keep us happy" budget and that varies widely from place to place and dev to dev.

What does all this have to do with F#? I think the way to drive F# adoption is create an alternative default stack and the only way to do that is to reclaim the space once held by VB classic - High productivity LOB app dev. Forget the C# devs, go after the folks who have stuck with VB.NET (or wish they had). Position F# as the advanced tool for the VB dev. Make Type Providers work with VB.NET. Get Microsoft and the community focused on that VB to F# transition. Call it the "Squirrelly braces, we don't need no steenking squirrelly braces" movement. Use Paket and FAKE to free us from the tyranny of MSBuild. Microsoft already has Visual Studio and VS Code. A Microsoft supported toolset based on Code w/Ionide plus enhanced VB support would rock. That's the community edition. Now, for the enterprise, you really need charge them some money, so bundle it with Xamarin's tools for cross-platform forms apps (because the Xamarin folks deserve the payday). Our managers would see the value-add of the Xamarin stuff. Add in an Azure subscription allowance, a bit of magic sauce for stuff like DocumentDB, Logic apps, and anything else that's marketed as "high-productivity".

The key is to put all this stuff together in a bundle that comes from Microsoft and has a SKU. The Forms UI layer should default to VB, but it should work well with F#. You could put a bunch of other stuff in there (Suave, F# to JS transpilation, etc.) and they would magically become part of this new default stack. That's one battle, not continuous warfare to justify each thing.

[eulerfx]

I can offer some insight from use of F# at Jet.com. We use F# as our primary .NET language (and .NET is our primary platform). However, there are still places that C# is used and some developers still tend to favor C# as their go-to language. Furthermore, it takes considerable time for a C#/Java veteran to become "fluent" in F#.

C# still used in a primarily F# environment

This is a consequence of the "upstack" issue that @dsyme outlined above. ASP.NET can be used with F#, but many teams prefer to create a shim C# layer to make it easier to deal with. The ASP.NET programming model - with controllers, methods as actions, lots of reflection, etc - doesn't make a lot of sense in a language like F#. Other teams opted to roll their own F# web framework - existing OSS libraries weren't deemed sufficiently mature/useful when these choices were made.

Some still prefer C

As far as I can tell, there are two reasons for this - 1) there will be those that will always favor an imperative language. This is perfectly fine and this is why I tend to agree that F# and C# can complement each-other. 2) Its simply a matter of time - it takes time to get comfortable in a new language, and even more time for a new paradigm. I think this will improve over time - more tutorials, more documentation, more books, etc.

[isaacabraham]

@drcrook1 Comments inline below: -

Microsoft Application and Data Platform Adoption of F#. F# is not supported in UWP, IoT Core, SQL CLR, Azure ML, U-SQL does not have an F# flavor. Data Factory supports C#, maybe F#, but has anybody tried it? If there are hard solution architecture blockers of this nature, support will be

• UWP - Officially on MS backlog (https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/9110134-f-support-in-net-native-for-uwp).
• SQL CLR - Does anyone actually use this? I know when it came out it was considered by MS to be a high priority and high value feature but since then.....
• Azure ML - Doesn't have C# support either. Unless you're referring to the web service code generator that you can do in about five minutes in F#? Having said that, I'd love to see F# support for custom tasks just like you can with e.g. R.
• ADF - all the workflows are just JSON at the end of the day. Unless you're referring to custom tasks - these are just .NET SDKs, so they are no more C# than VB .NET or F#. I actually worked with the ADF team during the early days of the SDK and wrote a (pretty complex) ADF pipeline adapter for Brisk which would have orchestrated e.g. Brisk Spark clusters via an ADF custom task. It was written entirely in F#. But to be honest there was nothing difficult in terms of interop - it was just implementing an interface or two and inheriting from an abstract base class or similar.

To be honest, 99% of the Azure SDK has no F# documentation on it but every one I've tried worked first time out of the box - there's really not a lot you need because it's just classes and interfaces, and F# has a good story for working with OO constructs when needed.

Integration in top tier software for data and analytics in supported packages. Top software packages need to be identified, prioritized and integrated. Right now we have primarily wrapper based solutions in which more common languages are the first class citizen. F# has to compete with that. Reference: Hadoop, Kafka, ZeroMQ, things of this nature.

Hadoop - by this do you mean Hive / Pig? Or more a big data framework? MBrace should be the first port of call there. Kafka / ZeroMQ - these to me are messaging frameworks - by the same token again that if you can use them from C# you can use them from F#.

Idiomatic Entity Framework Experience. Enough said. Entity Framework type provider would be ideal. Last I used the SQL Type provider, there was a ton of yak shaving that had to happen.

There is an EF type provider that comes with F#3.0, but it's for EF4.x, not the latest one. But I'm not convinced that you would want a TP for latest EF. EF6.x is all about code-first i.e. creating POCOs for your domain model, decorating them with attributes (or otherwise using fluent API) and generating databases from there, rather than the other way around. In such a situation, a TP doesn't make any sense. The SQLProvider is a very good type provider in an ORM style. You also have the SqlClient type provider which is slightly different - a bit more hands on with SQL - but it's also very, very good - I've written entire applications using this for the back end data access layer without problems.

Packages that accomplish simple common tasks. Time-Series, Linear Regression. There are packages out there, but who knows the quality of them? Bring those packages as core shipping components of F#.
Common Type providers shipping with the Microsoft blessing. I know that something on GitHub by Isaac Abraham or Thomas Petrick is likely safe. Those packages (particularly type providers) need to be adopted as core language capabilities that can be added as a reference that ships with the F# codebase and is supported by Microsoft. These type providers are the bell of the ball when I show off F# to my communities.

As important as some of these might be, I'm not sure that we want to add these as things that ship with F#; secondly, what would "supported by Microsoft" mean? Would this mean they are responsible for the quality of those products? Would they be liable if e.g. the Storage Type Provider had a bug that deleted all the data in a customer's Azure storage account? Yes, made available and / or included as nuget packages in starter templates would be great - but I'd be surprised to see any of these projects supported officially by Microsoft.

Better JSON Serialization of F# types to provide a standard the web UI devs expect. FSPicklr is ok, but try sending a Some/None or a discriminated union down to a UI dev and watch as your

Doesn't JSON.Net now support F# serialization? I must admit I'm not a massive fan of the way it serializes some types - I did a quite mockup of how you could write a better serializer for it here many months ago https://gist.github.com/isaacabraham/ba679f285bfd15d2f53e. I think someone else did a much more complete one though.

Better REPL referencing experience. I have to use #r to open something with a long path, and then I have to open it. If it is in my references, I should just do "open".

Power Tools does this pretty much out of the box now. Just right click the references node and choose the "Generate References to .fsx" option (or whatever it is). It generates an auto-updating script that contains all the references that you can #load easily. Perhaps some custom in-built VS tooling would be nicer, but with this generated script approach you can also use it from outside of VS.

F# does not compete with C#. F# and C# complement each other. C# if you look at it closely is built for the lowest common denominator in a developer shop, while F# is tuned more towards more advanced and capable developers. C# has its place, but at the end of the day there is code that is significantly simpler to write in F# than C#, the caveat is that F# has a learning curve to it that is

I'll disagree with you here. What you're saying is (IMHO) again part of the unfortunate misrepresentation of F# as somehow more complex than C# because it is in many ways more powerful than C#. The hardest part I see with C# developers adopting F# is not because it's more difficult to learn. It's because it's really, _really_ hard to unlearn OO as a way of problem solving. If it was the syntax that was difficult to learn then it would be hard to learn VB from C# (or vice versa) but this can be done in probably 24 hours. F# is an extremely flexible, general purpose programming language, that happens to push the functional programming style rather than OO, albeit it has scripting possibilities as well as opens the door to data science for .NET developers.

Definitely agree with you that I would like to see F# being considered as a "first class citizen" as part of the many new frameworks, libraries and services being developed by Microsoft though, although as has been shown over the past few years, if Microsoft don't, the community will often find a way themselves! :-)

[lambdakris]

Hopefully I'm not too late to the party. I am a recent adopter of F# and have been making the transition from C# to F# for everyday commercial use for the last 5 months.

getfsharp.org (.io, .net, .com, etc) & first class command line tooling:

Most trending languages/platforms such as Node.js, Go, Elixir, Clojure, and Haskell (through Stack) have a simple install of a command line tool which you can then use to launch an interactive/repl session or compile a file or even do dependency and/or task management. I know we have the F# SDK with fsc.exe and fsi.exe, but it would probably be nice to have a getfsharp web page with the first option being download and setup command line tools (no editor), second option Atom/VS Code with prepackaged Ionide (and a project workflow tutorial so that users are instantly aware of how to organize files for compilation), third option for Visual Studio Community, fourth option for CloudSharper, fifth option for MonoDevelop, and sixth option for Xamarin Studio (or something along those lines).

Relational Data Access

I know F# has a couple of celebrated data access libraries, including FSharp.Data.SqlClient and SQLProvider. However, in practice the SqlClient is really just a better ADO.NET and doesn't even have productivity functionality for query building and writes that some Micro-ORMs do. As for SQLProvider, the generated SQL is even slower than what is generated by EF 4.1+ which is unfortunate. It would be nice to have a typesafe, composable SQL DSL in the vein of jOOq for Java, Korma for Clojure, or Quil for Scala (there is linq2db in .NET but I get the feeling that something simpler and safer could be done with the F# type system and metaprogramming capabilities rather than rehashing LINQ and expression trees).
On top of the DSL one could then build Identity Map, Change Tracking, and Unit of Work together or apart and combine as necessary.

NoSQL and Queue drivers/adapters/wrappers for the top OSS products.

They don't have to be type providers or computation expressions. In fact, it would probably be best that they not begin in that way and just be plain old modules and functions. Here are my candidates in order or importance:

1. Cassandra
2. HBase
3. Kafka
4. RabbitMQ
5. Couchbase
6. MongoDB
7. Redis

FSProjects maintained and featured step by step tutorials for archetypal scenarios

1. create and deliver a crud webapp to azure (and choose/describe/recommend the preferred approach Web Apps, Cloud Service/Worker Role w/ Self-Host, Service Fabric w /Self-Host)
2. create and deliver a crud webapp to aws (Beanstalk, VM w/ IIS, VM w/ SelfHost)
3. create and deliver a deamon/svcapp to azure (and choose/describe/recommend the preferred approach Web Apps, Cloud Service/Worker Role w/ Self-Host, Service Fabric w /Self-Host)
4. create and deliver a deamon/svcapp to aws (Beanstalk, VM w/ IIS, VM w/ SelfHost)
5. create and deliver a combination of crud webapp and deamon/svcapp connected by messaging/queue tech to azure
6. create and deliver a combination of crud webapp and deamon/svcapp connected by messaging/queue tech to aws

[dsyme]

@lambdakris Those are very, very good suggestions. All of them very "fresh" in the ecosystem. Let me know what I can do to help recruit people to help implement those. And please lead the way in making them happen - they are very good suggestions indeed.

[swlaschin]

@lambdakris Excellent suggestions! I just snagged getfsharp.org -- it's a great idea to have a site that is all about getting started and nothing else.

[dmitry-a-morozov]

Guys stop worrying about about idiomatic type provider for Entity Framwork.
Santa heard you - it's here.
https://www.nuget.org/packages/FSharp.EntityFramework.MicrosoftSqlServer
I will write some docs soon. Feel free to grab the package - it works.
It's EF7 and SqlServer only. I hope community will step in and do other databases.
I don't think there is a point to support EF6.* and below.
I will transfer project to fsprojects over holiday season.

[drcrook1]

@dmitry-a-morozov no way. This brings up a point. Is there a consolidated list somewhere of awesome packages we should all be using?

[dmitry-a-morozov]

@drcrook1 It was intentionally hidden Christmas present.

[dmitry-a-morozov]

@lambdakris Writes support in FSharp.Data.SqlClient http://fsprojects.github.io/FSharp.Data.SqlClient/data%20modification.html

[simontcousins]

As others have said, to drive F# adoption there needs to be a friction
free way of getting started. F# needs a command line tool that pulls
together project management, dependency management and build (see
Rust, Go, Node etc). That's it!

I have been a .NET (C#) developer since 2001 and I have been using F#
professionally since 2008. Since 2008 I have written many different
types of applications and components either exclusively or
predominantly in F#. Without question, switching to F# profoundly
improved the quality of the software that I and the teams I work with
deliver. F# is the most effective language on the .NET platform.

Eight years in I realise there are things that used to concern me that
I no longer worry about because they are no longer relevant and/or have
not turned out to be a problem in practice - this includes: hiring F#
devs, C# interop, Microsoft upstack components and Visual Studio tooling.

Let the legacy languages dominate legacy platforms. Drive F# adoption by
helping developers work with F# anywhere on anything on future platforms:

Target command line tooling
Target cross-platform
Target the cloud
Target open source upstack

and hope Microsoft continues to push .NET

[dadhi]

I will talk from perspective of switching from C# to F#. C# is mostly an OOP language and it is good at it. C# as language designed to resemble other OOP managed languages (e.g. Java), and that way allowed an easy adoption:

• I don't need to switch mind set.
• I don't need even to be accustomed to new strange syntax (_it is very similar!_).
• I know how program is structured and how to follow the code.

Only after that I am starting to consume new features (_hey I can use functional stuff too_) and whole goodness of tooling, etc.

I recall my personal experience when I've discovered F# and started to dig into the great @swlaschin and mind-blowing @tpetricek blogs (Thank you guys BTW!).
And everything was amusing and natural when I was looking into examples of functional programming.

But every time I saw the definition of type/class in "classical" OOP meaning I have a feeling, that this thing is out of place, something foreign to the language. Particularly the syntax seemed wordily, hard-to-remember and not consistent. And the main thing: F# OOP did not resemble C# at all. Why?

I expect from the new language to remove boilerplate things and noise from my current language _in the same field_. But not to reinvent the same with other words which is hard to follow (_in the same field_). For instance absence of curly braces is a good thing to be more concise and productive.
But the abstract member is not.

_The above is my IMO and personal exp, which may be different for you._

The last thing:
+1 To better tooling - ReSharper is the most. Or we should have a capable alternative.

[forki]

Regarding ReSharper: there is a hen and egg problem here. F# is not interesting for a company like jetbrains since we have not enough users (and probably will never have to make good money with a refactoring tool). Also jetbrains is probably not that happy with Microsoft doing roslyn-based tooling even if they say that they are still way ahead. In other words: there will probably never be a R# for F# and there is nothing we can do about it. Our best hope is to improve FCS which powers FsAutoComplete tools like ionide and of course the powertools.
We as a community and MS as vendor should try to make these projects great.

[enricosada]

@simontcousins xplat tooling ( works this time, really ) is http://github.com/dotnet/cli
It's exactly what you need.
And is going to support f# soon

[enricosada]

as a side note about ms sdk, i think now is easier to add samples to microsoft from community.

for example powerbi

there is https://github.com/Microsoft/PowerBI-CSharp

We are going to open source our PowerBI API SDKs and samples to enable the community to quickly create application based on our API. This is the CSharp version

there is also https://github.com/Microsoft/PowerBI-JavaScript obv

and add link into https://powerbi.microsoft.com/en-us/documentation/powerbi-developer-introduction-to-creating-a-power-bi-app/ ( see Power BI samples section )

[panesofglass]

@drcrook1 @isaacabraham I've used F# with SQL CLR previously. You have to upload FSharp.Core to make it work, but I found it worked rather well, if a tad more difficult than doing the same with C#. I eventually ported it all to C# b/c that's what the client wanted, but I prototyped and fixed some perf issues in F# first.

[lambdakris]

@swlaschin @dsyme Cool! With regards to getfsharp.org, perhaps you can point me in the right direction/people. What would be the typical setup for a fsfoundation/fsprojects website? Should the getfsharp effort begin with the existing Visual F# 4 Tools or a newer community release or one of the newer MS releases, or one of the newer open edition releases, or something new that encapsulates and orchestrates the installation of .NET + Win SDK + MSBuild + 'fsharpRelease? (Ironic that the installation process for nix just seems to be install Mono...)

[panesofglass]

@dsyme @KevinRansom I see that someone from Microsoft owns http://fsharp-lang.org/, but it is not in use. (I just went to try to register it.) Is this something we could use for hosting documentation? It would align well with other OSS languages like http://rust-lang.org/, http://elixir-lang.org/, etc.

[7sharp9]

@lambdakris Yes, mono includes a tagged version of F#4

[swlaschin]

@lambdakris I think I'll set it up as github pages for now, and then people who want to contribute can, and it also will provide a place for discussing issues specifically for that. As to moving it into fsprojects, that's not my decision :) and also I think that we should play with it for a while and see how it goes, and if it is useful.

@panesofglass Re hosting docs, I don't see why we can't do that on fsharp.org, (or docs.fsharp.org to keep the git repo separate). I would hope that docs are a neutral enough topic :) and I imagine we would use a licence like cc-by-nc-sa so people could fork if they choose.

[7sharp9]

It would be nice if documents were available in an open source open license fashion, like the docset format. That way tools like https://kapeli.com/dash and https://zealdocs.org can be used to display and browse docs. Mono already has a docset available, it would be nice if FSharp.Core was available and maybe some of the other fsproject projects and language guides.

[swlaschin]

@lambdakris @panesofglass and everyone else, I've set up a (very basic) skeleton site at http://getfsharp.org/ and the repo is at https://github.com/swlaschin/getfsharp.org

Please start adding issues if you like.

I've also added one on the role of getfsharp.org itself!

Thanks!

[battisti]

Did anybody here who thinks that F# has a good cross platform story actually use it on OS X or Linux? Compared to e.g. Rust or Elixir the *nix command line experience of F# is highly frustrating.

[jeroldhaas]

@battisti what sort of frustrations have you had?

[battisti]

@jeroldhaas apart from having to install mono, npm, yeoman, yeoman F# generator just to set up a simple console application project, having to mess around with the fsproj, paket.dependencies and later build.sh/.cmd/.fsx files just to get some unit test running, neither the Atom nor VS Code Ionide plugins work out of the box.

[7sharp9]

With Osx you can easily just use MonoDevelop/XamarinStudio along with mono.

[battisti]

@7sharp9 I know, but there are good reasons why someone might prefer not to use MonoDevelop/XamarinStudio.

[forki]

@battisti most of the stuff is not needed. Seems that latest blog posts give a wrong impression.

[battisti]

@forki what do I need to setup a simple console application project with unit tests and external dependencies (say e.g. MathNet.Numerics) on a Unix system?

[forki]

Basically the same as for C#. You need mono, a compiler, a unit test framework and for dependency management (if you don't want to do it manually) nuget.exe or paket.exe.

[battisti]

So there is no need to manually create a .fsproj or .sln file and use it to wire up the unit test framework, the external dependencies with the test and application code?

[forki]

Sure it is. But that's the same with C#.

If you look for more complete solutions then look into things like
https://github.com/fsprojects/ProjectScaffold
We try to make it as xplat as possible. There is constant improvements.
On Dec 23, 2015 11:53 PM, "Alexander Battisti" [email protected]
wrote:

So there is no need to manually create a .fsproj or .sln file and use it
to wire up the unit test framework with test and application code?

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

[battisti]

@forki "not worse than C#" is a poor argument to drive F# adoption :)

[smoothdeveloper]

@battisti could you describe what you'll be looking for? What other eco-system are you used to and how do they differ from current experience with F# eco-system?

What is the experience like with paket on *nix? it seems it's a good way to bootstrap your environment to get dependencies (nunit runner, fake).

I think one direction to look at is work on haskell stack and how it wraps other key pieces of haskell eco-system (ghc, cabal, haddock, etc.) and provide a single entry point to initialize / manage projects.

This is probably an effort which is best handled/pursued by the community.

Also, there are efforts taking place in other parts of dotnet eco-system by Microsoft (dotnet command line), those projects driven by MS need to take F# as a first class language upfront rather than later down the road.

[battisti]

@smoothdeveloper to use F# on OS X you have to the following (I assume Linux is similar) – of course this is _not_ documented on fsharp.org.:

brew install mono
git clone https://github.com/fsprojects/ProjectScaffold.git
cd ProjectScaffold/
./build.sh
... answer a bunch of questions

This results in more than 200 lines of poorly formatted, hard to read log spam of which maybe 20 lines contain actual valuable information, the rest is noise.

What is structure is created to support this simple hello world project:

1 .sln file (60 LoC XML)
1 build.fsx file (_400_!!! LoC F#)
2 .fsproj files (75 and 90 LoC XML)
3 "paket" files
1 AssemblyInfo.fs (10 LoC F#)
3 helper Scripts (build.sh/.cmd 35 LoC bash and generate.fsx to generate documentation)
and an additional F# script file

I assume, that whenever you add, remove or rename a source file or a add a dependency you have to edit at least one of the .fsproj files, that you have to change the value of the OutputType node from "Library" to "Exe" to create a console app instead of a DLL. Again none of this can be found in easily accessible documentation.

This might be acceptable when using an IDE taking care of all this, but for a command line interface this is absurd.

Let's try the F# Yeoman Generator:

brew install mono
brew install npm
npm install -g yo
npm install -g generator-sharp
yo fsharp
... answer a bunch of questions

It doesn't inspire a lot of confidence that a supposedly great programming language does not have a dedicated scaffolding tool but instead is using a tool from a supposedly horrible programming language and the additional installation steps are annoying but the result of 30 lines of readable, actually useful console output... nice.... next...

cd hello_world
./build.sh
25 lines of noisy compiler output... not nice but at least not horrible

Look what has been generated, a single fsproj (70 LoC XML) and paket file an App.config file (for whatever this might be useful) and a single source file... again not horrible, but not really good either.

But, how do I create Unit Tests and wire them up with the project? Move my source files from the top level to a src directory? I assume I have to mess around in the fsproj file but I have no clue how and what to do as the fsproj format is an undocumented mess even for somebody who is accustomed to maven. If I had to guess here your are loosing maybe 30-50% of all developers who took the time to look into F#, of the remaining you'll loose 90% when they can't find out after an hour of googling and those who remain and find out what is necessary (probably involving a little bit of reverse engineering using the output of Xamarin Studio) will drop out the moment they realise this.

But let's pretend this is not an issue and continue by adding MathNet.Numerics.FSharp as a dependency:

Add a single line to paket.dependencies

mono .paket/paket.exe install
5 lines of useful readable console output.... nice!

add the simple hello world example to the hello_world.fs

module hello_world

open MathNet.Numerics.LinearAlgebra

[<EntryPoint>]
let main argv =
    let m = matrix [[ 1.0; 2.0 ]
                   [ 3.0; 4.0 ]]
    let m' = m.Inverse()
    printfn "%A" m'
    0 // return an integer exit code

./build.sh

error FS0039: The namespace or module 'MathNet' is not defined

Great, so reading the getting started section at fsprojects.github.io/Paket tells me that I also have to add a paket.references file and add MathNet.Numerics to it. Because obviously when I install a dependency in a project the common case is that I only want this dependencies to fill up my repository and NOT use them in my F# source files! I am sure that there are great reasons why having to repeat the information in the paket.dependencies in the paket.references file is in fact a good thing, but it is annoying.

mono .paket/paket.exe install
build
mono ./bin/Debug/hello_world.exe

I finally get my output.

So how does this compare to e.g. Cargo and Rust (Mix and Elixir will have a nearly identical experience)

brew install rust
cargo new hello_world --bin
cd hello_world
cargo run

=> 3(!) lines of useful, easy to read output. One of that is the default output of a new project (e.g. "Hello, world!").

So what is generated:

A Cargo.toml file (roughly the equivalent to paket.dependencies and paket.references as well as providing most of the use of the build.fsx and build.sh/.cmd files) a src directory with the main.rs source file and a target directory!

Let's look into the toml file. _6_ lines!!! This includes everything needed to run unit, functional and performance tests (part of the language) as well as documentation generation. Let's add a simple dependency.

Add a single line to the Cargo.toml file, which now looks like that:

[package]
name = "hello_world"
version = "0.1.0"
authors = ["AB <[email protected]>"]

[dependencies]
rustlearn = "0.2.0"

add code to source file,

cargo run
... done!

what do I have to do to add tests?

mkdir tests
vim tests/my_test_file.rs
=> write your tests
cargo test
... done! (there are even simpler ways to add tests, but these are provided as language features)

How does this look when projects grow beyond hello world:

• piston: 1.6k commits, 50 contributors, 2.5 kLoC -> 40 line toml
• nickel.rs: 500 commits, 30 contributors, 2.5 kLoC -> 95 line toml
• mio: 300 commits, 40 contributors, 6 kLoC -> 45 line toml
• rustlearn: 24 commits, 1 contributor, 17 kLoC -> 35 line toml

I have no experience with stack, it has been a couple of years since I played around with the Haskell Platform and for me the experience with the infrastructure (Cabal and friends) hasn't been great, but it is likely that things have improved.

[enricosada]

@battisti it's not working with F# atm ( but will soon ), something like http://dotnet.github.io/getting-started/ is a simple experience you think it's ok?
pls try it, it's csharp, i know, but project.json and commands are going to be the same for f#

[enricosada]

or as usually an amazing work from @7sharp9 , http://7sharpnine.com/Xebec/

[battisti]

@enricosada yes thanks the

dotnet new
dotnet restore
dotnet run

workflow looks nice (also the generated files look good, assuming that it is reasonably easy and documented on how to add unit test etc.) BUT the current version terminates with a:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Console, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

when calling

dotnet run

Xebec does look amazing (like Cargo for F#)!

[forki]

Yes there are really good reasons to split paket.dependencies and
paket.references - I hope the docs explain that well enough.

Regarding projectscaffold. Yes the build script is large because it really
does a lot - including deployment to multiple yargets. Again the docs show
you what it does. If you want to know how projects grow with this approach
then look into the Paket project. We have over 5000 commits, it works xplat
and I shipped over 1000 releases with basically the same stuff that is in
projectscaffold. It really works.

Regarding fsproj files. Yes that's super annoying. Many people tried to
come up with something different, but all projects "failed" because it
would always mean a fork in the ecosystem and making things incompatible to
the standard Microsoft stuff. I hope xebec succeeds.
On Dec 24, 2015 17:04, "Alexander Battisti" [email protected]
wrote:

@enricosada https://github.com/enricosada yes thanks the

dotnet new
dotnet restore
dotnet run

workflow looks nice (also the generated files look good, assuming that it
is reasonably easy and documented on how to add unit test etc.) BUT the
current version terminates with a:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Console, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

when calling

dotnet run

Xebec does look amazing (like Cargo for F#)!

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

[enricosada]

@forki if it's possible to fix dotnet restore ( because nuget has it's problems ), i think project.json is the same as xebec, only json instead of toml.

For example development-dependencies are going to be merged soon

And dotnet ( the command is only a tool to call csc or fsc, really, install dotnet cli and do where csc ) package is going to be nice, to install coreclr instead to use dnvm directly.
It's not dnx, with in memory compilation, plugin system etc.

Bonus point, project.json give us xproj in visual studio, a common project system for both c# and f#, so less problems.
Sucks it's json because no comments, toml or yaml where better solution, but still.
If we can teach dotnet compile to understand xebec project format to read source files, and dotnet restore to read xebec or packet, it's going to works good, because dotnet-compile-fsc.exe has source files as command line args, doesnt read project directly

{
    "version": "1.0.0-*",
    "dependencies": {
        "Microsoft.FSharp.Core.netcore": "1.0.0-alpha-151221",
        "System.Runtime": "4.0.21-beta-23428",
        "System.Console": "4.0.0-beta-23428"
    },
    "compilerName": "fsc",
    "compileFiles": [
        "Helper2.fs",
        "Helper.fs"
    ],
    "frameworks": {
        "dnxcore50": { }
    }
}

problem is always restore, source files, and compiler args. the rest is fsc al the way down

[enricosada]

@battisti just run the ./bin/Debug/dnxcore50/file.exe after dotnet build no magic there
the dotnet run is only an helper for restore+compile+call exe. , see Microsoft.DotNet.Tools.Run/README.md, try dotnet restore + dotnet compile. or open a bug :smile:

[forki]

I know that dotnetcli is a way out, I hope they hear our feedback.
On Dec 24, 2015 17:41, "Enrico Sada" [email protected] wrote:

@battisti https://github.com/battisti just run the
./bin/Debug/dnxcore50/file.exe after dotnet build no magic there
the dotnet run is only an helper for restore+compile+call exe. , see
Microsoft.DotNet.Tools.Run/README.md
https://github.com/dotnet/cli/blob/master/src/Microsoft.DotNet.Tools.Run/README.md,
try dotnet restore + dotnet compile. or open a bug [image: :smile:]

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

[7sharp9]

I have no idea how the new coreclr works or how the correct target gets used for the dnx stuff. The idea behind xebec is to make things easier rather than the complicated mess that exists in proj files. First support will be for vscode, atom, and emacs, and that's right after command line support for building, running and testing etc.

On 24 Dec 2015, at 17:54, Steffen Forkmann [email protected] wrote:

I know that dotnetcli is a way out, I hope they hear our feedback.
On Dec 24, 2015 17:41, "Enrico Sada" [email protected] wrote:

@battisti https://github.com/battisti just run the
./bin/Debug/dnxcore50/file.exe after dotnet build no magic there
the dotnet run is only an helper for restore+compile+call exe. , see
Microsoft.DotNet.Tools.Run/README.md
https://github.com/dotnet/cli/blob/master/src/Microsoft.DotNet.Tools.Run/README.md,
try dotnet restore + dotnet compile. or open a bug [image: :smile:]

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

—
Reply to this email directly or view it on GitHub.

[battisti]

The quality of the Ionide plugin (version 1.2) with VS Code on OS X using Mono 4.2 stable (using the package installer, not homebrew) improved a lot. It is now usable out of the box and the debugger works (most of the time). The fsproj files are still annoying though.

[jpierson]

I don't understand the desire for templates as a way to improve things. I've never been in the habit of using any kind of project template and always see the need for them as a failing of the language, framework, or ecosystem in general. One of the things I've been appreciating about F# is how expressive yet concise code can be. An example is canopy, no real reason from what I can see to have canopy templates because the API/DSL exposed is exactly what you need to write and nothing more.

My hangup has been msbuild/.fsproj baggage and the single pass compiler. I'd prefer the Node.JS experience in terms of lightweight projects that can consist of only dependencies, language/tooling constraints, and code in a nice digestible text based format (preferably code itself such as with Fake). I think these things should lower the barrier to great IDE and editor support because it doesn't not lean so heavily on an IDE support for ordering of files in a project and to add remove dependencies.

On a slightly related note, I really like what Rust is doing with Cargo and was excited to see similar things coming to .NET Core but unfortunately that stuff was recently announced as something that will be retired before 1.0. At this point I'm starting to question what advantages I really have building off of the existing .NET framework, F# and .NET Core are the main things keeping me interested but I'm finding that TypeScript, Node.JS, npm is quite a reasonable alternative without the _baggage_. Anything that moves F# toward lightweight and flexible tooling will keep me interested and the inverse is also true.

[isaacabraham]

@jpierson Have a look at paket manager - particularly v3 (currently in alpha) which can generate dependency scripts to reference all nuget packages as well as all the other goodies like nuget package dependencies, github dependencies etc..

FWIW I agree that lightweight tooling with emphasis on code first is the way to go. Not sure I would want to lose built-in prevention of cyclical dependencies but getting rid of the heavyweight .fsproj yes.

[smoothdeveloper]

@jpierson just on this matter:

I don't understand the desire for templates as a way to improve things

There are many aspects regarding this kind of concern, I also am better with lean project, empty template but in context of driving adoption within .net eco-system, anything which is available to C# and VB.NET but for some reason is not available to F# (despite, in the grand scheme it wouldn't cost so much to have it implemented), such as winforms & WPF designers, project templates for MS frameworks, all which is related to IDE tooling, etc. is a significant hinderance toward getting F# being adopted.

My experience with the language is short but I faced this big time already, people tend to get iffy when they see this MS language but at the same time, the support is not as "first class" as with C# and VB.NET.

Outside of .net land, I mostly agree with all you bring :smile:

[dsyme]

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

[Bartolomeus-649]

The reason I don't use F#

• I don't know F#
• I know C# and it solves my problems rather good most of the time.
• When I search for something all I see is C# (and sometimes VB) solutions and examples.
• My existing code base is in C#
• Never meet an F# developer, do they even exists? Where would I find an F# consultant or employee?
• Most of my code basically consist of fetching some data from a DB, modifying it a bit and then send it on to the client for display, or getting some data from the client, modifying it a bit and then writing it to a DB. It's kind of hard for me to see how F# could do this better/easier than C#?

[forki]

Many of us are on github, slack, Twitter,... We do exist

[Bartolomeus-649]

Yeah...heard the same argument about Jesus ;)

What I mean is, if you have system written in F# and go look for a consultant or an employee to hire, would you find any?
It's a risk when using anything but C# in a dot.NET project.

[isaacabraham]

@Bartolomeus-649 you can google "f# consultancy" and you'll get some results (and even "F# Azure Consultancy" if you feel really dangerous ;-)).

Seriously though, the points you make are all very common ones so you're not unusual there. In my upcoming book I discuss basically all of these issues and concerns. In short: -

• Yes, you can find F# people (and cross train from C# / VB or other platforms easily enough). Jet basically built their entire development team this way.
• That "I know C# and it solves my problems rather good most of the time." absolutely drives me crazy (not having a pop at you - a lot of people say it). It suggests that there's a way to quantify how good "rather good" is, and assumes that what we know now is all there is out there. I certainly thought when I was using C#2 that it was "rather good" for solving problems, but when C#3 came out, I realised how ineffecient some of my solutions previously had been in comparison.
• Regarding the client/logic/db area - F#'s tagline is that it solves difficult problems with simple code. However, it also solves simple problems with really simple code. We do this quite often for our customers.

[Bartolomeus-649]

@isaacabraham , none of those arguments will make me use F#.

The next time my customer want something, I will need to provide a solution that is better than my competitors, else I will not be doing any coding at all.

And if I would present a solution based on F#, I would not get the job.
I would have to deal with questions like: Why I don't just use C# like everyone else, or Why introduce a new language into our environment that noone else but you seem to know?

Also the cost for a C# solution would be higher than one for C# since either would I need to spend my own time learning F# or I would need to get the customer to pay for the extra time needed for me to learn enough about F# within the project.

The only way to get F# of the ground is for Microsoft to present a nish use for F# where it clearly outperform other languages like C# and VB.NET.

And then there need to be an F# extension for C#, so you could just do some F# stuff with C#, so people will start to understand what F# is all about without switching to F#.
Sure, this F# extension for C# would not allow you to do all that F# can do, but perhaps some of it can be emulated and giving C# a touch of F#.
This would make it a non-issue to use the real F# once people has started to get used to it and start to understand what F# is.

If possible, F# should be just merged in with the next version of C#.

[isaacabraham]

@Bartolomeus-649 I can only speak from my own experience. We use F# because it gives us (and our customers) a competitive advantage as we can deliver reliable, performant and maintainable solutions more quickly and cheaply than we would with other languages. YMMV. The "why not just use C#" argument goes back to my point regarding C#2 vs C#3.

And you can't merge F# into C# - have a look at the C# language repo and witness all the crazy ideas of how some of that would look for a start. But more than that - F# and C# have very, very different goals and ways of doing things. If you just took the ideas of F# and put them into C#, you'd end up with a crazy, crazy language with no clear identity (not to mention many F# features would be massive breaking changes in F#).

You're free to use whatever language you feel like. I'd suggest you at least have a crack at F# though - you might find it dispels some of the FUD you might've been exposed to previously.

[jamessdixon]

I sincerely hope my competitors stick with java/C# - and more importantly,
continue using the same mindset that keeps them there....

On Sun, Apr 30, 2017 at 8:46 AM, Isaac Abraham [e-mail]
wrote:

@Bartolomeus-649 https://github.com/Bartolomeus-649 I can only speak
from my own experience. We use F# because it gives us (and our customers) a
competitive advantage as we can deliver reliable, performant and
maintainable solutions more quickly and cheaply than we would with other
languages. YMMV. The "why not just use C#" argument goes back to my point
regarding C#2 vs C#3.

And you can't merge F# into C# - have a look at the C# language repo and
witness all the crazy ideas of how some of that would look for a start. But
more than that - F# and C# have very, very different goals and ways of
doing things. If you just took the ideas of F# and put them into C#, you'd
end up with a crazy, crazy language with no clear identity (not to mention
many F# features would be massive breaking changes in F#).

You're free to use whatever language you feel like. I'd suggest you at
least have a crack at F# though - you might find it dispels some of the FUD
you might've been exposed to previously.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/798#issuecomment-298230184,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVH1LUCF_whJ_Oz7qS5S9p_lNm8HKxCks5r1IKsgaJpZM4G2wxq
.

[Bartolomeus-649]

@jamessdixon So why this thread about driving F# adoption?

[jamessdixon]

If you are not my competitor, have at it. In fact, I am happy to help you.
:-)

On Sun, Apr 30, 2017 at 8:52 AM, Bartolomeus-649 [e-mail]
wrote:

@jamessdixon https://github.com/jamessdixon So why this thread about
driving F# adoption?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/798#issuecomment-298230447,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVH1IFppns3Kku6z7YtZssA7d5U2R6kks5r1IQVgaJpZM4G2wxq
.

[ploeh]

Where would I find an F# consultant or employee?

Easy, just advertise for one: http://blog.ploeh.dk/2015/12/03/the-rules-of-attraction-language

[forki]

And if I would present a solution based on F#, I would not get the job.

Many people here try to present something that works and has fewer bugs and has short time to market. Sometimes that happens to be written in F#. The advantage is often there but if you think differently or want to ignore it then this is fine. I won't force you to do F#. At least as long as you are not part of my team.

[cartermp]

Locking, as the conversation is closed and has drifted far from ways to increase F# adoption.