search

dotnet / fsharp

The F# compiler, F# core library, F# language service, and F# tooling integration for Visual Studio
https://dotnet.microsoft.com/languages/fsharp
MIT License
3.82k stars 773 forks source link

How to drive F# Adoption - Part 1? #798

Closed KevinRansom closed 7 years ago

KevinRansom commented 8 years ago

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 commented 8 years ago

My List:

jamessdixon commented 8 years ago

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

rodrigovidal commented 8 years ago
eiriktsarpalis commented 8 years ago

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

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 commented 8 years ago

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

lefthandedgoat commented 8 years ago
jeroldhaas commented 8 years ago

+1 on macros, compiler extensions

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

7sharp9 commented 8 years ago

Add more value to the core language:

forki commented 8 years ago

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" notifications@github.com 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 commented 8 years ago

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.

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

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 commented 8 years ago

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 commented 8 years ago

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

dsyme commented 8 years ago

Awesome discussion.

Language

Compiler and build

Visual F# Tools:

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

rodrigovidal commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

@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" notifications@github.com 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 commented 8 years ago

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

7sharp9 commented 8 years ago

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

misterspeedy commented 8 years ago

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 commented 8 years ago

By that same logic we should add more curly braces to the language. ;-) On Dec 16, 2015 22:44, "Rodrigo Vidal" notifications@github.com 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 commented 8 years ago

+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 commented 8 years ago

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

rodrigovidal commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago
Getting people to try at all

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
gsobocinski commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago
KevinRansom commented 8 years ago

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

Kevin

bleis-tift commented 8 years ago

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 commented 8 years ago

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

ForNeVeR commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

Indy9000 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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

Indy9000 commented 8 years ago

@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 commented 8 years ago

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

Indy9000 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

@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: