It's nice to see their strong continuing support for F#. I'm no longer in the .NET ecosystem but when I was learning F# and using it day to day was some of the most enjoyable paid programming I've done
It's good to see C# catching up with the past decades of language research. Maybe it's MS's DNA - they're still heavily pushing C++.
Tooling is the only real reason to ever use C# over F# - C# just doesn't do much (anything?) better. That, and legacy/enterprisey dev.
Heck, C# 7's tuple support is exactly what F# used to do, but then capitulated to MS's idea of making System.Tuple, a reference (heap allocated) type. Now in C# 7 since they finally got around to being a bit serious, they implement a new value-type tuple.
I guess we should be happy for any F# support we get. And indeed, tooling for functional languages is poor in general, so F# certainly leads...
I'm looking for the nearing releases where F# starts to share much more of the same Roslyn platform that C# and VB have been using for a while now. That should be some very interesting tooling to have at F#'s disposal.
C# is always going to be the flagship for the same reason that C/C++/Java/et al are still some of the most common programming languages in the world. That doesn't mean that we can't expect good things from F#, though.
Hopefully this will improve. It's just frustrating seeing C# slowly adopt stuff that was known to be good decades ago...
- I wanted to use it for websites. Sorry, not really supported in MVC.
- I thought it'd be great for doing .Net stuff in SQL-Server and SSIS, like you can with VB and C#. But it's not supported there either.
They always positioned it as "use F# for the extra hard stuff and C# for everything else," but in the end C# isn't terrible for hard stuff, and if that's what you use all day then for you, C# is probably better.
I'd like to see some love there. These simple things introduces needless uncertainty about the language.
- use Suave (https://suave.io/), best from f#, works on .netcore too
- use Aspnet Core Mvc (just `dotnet new -l fsharp -t web` in dotnetcore), or just aspnet core
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.
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.
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
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)
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.
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.
So classes/interfaces to each service your app uses. I just use very basic autofac, declaring which implementations to use in code. (Really nothing I couldn't wire up by hand; autofac is just a tad less cumbersome).
I've heard about OCaml's module system and am intrigued by it but never used it.
But I do appreciate the work MS does - F# is a leader in FP tooling. And C# is getting easier to deal with :).
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.
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.
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.
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.
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
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.