[MadsTorgersen]

You're seeing us strike a balance here. As I point out in the post, there are millions of C# developers, and tens of thousands of F# developers.

However, we think F# has awesome growth potential, and is great for .NET in general. So while we can't defend spending the same resources on it as we do on C#, we want to do what it takes to nurture it and keep it healthy and growing.

Being on the inside at Microsoft over the past years, it's been great to see more and more of the organization think of F# as part of the family.

[smoothdeveloper]

Agree with other comments, back then MS invested a lot in C# while there was then way more VB users, now it should invest a lot on F# while there are way more C# users.

C# isn't going to dwindle because F# expands, if F# expands C# wins because F# has ability to appeal to developers on non .net platforms, where C# isn't seen as appealing, and F# has ability to bring outstanding projects and idioms to .net eco-system.

Take the returns on investment made with C# all those years and invest a fair share in F#.

The main reasons F# is not picking up have been stated, and I face this situation at my work where my use of F# is put on hold because Microsoft is not investing in it much and my colleagues have the feeling C# is "good enough" which is very short sighted perspective.

[strmpnk]

While I'm already one of the few that use F# full time, I think this is a rather self-fulfilling statement. Looking back in time, Microsoft has continually cubbyholed the language, almost to the point of counter-marketing its general purpose feature set.

Simply giving it a fair share per-developer after so many years of mismanaged commercial handling seems to fall short. You say yourself, F# has awesome growth potential and I'm sure you'd agree that the growth potential has been there for years now. Is this time around going to be different?

I hope so.

[oblio]

In my opinion Microsoft should focus more on base tools for F#, such as Roslyn, integration with dotnet core, etc.

Integration with Visual Studio is nice, but if the language is to be adopted in hacker circles, without major Microsoft investment, it needs to provide very solid and flexible tools on top of which the community can build awesome things.

Example of small things Microsoft can help with: as far as I can see Nuclide doesn't work with dotnet core (only Mono). Throwing 1-2 devs that way would pay good dividends, in my opinion.

[wluu]

> Example of small things Microsoft can help with: as far as I can see Nuclide doesn't work with dotnet core (only Mono). Throwing 1-2 devs that way would pay good dividends, in my opinion.

I don't know anything about Nuclide, but if they want to work with dotnet core, they should look into working with omnisharp-roslyn[0]. VS Code[1] and Atom[2] both have extensions that work with it.

> In my opinion Microsoft should focus more on base tools for F#, such as Roslyn, integration with dotnet core, etc.

I think there's already work underway for F# support for dotnet core[6].

As far as F# support for editors go, have a look at ionide[4]. They only have extensions for VS Code and Atom at the moment.

> Integration with Visual Studio is nice, but if the language is to be adopted in hacker circles, without major Microsoft investment, it needs to provide very solid and flexible tools on top of which the community can build awesome things.

Have you seen omnisharp[5]? If so, what's missing from that?

[0] https://github.com/OmniSharp/omnisharp-roslyn

[1] https://github.com/OmniSharp/omnisharp-vscode

[2] https://github.com/OmniSharp/omnisharp-atom

[3] https://github.com/Microsoft/language-server-protocol

[4] http://ionide.io/

[5] http://www.omnisharp.net/

[6] https://github.com/dotnet/netcorecli-fsc

[enricosada]

About F# and .NET Core, you can read more info (usage/bugs/workaround) in the wiki https://github.com/dotnet/netcorecli-fsc/wiki/

The only ide who support f# and .net core is VSCode (with Ionide extension who add f# support)

see

- https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... for LTS of .net core 1.0 (project.json)

- https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... for msbuild based (latest bits)

[oblio]

I meant Ionide. Ionide works with/on Mono.

[runT1ME]

Think how many developers you could add by adding Higher Kinded Types to F#. You could poach a ton from Scala/Haskell land. Alas, many of us can't leave until that happens. :)

[daxfohl]

It really needs to be added at the dotnet level. I'd love to have it in C# as well. LINQ expressions should work on arrays, ienumerables, lists, iobservables, subjects, nullables, etc, basically anything monadplus, and return back what you passed in. It's silly to have to write the same expression for each of those cases, or to convert everything to ienumerable/iobservable and back by hand. I'm surprised they didn't take the opportunity to do that in dotnetcore. It's mainstream enough now that I'm curious why they didn't; whether the perceived need was low or whether there are other problems it would have introduced.

