F# end to end | Hacker News Reader

F# end to end

colinbul.wordpress.com

90 pointsgebe46 comments

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.

According to an article linked in this article, there is.

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#.

What's your development workflow like? Do you try out bits in the REPL then paste into source?

What about incremental compilation, is this done at all or does the F# interpreter recompile everything at runtime?

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.

Are your F# projects web-based or desktop ones? I'd imagine hand coding UIs to be rather cumbersome.

I had a look around the web, and I couldn't find any sample open source F# applications that one can take apart.

>F# is fantastic, and the team behind it is super solid, having delivered generics for the CLR.

So the CLR generics team build F# (an Haskell like language) and the Java generic team build Scala (an Haskell like language).

Hmm...

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.

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...

I've been reading Chris Smith's book:

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.

What do you hate about VB?

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.

In my experience, if you use #region in the body of a function, it is a sign it needs refactoring.

While I'm sure F# is nice -- any reason why you wouldn't/couldn't use Iron Python? Is it "dead" ?

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.

F# is a very interesting language and one of the best things to come from Microsoft in a long time.

It 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.

Does anyone have any experience with F# (and Mono in general) under Linux? How's the library support?

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.

I've used F# for some little .NET school projects using Mono.

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.

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!

Regarding MonoDevelop, it never worked for me on Linux, it just flaked out completely.

If you don't need .Net, OCaml is practically the same language and has lots of vim/emacs support.

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:

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

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.

well, personally i use monodevelop(xamarinstudio) 4.0 and mono 3.0.3 in archlinux.

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.

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?

up to you really they released 4.0

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)

I've spent about 3hrs trying to get the fsharp binding working in xamarin studio but no luck. How did you get it working?

deIcaza mentioned here that it's a priority for Xamarin

http://news.ycombinator.com/item?id=5251413

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.

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...

So how do you want to write your client-side? Does not using one language for both the server and client make sense to you?

My favorite part - they use type providers to work with xaml code. They're moving IDE features closer to the compiler.

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)

http://www.amazon.com/review/R3VEMJVVPFSUNF/ref=cm_cr_pr_per...

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#.

It's like building Python projects with SCons.

Reply on news.ycombinator.com