F# is fantastic, and the team behind it is super solid, having delivered generics for the CLR.
What this post leaves out is some of the tooling you lose when you move to F#. For what I assume are political reasons, F# keeps being marketed as a niche "scientific" product, when in reality, pretty much any C# code is better off being written in F#, even if you aren't writing idiomatic F#. I did one small test where I rewrote a C# program in non-idiomatic F#, and it required 1/20th the type annotations. C#'s just verbose - why use it?
Even WebSharper requires a "C# web site" to actually get Visual Studio to kick up IIS and make things run. There's no real C# code, but so much in the .NET/VS environment assumes C# (or VB).
In fact the worst times I've had with F# were due to other libraries depending on how the C# compiler is implemented, and failing when reflection/expression trees didn't look exactly the same. Fortunately the major use case (LINQ) seems to have been addressed quite solidly with F# 3.0.
This is essentially the same thing you find with Java and Scala. There are still a few benefits to using the base language, but for the most part you can get the same results in much less code with comparable performance. The only difference is that if I remember correctly F# has a _faster_ compiler then C# and limits where you can put code in your files while Scala has a slower compiler and lets you put your code any where you choose.
The biggest difference is that C#'s design is way better than Java's, so there's not nearly as much motivation to move to another language targeting .NET.
I love F# (I'm currently a contractor with the F# team in Microsoft Research), and I'm delighted to see people advocating its use. I prefer F# to C# by a wide margin. But C# is still a really well designed language, which makes it much harder for F# to gain wider traction than if it were competing primarily against a weaker language like Java.
No, the C# compiler is wickedly fast. There's a story that the first internal version printed nothing on success, so the PM reported that it wasn't doing anything, when in fact it had compiled the source so quickly he thought it was just exiting.
F#'s compiler is OK - it's doing a lot more work. But it's not instantaneous like C#.
Having the REPL (F# Interactive) available always from inside Visual Studio is one of the biggest changes to my workflow, ever. It saves so much time, allows me to play with things, and on occasion, I've even used it for live debugging where a debugger wasn't possible (paste parts of the source into the REPL on production box, then interactively play with it).
With C#, it was common to always have some project somewhere that was just a playground to run a few lines of code to test out a library, make sure I got a format string correct, etc. The F# REPL in VS eliminates that. If the F# team had more resources, and could make it fully integrated, it'd be unbelievable.
F# doesn't have an interpreter, it's compiled. The REPL is taking your lines and compiling modules and whatnot on the fly, then loading and running them pretty much as normal. So when you build, you get a binary, and you're all set - no runtime overhead.
Meanwhile, C# is supposed to have a REPL, Mono has an implementation, but it seems like C# is sort of abandoned and now the primary folks are working on yet another "almost-JavaScript-to-JavaScript" compiler.
Doesn't F# still perform worse than C# in various scenarios? IIRC the functional glue adds some overhead and F# uses classes instead of structs in some cases.
I have not found that to be the case. Yes, sometimes certain idiomatic things in F# might be slower, but in that case, just write them like you would in C# and you'll get the same performance. So, at worst, you end up with the same code, with more concise syntax.
There are a few exceptions, but in general, F# can emit anything C# can.
In fact, with F#'s "inline" ability, you have more flexibility than you do in C# - the CLR does vastly better when handed a big IL function, versus expecting it to get inlining right. The F# compiler does more advanced optimizations, too.
Just straight up writing F# as if it was C# gives you similar runtime results, with sometimes shockingly less code due to how much more concise the syntax is. C# and F# interop is also pretty painless if you do run into something that simply can't be done performantly enough in F#.
There are some cases where the F# compiler emits slightly less-efficient code than the C# compiler. However, in my experience I've found that I'm able to implement algorithms much more efficiently in F# than C#, which more than makes up for any compiler inefficiencies.
Also, "the CLR generics team" has built a lot of Haskell. The Microsoft Research program in Cambridge has been developing the GHC for years. The F# project led to a number of improvements in the CLR. F# really started as "Haskell for .NET" according to Don Syme.
This is really exciting. I do about 50% of my commercial development work in VB .NET (the other 50% in Python), and I hate hate HATE working in VB. Convincing the suits to go with Python would be near impossible -- too many processes rely on .NET -- but this seems like it could a be a great compromise. Sane, fast, modern language but with the full power of .NET libraries.
Can anyone recommend a good resource for learning F# for the .NET developer? I don't need an intro to functional programming (I have a pretty functional style in python and I've messed around with Haskell) but just a well paced intro to the syntax and standard library.
The book by Don Syme (one of the F# creators) is pretty good as it gives an short, yet complete, introduction to the language to people with a functional and .NET background.
I've started functional programming by reading the book about F# by Tomas Petricek. It was really good because it target learning functional programming to someone who have a solid OO background.
With a background in FP, I can go through the book at a walking pace. It starts off with the basics, though, so it might not get into the nitty-gritty details that would interest you if you're already familiar with .NET and FP.
I'm a C# dev that thinks in terms of F#/ML but I've long recognized that VB is actually a more expressive language than C#, especially if you want to write OOP in a functional style. For instance, VB has better IDE support for expressing sum types, doesn't require type annotations for lambada expressions, and has more Linq (query comprehension) operators.
Edit: I'm wrong about the "better support for sum types", I was thinking of Completion List feature but it doesn't quite give you a proper sum type (though it comes close).
VB.NET also doesn't allow #region's in method bodies, and can't use unsafe code.
I've found C# to feel more concise, clean, and have less annoying hard to predict syntax. If .. End If, While .. End While, but For .. Next? I'd expect End For. The attempt to make it look more like words just made it more annoying to me. VB.NET's syntax feels too verbose. C#'s feels more like a good spot where it's very similar to C++ and Java, but not alien.
I second rafaelj's recommendations, and there is also a good interactive tutorial from the F# team: http://www.tryfsharp.org/Learn. You may find it a bit slow paced given your FP experience but it may be a good way to actually try out the syntax rather than just reading about it.
imho, pretty much. you can do pretty much everything in ironpython, but i can't see you getting much support for it in a .net shop. the latest books for it are pretty old too, and overall it doesn't seem very active.
f# has lot's of pythonish elements anyway. and the clr bindings are better documented
I have been hoping to pick up some F# with Mono, but I'm having a hard time getting started - not with the language itself, but with the development environment. For instance, MonoDevelop seems very flakey on the Mac. I'd love to try out FsharpX, but I can't find instructions for how to build or install it on Mono.
Can you make any suggestions as to places to read up on this stuff? The language seems so well put together!
MonoDevelop 4? I'm using 3.0.3, which seems to be what their website advertises as the latest version. Maybe I'm missing it. Should I be building from source?
it looks a little prettier, but besides that nothing has really caught my attention. it also seems to throw exceptions more frequently(throwing exceptions, not crashing)
When was the last time you tried MonoDevelop? Xamarin has put in a lot of work on MonoDevelop over the past year or so -- in fact, they just released a major new version (4.0) and even contributed a bunch of improvements to the F# bindings:
It would have been over a year ago. I am not interested in using it, I was just curious about it at the time. (I don't really get along well with anything that expects me to use a mouse.)
I sorta doubt that the emacs/vim support is anything near what there is for OCaml, but knowing Xamarin it will get there... eventually. But really, I don't see a big reason to pick F# over OCaml unless you're already doing .Net or something.
I've had production daemons running for a few years on Mono. (SQL stuff, RabbitMQ)
In general, Mono (with or without F#) just works. I do all the development on Windows and VS, and then copy the binaries over to deploy. Downside is that stack traces don't read the pdbs so I don't get line number information.
F# Interactive has had some readline and other weird errors on Mono/Linux.
You can add a post build task to your csproj to run Mono's pdb2mdb, you'll have a .mdb debug symbol file that Mono can use, and you'll get line numbers in stack traces.
There's a lot to love about F# (type providers are especially sweet, for example). I'd like use it more, but the challenge seems to be more about getting C# devs to embrace functional development. Which I suppose is the challenge of functional languages everywhere...
the way my coworker put it, if ml and python had a baby, and microsoft stole that baby, that would be f#.
i don't like websharper. what is wrong with people wanting to write their clientside in f#? anyway that's why i was looking at how the iis stack works, so i can write my own framework.
I have been eying F# for bioinformatics work for a year, but a dearth of bioinformatics library, difficulty linking existing libraries, and flaky tools on Linus have held me back. Right now I am stuck with Python and R, which are good languages with plenty of good libraries, but I want to branch out into functional languages. It also does not help that I don't know C# and am disinclined to learn it.
I was thinking of ordering the Expert F# 3.0 book, when i saw this (writer of this review was the Tech Reviewer for the Expert 2.0 version of the book)
Hum. That rant goes against F# itself, not against the book, notably the less than stellar support for GUIs. The book itself is fine, albeit a little bit expensive. The criticism of this review, as well as the optimism expressed by the blog post both miss the wood for the trees: F# will never outshine c# or VB.net in areas where tooling matters more than the language itself. It is tremendously useful for developing libraries and services to be glued together by c#.
What this post leaves out is some of the tooling you lose when you move to F#. For what I assume are political reasons, F# keeps being marketed as a niche "scientific" product, when in reality, pretty much any C# code is better off being written in F#, even if you aren't writing idiomatic F#. I did one small test where I rewrote a C# program in non-idiomatic F#, and it required 1/20th the type annotations. C#'s just verbose - why use it?
Even WebSharper requires a "C# web site" to actually get Visual Studio to kick up IIS and make things run. There's no real C# code, but so much in the .NET/VS environment assumes C# (or VB).
In fact the worst times I've had with F# were due to other libraries depending on how the C# compiler is implemented, and failing when reflection/expression trees didn't look exactly the same. Fortunately the major use case (LINQ) seems to have been addressed quite solidly with F# 3.0.