"How’s F# adoption?"

Based on inferences it has a small, enthusiastic and talented userbase and has still language core developers bankrolled by Microsoft.

There's been some worried discussion whether Microsoft wants to continue investing in it or not, e.g.:

https://www.reddit.com/r/fsharp/comments/91gg6j/is_microsoft...

Personally I hope they would continue the investment.

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.

I don't know about general F# adoption, but I've used it for personal projects and I quite like it. I'm trying to convince work to let us use it in production.

Great to hear that you're working to convince people to use it in the workplace. Not sure what your approach is, but a few things have worked for people very well:

* F# for unit testing

* F# + Giraffe or Saturn deployed to Docker containers on .NET Core (people tend to love the succinct routing and that it all runs on ASP.NET Core in Docker)

* F# for internal tools to ingest and manipulate data, then put it into another place in a much more sane format

* F# with FAKE for a right proper build script

* F# with Azure Functions to perform some scheduled task or something like that (it also helps that Functions is dirt cheap)

Good luck!

If only my workplace used Azure for some stuff. We're moving to serverless architecture for a lot of our apps, but it's all on AWS so no F# :(. The other .NET guy at my company (wpf) and I have been singing the praises of Azure and using .NET core for future developments. I think that they'll eventually throw us a bone since they don't want to be dependent on a single cloud provider.

However, I have messed around with data manipulation in F# for sports betting, and it's been exceptionally pleasant.

Love the work you guys are doing on the F# team.

F# actually rusn _very_ well on AWS. There is some official scaffolding tooling you can use[0], and performance with .NET Core is more than sufficient for what your business likely needs[1]. Love this quote: "Both C# and F# on .Net Core 2.0 exceeds all expectations and outperforms all other runtimes in average duration".

Thanks for the compliment! And I hope that it all goes well with you.

[0]: https://aws.amazon.com/blogs/developer/f-tooling-support-for...

[1]: https://read.acloud.guru/comparing-aws-lambda-performance-of...

Thanks for the information! I'll try to let you know if we ever get something going.

My company runs F# + .NET Core on AWS Lamba (almost our entire backend infrastructure). We've been very happy with it.

I'm in the same boat, coming from Python. I like it a lot -- it lets me write things that are hard to express in Python. (Sum types and exhaustive pattern matching in particular.) My Python had been moving in this direction anyway -- less OO, more procedural, more pure functions, limited mutation.

Exactly. We're doing the same thing with my C# project at work. It's becoming more "functional" as we refactor and fix bugs. The project has been much easier to work with.

Sorry to hijack the thread:

I recently was trying to decide which language to pick up next: Lisp, OCaml, F# or Haskell (I know a bit of Lisp and Haskell already, as well as some Standard ML).

It came down to two: OCaml and F#. The former has poor support in Windows (work machine), and the latter has less poor support in Linux (home machine). So I decided I'll probably go with F#. I've been told the syntax is quite similar, so how difficult is it to translate an F# program to OCaml. Are all the patterns the same that one can do a more or less 1:1 translation while still being canonical?

Going from Ocaml to F# is trivial, most of the time it is only a matter of adjusting the indentation and getting the correct name from the std. Going from F# to Ocaml tend to be harder since F# has a number of functionalities that are often used and do not exist in Ocaml (such as parallelism, sequences, active pattern, list comprehension, type providers, etc and a much bigger std). As a user of F# on linux, the experience is good (better than Ocaml on linux) and getting better every year (some library are still windows only but it is changing).

>Going from F# to Ocaml tend to be harder since F# has a number of functionalities that are often used and do not exist in Ocaml (such as parallelism, sequences, active pattern, list comprehension, type providers, etc and a much bigger std)

The opposite is also true, F# does not have ppx, OCaml's object system, GADTs, polymorphic variants, functors, first class modules, extendable variants.

Better than OCaml on Linux or Ocaml on Windows? If it's better than OCaml on Linux, that would be impressive.

F#'s object model is very different from OCaml's. F# is basically the same as C# when it comes to objects, but OCaml has some sense of structural subtyping that F# lacks. On top of that, OCaml has a very powerful module system, whereas F# has a pretty standard one.

On the other hand, F# has computation expressions (essentially extensible syntax sugar for certain kinds of operations), as well some nice extensions to the pattern match system.

That's not to say one is exactly better than the other, they just focus on doing different things.

Have you tried F# on .NET Core? There are plenty of people using it exclusively on Linux (both to develop and as a deployment target).

I use F# every time I have to write a parser for the sole reason of FParsec, which is a godsend and a joy to work with

This is a brief history of OCaml and ML family

https://blog.baturin.org/images/fp_genealogy.png

It is the stepchild of .NET.

There are still a few deployment scenarios where only C#, VB.NET, C++, JavaScript get to play and F# gets no entry.

A few F# features still don't work on .NET Core, like REPL and type providers.

Speaking of which, type providers is the king of F# demos, instead of discussing how and if ever .NET Native devs will care about F#.

Type Providers have worked in .NET Core since April.

Edit: https://twitter.com/dsyme/status/981799285925842945?s=20

Thanks for the correction. I lost motivation to keep following up F# tools being also ran for C# and VB.NET.

F# is not a derivative of OCAML, though it was that way in the very very first version (pre-1.0). Since then, it has diverged a lot, though it does have the same core syntax and "feel", and even has a flag (--mlcompatility) that allows you to compile a subset of OCAML programs with F#.

They all belong in a continuum of ML languages, starting from (I think) SML.

No, I think SML was an attempt to standardize the various dialects of ML (which was the original) that had been invented. OCaml was a version of Caml with Object-Oriented additions. (I remember playing with Caml Light many years ago).