I'm sure I was in that room with Reed (the OP) a year ago in November. Although I don't recall the details of the conversation, I do recall the feeling within the F# community of accomplishment up until then (Nov. 2013), and excitement looking forward. As the post summarizes, 2014 was a year of great progress for both the F# language and the community. On the community side I used to know personally or through social media most of the movers and shakers. Today it seems like there is a steady stream of new contributors posting OSS projects and technical articles, far too many for me to remember or keep up with. Sergy Tihon's F# Weeklyhttps://sergeytihon.wordpress.com/category/f-weekly/ covers more F# news than I can possibly track.
If you believe the future of software engineering includes strongly typed functional languages, then F# is the place to be for many reasons:
1) Microsoft has settled into the role of corporate curator of the language, core libraries, and core tools. I personally know the small MS team supporting F#, and I can tell you they are motivated, enthusiastic, and very capable in this role. I can also tell you the major players in the other MS language and tooling teams take an interest in following the progress of F#. Not to mention the world's most advanced quantum computing simulation compiler is written in F#. http://research.microsoft.com/apps/pubs/default.aspx?id=2096...
2) F# is Microsoft's longest running major OSS effort, and the experience no doubt played a role in how MS roled out the recent open sourcing of .NET and commitment to making .NET cross-platform. Keep an eye on developments in this area, it will strengthen F# as a cross platform language.
3) And finally if you have an interest in hacking on functional languages, core components, libraries, tooling, etc., this is the place to be. You can make OSS contributions which will make a difference to users around the world.
It'd be nice though if MS would provide the F# team with more resources, or actually do pro-F# marketing, instead of pushing the inferior-but-with-far-better-tooling C#. For instance, it's embarrassing that MS doesn't have a comprehensive web toolkit for F#, and instead just pushes a mashup of TypeScript and ASP.NET. No doubt the community is great, but the effort that goes into first class VS support seems to require a much larger team doing rather unfun work. To date, it seems only MS has pulled this off.
There are definitely people using F# on Mono in production, but it is the smaller brother still.
Having said that, nearly all of the "core" projects are now being CI tested on mono as well as windows, and the fsharpbindings project provides autocompletion for Vim and Emacs (+ powers the MonoDevelop/Xamarin Studio F# support as well).
I'm having great fun writing F# code in Linux with Vim - now that .fsx (F# script) files have proper #! support you can just write fsx files with full highlighting, error checking and autocompletion in place and then run them with supervisord.
Up until recently, packaging was a bit of an issue, but recently the official Mono repositories have started being much more up to date again, and now include recent versions of F# as well: http://www.mono-project.com/download/#download-lin
Getting vim support is still a case of cloning the project from github https://github.com/fsharp/fsharpbinding and running make in the vim directory - Vim 7.4+, make, python and a couple of other vim plugins required.
After that, things can start getting pretty nice. For (my only public) example, https://github.com/mavnn/Advent2014 shows how you can use fsx scripts and paket (a package manager compatible with nuget.org and taking source dependencies from github) to create a nice little project without needing to get into any of the Visual Studio project file nastiness. Of course, if you need to work on an existing project, the Vim bindings know about how to handle that too - but actually editing project files is still a pain.
One word of caution: there's currently a bug in the packaging for rpm: I'd go with Debian/Ubuntu packages at the moment. And as a final option, building from source is slow but has become pretty reliable over the last year or so.
Thanks for that. Having got past the setup and configuration issues, have you experienced any problems with the packages that are available? What's the ecosystem look like for F# on linux?
Packages generally work fine, although if they rely on native binaries they often require a bit of tweaking to point at the Linux .so rather than the windows .dll. That's uncommon in the .net world though.
The ecosystem is huge; http://nuget.org hosts the main .net package collection, and it fairly comprehension. Also, to be fair to MS the standard library is pretty "batteries included"; it just doesn't always have what I would consider the nicest APIs.
That sounds very tempting! What's the dependency bundling story like with F#/Mono - what would be the equivalent to assembling a fatjar for the JVM, or indeed `go build` for Go?
As in a self executing file? Not the standard deploy story, but is in theory possible on Mono with a combination of F# compiler options to compile in all dependencies, and mono's "ahead of time (AOT)" build.
It does mean that you lose a number of traditional clr advantages such as JITting - and I have to admit that I haven't tried this route myself. Almost all of the clr code I've written has been server side.
Ah - not necessarily a self-executing file - a fatjar still depends on having the JVM installed on the box. I guess I was asking if there is a way of packaging an F# script or app so that it can be installed on a server with a simple wget from Bintray? So all dependencies vendored in.
F# applications are compiled to ordinary .NET executables, so you can look at how other .NET applications are packaged on *nix. Basically, you can package them as you would any other software, though it would help to either have .NET executables configured to launch with mono via binfmt_misc (on Linux), or have a small launcher script to do the 'mono myapp.exe' invocation.
It should be possible to plug the F# binding backend into sublime; it expects to run as a separate process and have buffer states passed back and forth as JSON. I don't know much about sublime plugins, but I believe that they're Python based and should be able to handle that reasonably elegantly.
I know that one of the teams at my work has deployed a few tools on mono written in F#.
I play with mono and f# (nix) and I was surprised with how mature mono develop was (I had very low expectations)- I have not used it in anger however, so things like profiling and such I have not even taken a peak at.
I asked myself the same question, seeking for ressources on the web and help on irc and i concluded that unfortunately the f# community is mainly a windows community. Mono is quite a niche.
It is mainly Windows, but as stated in a few other answers people are using Mono in production. How long ago did you look around? I have to admit that it's only really become fully practical (in my mind) in the last 6 months or so.
>Tomas Petricek's "Real-world functional progamming" as well as "Expert F#" by Don Syme are excellent introductions to the language.
I found both books kind of lacking, the former has examples in C# which I found distracting and the latter was too dry.
If F# gets a book in the league of "joy of clojure" it would greatly help push F# into the mainstream.
Meanwhile, this is the best book if you like doing exercises as you learn( why wouldn't you? ). Not sure why the book is so underrated.
The academic nerd in me demands I add other references as well :)
Other resources I found usefull for F# were Sestoft's "Programming language concepts" which uses F# to teach about interpreters and compilers and Flying frog consultancy's "F# Journal".
Glad to hear they're doing well. I've been slowly tinkering with the tryfsharp.org tutorials and I'm liking what I see. It might be the first MS language I've actually liked since QBASIC.
It's always great to hear about people finding it and liking it! Even better is that, in a meaningful way, it's not "a MS language" really now - it's fully open source, probably the best thing to happen to F# this year.
I'm aiming that comment less at you than just generally because the general publicity around that is probably a bit lacking - but if things like that matter to you, F# is still a great place to look :)
Hope you carry on enjoying F# - the community is one of the friendliest, do come and say hello!
The last time I tried F# it was definitely a Microsoft language, in spite of their invitation to Linux users. It was hard to get it to install, it didn't work right, not all libraries were available on Linux, and I couldn't even access videos explaining the language because they required Silverlight. When I posted my experience to Reddit in order to give them feedback, I definitely didn't find a friendly community.
Things may have changed. I wasn't turned off by the fact that Linux support was so far from where it needed to be. I expected that. It was the toxic response that turned me off.
You posted to reddit and got a toxic response? Frankly I'm not sure that's a reflection on F# or reddit. I've been a member on reddit for years yet rarely vote or comment. Whenever I post something, seemed like all I ever got was abuse. Who knows? Perhaps reddit has changed.
As for F#, I've been using it since beta. All I did was get the books and slog through them. Coming from a strong OOP background, I had quite a bit of "this makes my head hurt!" before the light started coming on, but once I came to grips with the power of the language, I didn't look back.
Yes, not all libraries are available on linux. I program F# almost exclusively on linux, and that doesn't bother me at all. The number of libraries that are available, compared to other platforms, is astounding. A couple of times I needed some kind of weird library, so I went and found an open source windows F# version (or C# version, gotta love CLR), then just added the project to my solution. Presto chango, I built both projects at the same time and got a huge amount of functionality for the price of an hour or so downloading code and building it.
(disclaimer: I write microservices any more. No GUIs)
Biggest problem I have with my set up is remembering some of the switches and tweaks to get the thing to build. My code runs so great without my having to horse around with it, so it might be months between getting out the tools. That's usually a couple of hours of banging my head against the wall, but once I've got the build cycle nailed, it's a sweet setup. Best I've used in a long time.
The F# community seem to be most active via twitter, Google+ and (slightly bizarrely) StackOverflow chat in my experience. /r/fsharp is pretty small, although I've always found it friendly.
I actually wasn't sure as to F#'s independence; that's good to hear. Being free and open means it'll keep going even if MS gets bored with it, though it's mainly its 'first class' status with the MS tools (VS and .NET) that make me still think of it as an 'MS language' I guess, and also part of what excites me about it. I mostly use Windows and Windows Phone, so being able to write native Windows apps with a functional language is something I've been seeking for some time now.
I have been playing with F# a fair bit and I am totally in love with the language. I wish it was a jvm language given that is what I ply my trade on (and no scala is not as elegant imo)
F# is indeed very interesting! For the JVM, one alternative (based on Haskell 2010, so it has philosophical similarities to F#) is Frege (https://github.com/Frege/frege). Frege is probably even less mainstream than F#, though. I don't use it because I'd rather code in Haskell using GHC.
While it's not an ML-style language, I've found that I enjoy Clojure the most when it comes to JVM alternatives. The lack of F#-style pattern matching makes a few things feel less elegant, but the general structure of my code is extremely similar.
There is core.match[1], and between the restructuring bind, multimethods, and the ability to create polymorphic functions like hello in this example[2], you can replicate a lot of common FP idioms reasonably well. It's not pretty, but Clojure generally isn't.
The trouble with Scala is that developer A writes elegant mostly-functional code while developer B uses global state modified in nested while-loops with everything as type Any. I think more of a bondage language approach would be better.
Agreed this is a problem. For example, I had to educate my boss about Option vs null, and I'm still not sure he gets it (he's an old school C-and-then-Java programmer).
On the other hand, it's possible to "not get it" and write messy code in even the most bondage-oriented languages.
Interesting! Didn't know that. But note two things:
1- In the more general case, you cannot enforce a rule to disallows clumsy/inelegant code. You cannot force proper use of the language.
2- In the Option/null case, this is an education problem. My boss is an old-school programmer with lots of experience (and I've seen him successfully solve and/or prevent real problems at work that bit every other team, so by no means I want to sound disrespectful of his experience), but he simply doesn't understand why Option is needed. He claims "defensive programming should be enough" (i.e. checking for null at every turn). He claims "academia is not good for anything", and I guess he sort of believes Scala is an academic language full of fancy but not really useful constructs. He is not completely sold on functional programming, pattern matching, etc. So I cannot simply have the language complain about nulls, because I must justify the enforcement of this rule to my boss, and he isn't convinced. (Note: this isn't limited to Option values; think of almost every feature/coding style from Scala that might sound unfamiliar to Java programmers, and it's the same problem with my boss).
I recently tried to teach myself F#. Although the community is very small compared to others, the folks I ran into were warm and enthusiastically helpful.
Most of the intro texts I tried were not good. I found a fantastic one, but it is an outdated, abandoned text that must be accessed through the Internet Archive [1]. I tried to contact the authors to see if I could help updating it, but received no response.
The language has a large surface area. It is not uncommon to think you have learned a lot of F#, then read a blog post by someone full of F# code and think "what the heck is that symbol?"
I agree with others that note the MS influence. Things are definitely getting better, but you will have an easier time if you are in the MS ecosystem.
For what it's worth, I wrote a blog post [2] that might be helpful if you're trying to get started.
http://fsharp.org and Scott's site are the go to sites for all things F#. The Twitter hashtag #fsharp is sure to get you retweeted and/or responded to, and finally any well-formulated question to stackoverflow with an F# tag will get a speedy response.
If you believe the future of software engineering includes strongly typed functional languages, then F# is the place to be for many reasons:
1) Microsoft has settled into the role of corporate curator of the language, core libraries, and core tools. I personally know the small MS team supporting F#, and I can tell you they are motivated, enthusiastic, and very capable in this role. I can also tell you the major players in the other MS language and tooling teams take an interest in following the progress of F#. Not to mention the world's most advanced quantum computing simulation compiler is written in F#. http://research.microsoft.com/apps/pubs/default.aspx?id=2096...
2) F# is Microsoft's longest running major OSS effort, and the experience no doubt played a role in how MS roled out the recent open sourcing of .NET and commitment to making .NET cross-platform. Keep an eye on developments in this area, it will strengthen F# as a cross platform language.
3) And finally if you have an interest in hacking on functional languages, core components, libraries, tooling, etc., this is the place to be. You can make OSS contributions which will make a difference to users around the world.