Obviously it's not the first language to implement a "pipe" operator, but apparently F# was the original inspiraton for the %>% pipe operator in R. Not only was the idea of "piping" itself a small revolution in data analysis/science coding, but it was the gateway to introducing functional programming and metaprogramming principles to a wide audience of non-computer-scientist users. So its legacy will live on, even if the language does not.

For me, at least, I've had negative experiences with Mono-based applications on non-Windows platforms (e.g. Keepass), so that is scaring me off from wanting to build anything on .NET.

Have you tried F# on .NET Core? People seem to be quite happy with F# on .NET Core compared with Mono, at least for server/web/cloud programming.

Data science-y stuff is our next target, starting with finishing out our REPL support for .NET Core. It's not fully functional (turns out it's a ton of work!), but when completed it'll have support for ingesting packages in a REPL session, and it'll work with libraries such as ML.NET.

I really like a lot of F#, but it is really difficult for those of us with limited .NET experience (Python, R...etc experience here). There are several F# books, but it's all a bit above me. If you are an F# evangelist, please consider spreading that idea around. Maybe an updated tryFsharp.org would help. Not just REPL snippets either but how to put things together.

I appreciate everything the open source community does btw. It is just a little frustrating that there is a really cool language and ecosystem that I'm only making glacial progress in.

"F# for scientists" by Jon Harrop is awesome especially if one comes from a less computer sciency background. It shows exactly how to use F# effectively in a numerical context.

The guy is a god. I've been meaning to check it out.

F# is available in Azure Notebooks so I guess it’s fully supported

Microsoft is throwing everything on Azure these days, I won’t be surpised if a significant proportion of these services are discontinued in the next years.

Why should they when it gets used and makes them money?

A usable industrial strength tool needs more than just the compiler and a repl.

The main benefit of an industrial language is the entire toolchain including IDE with code higlighting, intellisense capabilities, debugging capabilities, etc. To provide these for F# in Visual Studio requires continuous investment.

Hence, given the not-entirely-committed feel MS is emanating just now for it, if they don't feel supporting F# as a first class citizen on visual studio is worth the investment, they might orphan it to to open source developers. Who probably would hold good care of the core facilities, but would probably lack resources and interest to provide an entire industrial strength stack. I do hope this is not the scenario, and Microsoft will continue investing in the language as a first class citizen on visual studio.

You can check out some of the investments we've been making for F# holistically here: https://blogs.msdn.microsoft.com/dotnet/2018/08/14/announcin...

(lots of language stuff at the beginning, but there's a tools and "what we're thinking of next" section afterwards)

Thinking of next, as usual is only interesting for the usual type provider demos, not for the working programmer using C# and VB.NET across EF, Forms, WPF, UWP, ASP.NET MVC, IoT Core, HoloLens.

This. As an industrial programmer: F# was awesome 10 years ago, I don't really crave for new language features. I want an industrial strength tooling and ecosystem to support this awesome language, not new language features.

To be painfully blunt: The language is really nice as it is. I would prefer it would expand on the bolted-on batteries included utilities rather than new contrived ways of code golfing.

What is critical from industrial point of view that the fundamentals are now and "forever" rock solid. Not how many new language features it will gain.

See C for reference. Nobody uses C because it gets new ways to write shorter code. People choose C for stability[0], not because it's horrible language or because it's a beautiful language.

F# would be fantastical, if it would ossify like C. Then I could write it for the rest of my programming career.

[0] Yes, C moves forward, but with a geological pace

I think your definition of "working programmer" is a lot more specific than you're implying here. There are numerous working programmers using F# successfully today, in a broad number of scenarios. Machine Learning is our next one to tackle.

I don't need F# for ML.NET and still get to use it on the above scenarios where F# gets a no entry to play allowance.