[louthy]

My reply here [1] may be of interest :)

[1] https://news.ycombinator.com/item?id=13547181

[MichaelGG]

But that's a catch-22 isn't it? There's few users in large part from not just tooling but messaging. MS has pitched F# as a specialised language for scientists and financial work.

But I do appreciate the work MS does - F# is a leader in FP tooling. And C# is getting easier to deal with :).

[hvidgaard]

You have a business to keep running, I respect that. But if you truely want to bring innovation to the regular developer, bump up your F# efforts.

It needs a significant effort to educate developers to develop in a truly functional way. You are on track to implement many FP constructs and patterns into C#, so I'm sure the F# efforts would not be wasted at all.

[Tsarbomb]

Preface: I really love what you guys are doing but...

I really don't think you guys appreciate how many Scala/Clojure/Haskell devs would love to work in F# but can't because of the tooling.

Also equating the type of work being done with C# to the type of work being done F# by just comparing developer numbers is incredibly naive.

[systems]

I think they do, and this is why they giving it any resources at all while admitting they only see it used by tens of thousands, compared to millions using c#

At the end of the day, MS is a big corp, decisions needs to be justified and supported by both quantitative and qualitative measures

Also on the bright side, in programming, more developers doesn't really mean it will evolve faster, actually with a smaller team f# may evolve faster, it this wasn't true no language other than c# or java would have stood a chance

[kartickv]

I agree with the other comments as well, that treating F# as a second-class citizen is a self-fulfilling prophecy.

As someone who was telling myself, "One day, I should learn F#", this thread makes me pause.

Throw all your weight behind it, make it a first-class citizen, and Microsoft may be the first to make functional programming mainstream. That would be exciting.

[jackmott]

just make folders work properly on F# solutions and I'll send beer/wine, whatever you want.

[daxfohl]

I'd like to see more of a focus on extension methods rather than the pipe operator in tutorials and such, and tupled args rather than curried args. Also make the OO aspects more visible. It's not so much a language thing as a presentation thing. I think these are the things that confuse mainstream developers, and it's silly to present them all up front when teaching the language. Intellisense and C# compatibility works way better if you go this route too.

[willtim]

If you want "OO aspects", you can use C#. F# should focus on being a functional language. Features like currying exist for a reason.

[MichaelGG]

F# is multi paradigm though. It's just that, especially when looking locally at code, functional style is just way better.

[willtim]

C# is also multi-paradigm, or certainly well on its way, as it gets more and more functional features. F# needs to be functional-first.

[daxfohl]

In four years full-time F# use, I still find standard LOB apps work better with an OO SOA structure at the high level. I've tried various methods of designing FP-style architectures for those apps but nothing has ever ended up nice and clean as a standard interface-based SOA (in F#) and a standard OO DI utility. At the low-level, F# is awesome for immutable records, ADTs, combinators, etc., in a way that C# would be hard to replicate just because the syntax would be so foreign.

So I think there's an opportunity for the F# market to explode as C# devs start to realize the utility of such things at the bottom level (and also for making interesting combinator-based libraries like suave). But in order to get there, I think the stepping stone has to be a change of emphasis in the F# world, to show off F# as a "better C#", starting with standard SOA-style OO-style frameworks, emphasizing a similar style (tupled explicitly-typed fn params, ext methods rather than pipe, C# naming conventions), and then just bumping the lower-level implementations of things and the domain model to ML style.

Going head-first functional-first I think leaves F# useful to just a handful of developers, where everyone else just wants their objects and DI frameworks back.

[willtim]

What exactly do you mean by "OO SOA structure at the high level"? Do you mean essentially a function from a document to a result? If so, then what exactly is object-oriented about it? I'm no expert on industry lingo, but "Service Oriented Architecture" sounds to me much more functional than object-oriented.

That you feel the need for DI frameworks is a great shame and more F#'s failing than functional programming per se. If F# had inherited the module system from OCaml, then there would be much less need to use objects. In OCaml, DI comes for free with module functors, no framework necessary. As it stands, I agree that you are somewhat forced to use objects as a module system, as F# has no other. That is what MS should fix.

[willtim]

Striking a balance? It's the Innovator's Dilemma!