I know its heresy, but for a while I was actually getting hooked on F# succinct way to write/support OO. On the surface at least, it looked a lot cleaner and more concise than C#.
I wish there were more F# jobs - its a very interesting language.
I think the language that is apart of .net that people on HN would find most appealing is F# . Its heavily Ocaml inspired but also has LINQ and all the other cool features from c# .
Not heresy at all. Everyone I know that has used it, including myself, really likes it. Yet no one I know has ever used it a real production environment. I guess it has some traction in financial circles, but that's about it. Maybe .NET going cross-platform will lead to some adoption.
We at Tachyus use it as the main server-side language in our production environment. Also on Linux/Mono. Jet uses it, and they were bought by WalMart for > $1B. There is no problem running in production. In fact, there is a noticeable lack of problems running in production.
Kiln, Fog Creek's old Git/Mercurial hosting environment, had major components written in F#. Those components honestly were probably the only genuinely bug-free parts of the code base (though I think that had as much to do with developers self-selecting to work on those areas as it did to do with using F# as such).
The syntax was a part of what kept me away at first, but ultimately, it has become preferable to C# for me as well. It's likely similar for Java programmers moving to Scala for the syntax.
I stumbled upon the following response on SO that helped me to move past using interfaces to passing functions instead.
I was introduced to F# 3 years ago at work, and have been developing with it for more than 2 of those years (in production, some apps mixed with C#, others pure F#)
My quick thoughts:
Beautiful language. There's quite a bit of a learning curve for some of the more advanced features, but a large portion of the language is very readable and succinct
Additionally, I love how the language has helped me become a better developer. Far fewer bug, and none of them are null-related
After my former lead left, I've had difficulty introducing new teammates to the language. It's hard to convince C# devs to try it out
I've been looking around for a long time, but there seem to be very few teams that are hiring F#. It doesn't help that many aggregate job posting sites fail to show useful results when searching for "F#"
Negatives aside, I really enjoy programming in F# and if you were on the fence, I'd say to give it a try!
I have been wanting to break into F#. At work I use PowerShell on many Windows computers. I could write PowerShell modules in C#, but F# would allow me to think like I would if they had been written in Haskell.
I am also working on a small web application with C#. (M101N course via MongoDB Uni.) I'm keen on re-implementing in F#, just to see how both compare.
I'd love to use F# in production on a Linux/Mac OS environment. I find the tooling to be problematic and quite hacky on these platforms. In the same time the library ecosystem around manipulating PDF/Word/XLSX documents, CPU/GPU math accelerated libraries, machine learning, stats, charts and DB connectors are not that mature and production ready.
If you just stay withing the F# and .NET core library ecosystem then it's fine. I'd need more support for the ecosystem to be able to fully switch from scala to F# for production. I'm so looking forward to having Microsoft get the full .NET to Linux.
I have been feeling this way for quite awhile. I never want to detract from anyone's hard work, but I simply hate Mono. I hate having to fool around with it to get something else to work. When MS released C# for .net-core, I was extremely pleased. I'm not a big MS fan, but C# is really good! Being able to run it on Linux is a great step forward. I know MS has a roadmap to get F# going, so I'll be anxiously waiting.
This talks about mono and I certainly think it's a nice option. If you want to use .netcore and F# (even on mac and Linux ) here is a nice getting started vid :
First the guest mentions the merits of F#'s deep implicit typing, where the use of a function at the top may determine the typing of other nested functions. And as one would expect with this level of things happening implicitly, it is very easy to get lost in what is going on, which is exactly what happened to the guest at minute 27, where he couldn't figure out why the F# compiler wasn't implying the correct type.
Later on the guest mentioned that for all their API, they actually create a signature file (i.e. a header file) where you have to declare every function signature separately from the implementation. The host diplomatically mentions that perhaps this might maybe be a little bit cumbersome to maintain. The answer is that it's not a problem, as the program simply doesn't compile if you have a mismatch.... Hum.
I like certain aspects of it, not using too many special characters (kind of python/vb style), the immutability, etc. But I can't say I am sold and ready to switch though. And many of what are presented as key features are just not the kind of things I have any use for, like declaring lists of consecutive numbers (can't remember the last time I needed one) or F# type providers (I rarely have to deal with unexpected file data formats).
It's true that it's easier to write and arguably harder to read code when types are not specified, or at least it's handy for public interfaces between modules. Luckily this is easy to do and often done:
It's the same deal with Haskell, you don't HAVE to specify the types of your code but it can help check your assumptions as to what the compiler is inferring. I've frankly found that a more frequent issue in Haskell because of pervasive use of Monads and other higher-order constructs.
Yes, to be honest in languages with type inference you have to rely on your editor/IDE to show you types on demand. You do need that to be able to work smoothly on a day-to-day basis. Of course you can and should learn how to reason about the types, but you still need quick feedback about whether the compiler agrees with your reasoning.
To your second point, about the 'header' (interface) files in ML-family languages like F#--that is a really great feature because it lets you do abstraction and access control. The interface file specifies what callers are allowed to see, you can use them to make your types truly abstract and prevent access to your modules' internal functions.
About lists of consecutive numbers ... not sure what that is referring to exactly. About type providers ... yes, I agree with you that not everyone finds a use for them. In general, I will say that the killer feature of F# and other ML-family languages is that they dramatically increase code refactorability (low-ceremony static types) and dramatically reduce lines of code (simple, 'math-y' syntax).
For consecutive numbers I am talking about the [1..99] notation. Very useful in academics to make a demo when you don't have real data. But less so in the real world. What I mean is that many of these demos tend to address problems that I do not have personally.
Multithreading is a good example. It is hard to do at a low level. And I totally get why F#'s approach helps a lot. But I find that you get most of the benefits of multithreading by splitting your task in independant subtasks that are not thread safe but do not share writable data, and run a parallel.for at the top. Occasionally you need some locking if you have a common cache but that's easy to get right.
Sure you could optimize it a little bit more by making it multithreaded at a lower level but most of the time that's enough to get 90% of the performance benefit.
I am also a bit uncomfortable with the liberty F# takes with memory. To make everything immutable you create a lot of copies in memory. All the .net performance articles I have read mostly focus on taking it easy with the garbage collector and reducing the number of allocations. Intuitively it doesn't sound like an obvious trade off (thread safety vs more garbage to collect).
Oh, the range notation. It's a little convenience that can save a bit of typing here and there. Not a tremendously important feature, to be honest.
About multithreading, not sure what you mean but F# definitely has parallel collections in addition to its general async capability that lets you handle concurrency in a safe way. If you haven't already, check out the Hopac project (http://hopac.github.io/Hopac/Hopac.html , scroll down to the Description section).
About memory use, yes you create copies but at the same time immutability means you can have persistent data structures which share and thus save a lot of memory. Also, in general performance is good enough that you don't really have to worry about it, and when you do, you can always measure, profile, and see what's actually causing the memory pressure.
That said, it's true that functional programming languages have a different memory profile than imperative languages, and implementations which have been designed with this profile in mind perform really well. E.g. check out OCaml's performance in this GC pause benchmark: https://making.pusher.com/golangs-real-time-gc-in-theory-and...
Any one that uses F# right now, can you tell me if you can create folders in Visual Studio? It seems like it's mentioned here, but I'd like a confirmation.
You can via the F# Power Tools; at least in VS2015. In VSCode just create the folder as per normal and hit "F1->F#: Add File to Project" using the Ionide plugin. Admittedly the need for folders in my experience is a lot less than in C#.
29 comments
[ 2.4 ms ] story [ 66.6 ms ] threadI wish there were more F# jobs - its a very interesting language.
And Kaggle, and Credit Suisse, and...[2]
[1] https://www.elastic.co/blog/solidifying-releases-with-fsharp...
[2] http://fsharp.org/testimonials/
I stumbled upon the following response on SO that helped me to move past using interfaces to passing functions instead.
https://stackoverflow.com/questions/34011895/f-how-to-pass-e...
https://web.archive.org/web/20170607134504/http://www.prigra...
My quick thoughts: Beautiful language. There's quite a bit of a learning curve for some of the more advanced features, but a large portion of the language is very readable and succinct Additionally, I love how the language has helped me become a better developer. Far fewer bug, and none of them are null-related After my former lead left, I've had difficulty introducing new teammates to the language. It's hard to convince C# devs to try it out I've been looking around for a long time, but there seem to be very few teams that are hiring F#. It doesn't help that many aggregate job posting sites fail to show useful results when searching for "F#" Negatives aside, I really enjoy programming in F# and if you were on the fence, I'd say to give it a try!
I have been wanting to break into F#. At work I use PowerShell on many Windows computers. I could write PowerShell modules in C#, but F# would allow me to think like I would if they had been written in Haskell.
I am also working on a small web application with C#. (M101N course via MongoDB Uni.) I'm keen on re-implementing in F#, just to see how both compare.
Appreciate the getting started guide!
https://notebooks.azure.com/Microsoft/libraries/fsharp
https://channel9.msdn.com/Events/Build/2016/T661
https://channel9.msdn.com/Shows/On-NET/A-tour-of-F-with-Phil...
There are two passages that I found amusing.
First the guest mentions the merits of F#'s deep implicit typing, where the use of a function at the top may determine the typing of other nested functions. And as one would expect with this level of things happening implicitly, it is very easy to get lost in what is going on, which is exactly what happened to the guest at minute 27, where he couldn't figure out why the F# compiler wasn't implying the correct type.
Later on the guest mentioned that for all their API, they actually create a signature file (i.e. a header file) where you have to declare every function signature separately from the implementation. The host diplomatically mentions that perhaps this might maybe be a little bit cumbersome to maintain. The answer is that it's not a problem, as the program simply doesn't compile if you have a mismatch.... Hum.
I like certain aspects of it, not using too many special characters (kind of python/vb style), the immutability, etc. But I can't say I am sold and ready to switch though. And many of what are presented as key features are just not the kind of things I have any use for, like declaring lists of consecutive numbers (can't remember the last time I needed one) or F# type providers (I rarely have to deal with unexpected file data formats).
https://fsharpforfunandprofit.com/posts/function-signatures/
It's the same deal with Haskell, you don't HAVE to specify the types of your code but it can help check your assumptions as to what the compiler is inferring. I've frankly found that a more frequent issue in Haskell because of pervasive use of Monads and other higher-order constructs.
To your second point, about the 'header' (interface) files in ML-family languages like F#--that is a really great feature because it lets you do abstraction and access control. The interface file specifies what callers are allowed to see, you can use them to make your types truly abstract and prevent access to your modules' internal functions.
About lists of consecutive numbers ... not sure what that is referring to exactly. About type providers ... yes, I agree with you that not everyone finds a use for them. In general, I will say that the killer feature of F# and other ML-family languages is that they dramatically increase code refactorability (low-ceremony static types) and dramatically reduce lines of code (simple, 'math-y' syntax).
Multithreading is a good example. It is hard to do at a low level. And I totally get why F#'s approach helps a lot. But I find that you get most of the benefits of multithreading by splitting your task in independant subtasks that are not thread safe but do not share writable data, and run a parallel.for at the top. Occasionally you need some locking if you have a common cache but that's easy to get right.
Sure you could optimize it a little bit more by making it multithreaded at a lower level but most of the time that's enough to get 90% of the performance benefit.
I am also a bit uncomfortable with the liberty F# takes with memory. To make everything immutable you create a lot of copies in memory. All the .net performance articles I have read mostly focus on taking it easy with the garbage collector and reducing the number of allocations. Intuitively it doesn't sound like an obvious trade off (thread safety vs more garbage to collect).
About multithreading, not sure what you mean but F# definitely has parallel collections in addition to its general async capability that lets you handle concurrency in a safe way. If you haven't already, check out the Hopac project (http://hopac.github.io/Hopac/Hopac.html , scroll down to the Description section).
About memory use, yes you create copies but at the same time immutability means you can have persistent data structures which share and thus save a lot of memory. Also, in general performance is good enough that you don't really have to worry about it, and when you do, you can always measure, profile, and see what's actually causing the memory pressure.
That said, it's true that functional programming languages have a different memory profile than imperative languages, and implementations which have been designed with this profile in mind perform really well. E.g. check out OCaml's performance in this GC pause benchmark: https://making.pusher.com/golangs-real-time-gc-in-theory-and...