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...
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.
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.
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#.
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.
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.
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.
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.
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!
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.
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)
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.
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.
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 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.
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.
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 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#.
46 comments
[ 0.18 ms ] story [ 112 ms ] threadIt could be a very very good thing for MS in the next decade if they invest in it properly (which they seem to be doing).
Interesting times.
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.
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.
F#'s compiler is OK - it's doing a lot more work. But it's not instantaneous like C#.
What about incremental compilation, is this done at all or does the F# interpreter recompile everything at runtime?
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.
I had a look around the web, and I couldn't find any sample open source F# applications that one can take apart.
So the CLR generics team build F# (an Haskell like language) and the Java generic team build Scala (an Haskell like language).
Hmm...
It seems like it should be a good fit for the stuff we normally do (log processing/munging), but I don't know how well it'll work outside of Windows.
It's quite well supported as everything related to F# developed by Microsoft is open-sourced (compiler, libraries, PowerPack).
Moreover Mono fully supports F#, as the compiler is sometimes bundled in some releases.
Also, F# is really a pretty sweet language (as for an heavy Haskell user with a little C# background). French love inside.
Can you make any suggestions as to places to read up on this stuff? The language seems so well put together!
If you don't need .Net, OCaml is practically the same language and has lots of vim/emacs support.
https://github.com/mono/monodevelop https://github.com/xamarin/fsharpbinding
BTW, F# also has emacs support, and from what I hear vim support is on the way:
https://github.com/fsharp/fsharpbinding
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.
you need a fork of the fsharpbindings project https://github.com/xamarin/fsharpbinding
have you tried using fsharpx from nuget? monodevelop has nuget support as of now. https://github.com/squidge/monodevelop-nuget-addin/tree/xs-n...
I also just built fsharpx.core and fsharpx.http with monodevelop(right now) and it built fine for me.
http://monodevelop.com/Download
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)
http://news.ycombinator.com/item?id=5251413
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.
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.
http://www.amazon.com/Expert-F-3-0-Apress/dp/1430246502/
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.
http://www.amazon.com/Real-World-Functional-Programming-Toma...
http://www.amazon.com/Programming-F-3-0-Chris-Smith/dp/14493...
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).
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.
f# has lot's of pythonish elements anyway. and the clr bindings are better documented
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.
there is an - in my opinion - pretty nice f# mvc template (not that i'm a big fan of mvc) available here: http://visualstudiogallery.msdn.microsoft.com/3d2bf938-fc9e-...
it's also ironic that when Donna Malayeri talks about F# the first thing she talks about is how verbose c# is compared to f# http://channel9.msdn.com/Blogs/Charles/C9-Lectures-Donna-Mal...
http://www.amazon.com/review/R3VEMJVVPFSUNF/ref=cm_cr_pr_per...