A whirlwind tour of object-oriented code in F# (2012)(fsharpforfunandprofit.com)
fsharpforfunandprofit.com
A whirlwind tour of object-oriented code in F# (2012)
https://fsharpforfunandprofit.com/posts/completeness-anything-csharp-can-do/
129 comments
I used to be a big Haskell programmer. While I still love the language, I've really come around to the idea that strictly evaluated functional languages like F# or OCaml are the best for programming in. You get the nice functional features but don't have the straightjacket of laziness forcing you into certain design decisions. It's really nice sometimes to be able to mix in impure, side effectful code without having to thread it through a monad. The OCaml family feels like a nice blend of good sound functional features with enough escape hatches to be productive in real world programs that might occasionally need arrays or mutable state or IO. Laziness by default also makes things like debugging or reasoning about performance frustratingly difficult. I do miss Haskell's typeclasses in these languages, though. My ideal language is basically Ocaml/F# but with Haskell's syntax and typeclasses.
I use F# daily, and to get around this limitation I use hacky custom code generation an F# script (fsx) to generated specific types.
Additionally, on cases where you’re not specifying the data of the type itself, you can use static type constraints on members. This doesn’t give you a default implementation like Haskell but you can always provide one as a function.
Btw the monadic threading is still very useful, especially when mixing impure code and mutation (when appropriate). The async and result monads, in F# computation expression form, are particularly useful.
For a good example of async + impure code, check out MailboxProcessor, which is part of the standard F# lib. Works similar to CSP/goroutine + channels/actor models; makes parallelized concurrency and message passing easy. You can also make pure mailboxes easily by recursively passing data forward, but sometimes you don’t want to for memory / gc & alloc reasons.
Additionally, on cases where you’re not specifying the data of the type itself, you can use static type constraints on members. This doesn’t give you a default implementation like Haskell but you can always provide one as a function.
Btw the monadic threading is still very useful, especially when mixing impure code and mutation (when appropriate). The async and result monads, in F# computation expression form, are particularly useful.
For a good example of async + impure code, check out MailboxProcessor, which is part of the standard F# lib. Works similar to CSP/goroutine + channels/actor models; makes parallelized concurrency and message passing easy. You can also make pure mailboxes easily by recursively passing data forward, but sometimes you don’t want to for memory / gc & alloc reasons.
Oh, for sure I still love monads. I miss Haskell's do syntax in every other language. I think it's a great design pattern that starts popping up constantly once you know where to look. My objection is being forced to use monads due to the language's lazy by default semantics. You get this problem with haskell where the IO monad eventually just pollutes a huge chunk of your code because you can't safely sequence side effects without it. Sometimes I just wanted an escape hatch that would let me do side effects that I knew to be safe/harmless. Haskell has unsafePerformIO but it truly is unsafe because you can't guarantee the execution order of your side effects, which makes it useless as an escape hatch for a lot of purposes.
Ocaml is getting something similar to ‘do’ syntax very soon (but for applicatives too!):
http://jobjo.github.io//2019/04/24/ocaml-has-some-new-shiny-...
http://jobjo.github.io//2019/04/24/ocaml-has-some-new-shiny-...
Hopefully we will see this one day: https://github.com/fsharp/fslang-suggestions/issues/243
Hopefully not :-)
It's easy to forgot the benefits of laziness: http://augustss.blogspot.com/2011/05/more-points-for-lazy-ev...
Laziness is a good default for declarative programming. Nix from NixOS is an example of a recent lazy language and benefits greatly from it.
Even in strict languages, lazy behaviour is often added, for example iterators and streams. Mixing effects and mutation with such constructs is also problematic.
Laziness is a good default for declarative programming. Nix from NixOS is an example of a recent lazy language and benefits greatly from it.
Even in strict languages, lazy behaviour is often added, for example iterators and streams. Mixing effects and mutation with such constructs is also problematic.
I'm not saying it's a replacement for either F# or OCaml, and I've only glanced at it, but F*[1] looks pretty neat. It's higher-level than F# (a lot) and has a syntax more similar to Haskell's. You can even extract programs in F# and OCaml.
[1] https://www.fstar-lang.org/
[1] https://www.fstar-lang.org/
My experience with F* is several unsuccessful hours of trying to compile hello world thanks to a complete lack of instructions for configuration and installation.
I hope it's gotten better.
I hope it's gotten better.
F* or F#? They are very different.
Years ago I was working a miserable job writing boilerplate template code where I had to sub in variables based on certain conditions, it was using a very bland language to look up data from our database and format the output. I wasn't allowed to download any software onto my work computer despite having a technical background.
So what I did instead to make my life easier was write F# to create a kind of DSL and create the template lookup scripts for me. I did it all from the browser with repl.it, and I generated dozens of scripts and saved myself a lot of time in the process.
Now I mostly use Racket, but F# is where I kind of started out. It's a fun dialect.
So what I did instead to make my life easier was write F# to create a kind of DSL and create the template lookup scripts for me. I did it all from the browser with repl.it, and I generated dozens of scripts and saved myself a lot of time in the process.
Now I mostly use Racket, but F# is where I kind of started out. It's a fun dialect.
Reads like an opening of a dystopian novel!
Heh. I was doing manual deployments because of dumb bank policies so after a lot of maneuvering I used Powershell and plink.exe to write a small, dumb version of Python's Fabric to be able to automate deployments.
I was writing Powershell in Vim while trying to keep my skunkworks project out of sight because of crappy management policies.
Sometimes you gotta make lemonade...
I was writing Powershell in Vim while trying to keep my skunkworks project out of sight because of crappy management policies.
Sometimes you gotta make lemonade...
Racket is a fantastic language. It has a solid community of great engineers, can doesn't try to hard to build hype or become a fad. I'd like to see it acquire an industry niche somehow so it can flourish.
F# is a joy to use. After a certain time, many C# developers find themselves writing in a functional style. F# makes this the default, but lets you continue using all of your existing code.
Better yet, Linux and macOS support via .Net Core is excellent. F# on .Net Core is now a powerful alternative to Node.js.
Better yet, Linux and macOS support via .Net Core is excellent. F# on .Net Core is now a powerful alternative to Node.js.
The thing I find most interesting about a lot of C# developers I've worked with, trained, etc. is their understanding of "Object Oriented" programming. I have the same discussion over and over again.
"Have you looked at F# even to just to see how it works?"
"I won't ever use it. I'm an OO programmer, and it suits me just fine!"
"Do you use LINQ, and understand you can pass functions into methods etc.?"
"Yeah, it makes things so much easier. I don't understand why people wouldn't use it."
"That's really more like functional programming"
"...."
Edit:formatting
"Have you looked at F# even to just to see how it works?"
"I won't ever use it. I'm an OO programmer, and it suits me just fine!"
"Do you use LINQ, and understand you can pass functions into methods etc.?"
"Yeah, it makes things so much easier. I don't understand why people wouldn't use it."
"That's really more like functional programming"
"...."
Edit:formatting
It's almost to the point where the deciding factors in choosing between (C#-style) OOP and (F#-style) FP are:
- Do you want your data types in one line or 20?
- Pattern matching, or large concretions of if-statements?
- Race conditions: Quality problem, or fun puzzle?C# has most of the same pattern matching functionality at this point
There's no compiler warning for incomplete matches, and without discriminated unions it's pretty verbose to write pattern-match friendly types
C# has support for most F# features, they're just often awkward to use
C# has support for most F# features, they're just often awkward to use
You can get a pretty reasonable facsimile using some libraries I made:
Discriminated unions: https://github.com/mcintyre321/OneOf and One line value objects: https://github.com/mcintyre321/ValueOf
Discriminated unions: https://github.com/mcintyre321/OneOf and One line value objects: https://github.com/mcintyre321/ValueOf
I haven't had a need for ValueOf yet, but OneOf has saved my ass now more times than I can count. Thank you so very much for it!
I'm constantly impressed by ways people manage to extend C# like this. I'll have to try this out :)
There are C# programmers like that I suppose. There are also many C# programmers who buy into multi paradigmism, they fee no ideological conflict between using OO or FP as needed. C# supports FP well enough, and gets better every release (eg pattern matching). It’s difficult to compete with C#, especially when F# is feeding features into it.
Hopefully F# feeds the ability to have functions at the root of a module into C#. It's a small thing, but needing to put pure functions on static classes gets old after a while.
I know local functions are a recent ish addition to C#. Hoping they keep going down that road.
I know local functions are a recent ish addition to C#. Hoping they keep going down that road.
C# has a set of design constraints that can be annoying, but they make the language consistent and extremely resilient. It isn't up to the whimsies of the designers either, Anders and company went one way with C# and a completely different way with TypeScript (given its need to fit in with Javascript).
They can be annoying, I guess, but once you are used to it you don't really notice they are missing. It is annoying if you have to switch languages often, I'm pretty sure I would need a few weeks to get re-acclimated if I had to go back to C# from using TypeScript for so long.
They can be annoying, I guess, but once you are used to it you don't really notice they are missing. It is annoying if you have to switch languages often, I'm pretty sure I would need a few weeks to get re-acclimated if I had to go back to C# from using TypeScript for so long.
> After a certain time, many C# developers find themselves writing in a functional style
If you can't move to F# or find its tooling abysmal and slow then I have a library [1] that makes the inertia flow positively in the functional direction in C#
https://github.com/louthy/language-ext/
If you can't move to F# or find its tooling abysmal and slow then I have a library [1] that makes the inertia flow positively in the functional direction in C#
https://github.com/louthy/language-ext/
After learning f# I had to go back to c#. You library made it bearable. Also the reader.md and some of your more hidden articles are amazing. Thank you, and the other contributors so much, amazing work.
My current strategy is to hook my colleges in with languag ext until they move to f# themselves.
My current strategy is to hook my colleges in with languag ext until they move to f# themselves.
Would love to use F# with Unity, but the typical high allocation rates that come with the functional language territory scare me. Looked at your library, it's very interesting. I saw your docs note about the allocation efficiency of Map, would like to hear more. Could you characterize the library's general allocation story?
I've done a short write-up about this:
https://github.com/louthy/language-ext/wiki/Performance
https://github.com/louthy/language-ext/wiki/Performance
Terrific info, thanks! Looking forward to using it.
Hah, the internet is such a small place.
I thought that library looked familiar, and realised I was looking at it earlier today when I set up some F# job filters on stackoverflow (you're the only F# job on there that doesn't involve moving to London).
I thought that library looked familiar, and realised I was looking at it earlier today when I set up some F# job filters on stackoverflow (you're the only F# job on there that doesn't involve moving to London).
C# for the most part does a decent job with Functional Programming, but it still leans very heavily towards statements instead of expressions. Even the newly introduced pattern patching (a common FP idiom) ended being a switch statement - perplexing decision because expressions are so central to good FP code. And if you were in imperative land, you didn't really need pattern matching so much in the first place; most developers will be fine writing if conditions.
I hope they fix these warts. It can soon be a good alternative to Go for real native applications.
I hope they fix these warts. It can soon be a good alternative to Go for real native applications.
C# 8.0 will have a switch expression: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh....
As C# gradually becomes F#, I have to wonder, why not just use F#?
Ah, the same old refrain [1]
[1] https://github.com/louthy/language-ext/wiki/%22Why-don't-you...
[1] https://github.com/louthy/language-ext/wiki/%22Why-don't-you...
Nice article, thanks for sharing.
I'm sure there are people out there debating F# vs C# for a new project, and might not realize how many future C# features are already in F# though.
I'm sure there are people out there debating F# vs C# for a new project, and might not realize how many future C# features are already in F# though.
You aren't wrong, but a lot of people are only comfortable in one language/style of language (so either just say Java/C#/c++ or maybe all Algol derived languages). Growing beyond that can be scary until you've done it a couple times if you wait until later in your career to start trying things like say Lisp or Haskell.
Node has its place, i wouldn’t call F# an alternative to it. The node community is absolutely fantastic. F# is also an amazingly powerful language and im happy using it on the back end
What is Node's place?
The first stepping stone the front-end folks take into server side programming. :D
What would you choose instead if you needed to write a simple web server?
Simple web servers are already written for me. If I'm serving static files, I'll just use a CLI tool or S3.
If I'm making a simple API, I've already moved into territory where I'd prefer to use C# or something like that. The ecosystem is better and you can write it to avoid runtime gotchas.
Big languages/stacks can still write tiny programs.
If I'm making a simple API, I've already moved into territory where I'd prefer to use C# or something like that. The ecosystem is better and you can write it to avoid runtime gotchas.
Big languages/stacks can still write tiny programs.
Considering we're in an F# thread, it makes sense that both alternatives to Node.js mentioned were part of the Microsoft stack (C# and F#). This furthers my conclusion that people just prefer the tools they're already familiar with, for better or worse.
I'm much more familiar with Node and PHP than .NET. I've only been able to use .NET on one project professionally, and while the language (C#) is missing some of the type safety I enjoy, it's much more solid. I almost never had runtime errors or found immature libraries.
Don't assume everyone is a fanboy/fangirl just because they have a recommendation.
Don't assume everyone is a fanboy/fangirl just because they have a recommendation.
Before making that conclusion, try asking some people who are comfortable with a handful of languages which they would use and why.
F# with Giraffe is super simple to get up and running and it fits into the rest or the ASP.NET Core ecosystem
Probably Kotlin, maybe Go or Python.
Been using F# on personal projects and C# at work. I noticed my C# coding gone high quality once I got into functional thinking. It is highly recommended for anyone to check/learn F#. F# is my goto lang. now to competitive programming too. I believe F# and ML will make a great combo, but python is still leading.
Unlike most commentors my experience with F# hasn't been stellar.
I feel the language itself is well designed and the community is great but there is just so much of it.
Any source code that i try to go through is sprinkled with so many new keywords, so many different way of combining stuff, that there seems to be so many syntactical stuff going on. It is really making me struggle.
It just feels like a language where the maintainers are going overboard with. And I am sure that once I understand it, I would love it, but the path to get there is so hard.
Pretty much no tutorials or articles are out there and reading sources for small projects is not viable for me either due to the keyword noise and too many ways to do something.
I did not feel anything like this when I taught myself python, ES6, lua, Crystal etc. F# just feels too big.
Any source code that i try to go through is sprinkled with so many new keywords, so many different way of combining stuff, that there seems to be so many syntactical stuff going on. It is really making me struggle.
It just feels like a language where the maintainers are going overboard with. And I am sure that once I understand it, I would love it, but the path to get there is so hard.
Pretty much no tutorials or articles are out there and reading sources for small projects is not viable for me either due to the keyword noise and too many ways to do something.
I did not feel anything like this when I taught myself python, ES6, lua, Crystal etc. F# just feels too big.
I agree, F# is hard to learn. It took me a few months of tinkering to be able to express myself in it.
Good entry points: Don Syme - his "F# Code I Love" talk has been recorded a few times: https://www.youtube.com/watch?v=aw2BAxG3bdM. I recommend catching a few versions.
Scott Wlaschin - His talks are also great: https://www.youtube.com/watch?v=srQt1NAHYC0. He also runs https://fsharpforfunandprofit.com/ which is a treasure trove.
And I found Isaac Abraham's book excellent and breezy to read: https://www.manning.com/books/get-programming-with-f-sharp
Now that I'm over the hump, I think F# code is far more readable than other languages I'm well versed in (C++/C#). Probably my favorite thing about F# is the strict top-down dependencies. You can open a project and read it in order, and understand it without having to hop around a bunch.
And since most programs can be written in far fewer lines in F#, code written in it ends up feeling very small and economical.
Good entry points: Don Syme - his "F# Code I Love" talk has been recorded a few times: https://www.youtube.com/watch?v=aw2BAxG3bdM. I recommend catching a few versions.
Scott Wlaschin - His talks are also great: https://www.youtube.com/watch?v=srQt1NAHYC0. He also runs https://fsharpforfunandprofit.com/ which is a treasure trove.
And I found Isaac Abraham's book excellent and breezy to read: https://www.manning.com/books/get-programming-with-f-sharp
Now that I'm over the hump, I think F# code is far more readable than other languages I'm well versed in (C++/C#). Probably my favorite thing about F# is the strict top-down dependencies. You can open a project and read it in order, and understand it without having to hop around a bunch.
And since most programs can be written in far fewer lines in F#, code written in it ends up feeling very small and economical.
>Pretty much no tutorials or articles are out there and reading sources for small projects is not viable for me either.
The lack of a good online tutorial is a problem for me as well. F# For Fun and Profit is decent, but I've not found it a good substitute for a book/tutorial.
The lack of a good online tutorial is a problem for me as well. F# For Fun and Profit is decent, but I've not found it a good substitute for a book/tutorial.
The problem is F# doesn't get enough resources internally at Microsoft. How many times has VS shipped missing the latest version of F# tools? In terms of community, it's tiny. If I want to do functional programming, F#/.NET isn't the strongest option. I have several books on F# and as much as I'd like to learn/use it beyond toying around, I can't help but feel like all it's worth using for is tinkering (outside of the few shops that use F# extensively.)
I find this to be an interesting cultural phenomenon, this thing where people in .NET-land are skittish about F# because it's not so tightly controlled by Microsoft.
Meanwhile, I'm pretty sure nobody even wants Oracle to be getting involved in Kotlin or Scala or Clojure.
Meanwhile, I'm pretty sure nobody even wants Oracle to be getting involved in Kotlin or Scala or Clojure.
I think that F# has a difficult spot in between. Microsoft has enough control over it to effectively kill it (mostly via the ecosystem), but at the same time does not step up and actually "own" it. Since it's still "their" language, anyone considering it would like to see they're still invested in it, which isn't all too obvious at the moment. On the other hand, if they'd distance themselves more, another organization could step up, become the big name behind it, and provide good stewardship. Right now it's just sort of hanging on the side and (at least) outsiders don't know what's going to happen with that, which doesn't inspire much confidence. They just don't seem to care much.
> this thing where people in .NET-land are skittish about F# because it's not so tightly controlled by Microsoft.
Microsoft's great tooling is what has made (traditionally) it sticky for a lot of developers. F#'s tooling from Microsoft has been a half-hearted effort (organizationally, not speaking of the effort that the F# guys have put in.)
Microsoft's great tooling is what has made (traditionally) it sticky for a lot of developers. F#'s tooling from Microsoft has been a half-hearted effort (organizationally, not speaking of the effort that the F# guys have put in.)
The irony is that F#s releases are in lock-step with the Visual tools team releases and schedule.
I must vehemently disagree.
From: https://github.com/dotnet/fsharp/issues/2400
"GiorgioG commented on Oct 19, 2017 @masaeedu - Not to beat a dead horse, but we've been waiting for an RTM release of this since May when VS2017 first RTM'd. We were then told it would likely come in the July release of VS, we're now nearing the tail end of October with no clear idea when we'll get it. It's not @cartermp 's fault, just the reality that MS has not made it a high priority (judging by their actions, not their words.) In summary, if you want to use F#, use VSCode, it has excellent support for F#, as long as you realize it's not Visual Studio, it's a souped up text editor."
From: https://github.com/dotnet/fsharp/issues/2400
"GiorgioG commented on Oct 19, 2017 @masaeedu - Not to beat a dead horse, but we've been waiting for an RTM release of this since May when VS2017 first RTM'd. We were then told it would likely come in the July release of VS, we're now nearing the tail end of October with no clear idea when we'll get it. It's not @cartermp 's fault, just the reality that MS has not made it a high priority (judging by their actions, not their words.) In summary, if you want to use F#, use VSCode, it has excellent support for F#, as long as you realize it's not Visual Studio, it's a souped up text editor."
Perhaps it's not the case anymore, but I meant more that F# language releases used to be delayed until the Visual Tools team was ready to release a new Version for Visual Studio. So essentially, the F# releases seemed to be held up. Perhaps I'm remembering wrong and/or this has changed since the .Net core support came in.
Usually those are the same people that preach OpenJDK, while forgetting that 90% of the contributions come from Oracle.
And that Oracle alongside Sun and IBM has been there since the begging, and other than IBM, no one else made an offer to buy Sun.
Or if the JVM had died with Sun their languages wouldn't even exist.
And that Oracle alongside Sun and IBM has been there since the begging, and other than IBM, no one else made an offer to buy Sun.
Or if the JVM had died with Sun their languages wouldn't even exist.
openjdk exists though and is broadly maintained. i don't know how many people use mono (i honestly don't know) but CLR seems to be the only runtime for F#.
Latest example, WinUI roadmap doesn't consider F# relevant.
https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...
Guess what is one of the complains on the feedback thread?
https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...
Guess what is one of the complains on the feedback thread?
What is the strongest option for functional programming then? I love Clojure as a language but it's almost impossible to find decent jobs with it in my area.
Scala is probably the most pragmatic functional programming language to get a job in. It's on the JVM and you can use all the Java libraries, and it also lets you fall back to an imperative style if you need to.
That sounds exactly the same as F# (except there might be more jobs in scala).
F# is on .NET CLR and you can use all the .NET libraries, and it lets you fall back to an imperative style if you need to!
F# is on .NET CLR and you can use all the .NET libraries, and it lets you fall back to an imperative style if you need to!
> you can use all the .NET libraries
did you try it?
Hint: there is a lot of things required before F# could use latest WinUI or WPF
did you try it?
Hint: there is a lot of things required before F# could use latest WinUI or WPF
I wouldn't call those libraries. If you have something that's actually just a library, using it from F# should not be a problem.
Try to use EF, WCF, UWP, WPF from F#.
EF isn't really needed with Dapper and the available SQL type providers. Even still it's totally naturally to have a C# project holding the base EF stuff which you reference from your F# projects
Try to use that argument to sell F# to the large majority of .NET shops.
The vast majority of .Net shops would run shrieking when faced with F# code. I still run into people regularly that shun the var keyword for type inference in C# because they think it is actually the evil old VB6 Variant type.
Yep that was kind of my point.
[deleted]
Well, in these cases it's very similar to F#, except it's based on .NET and has different syntax. I guess the main point of the comment above is lacking IDE support - refactoring tools don't exist and autocompletion is also not excelent. Do you know some decent tools for Scala? I don't know much about it, but it could be a very good language if IntelliJ had full support for that.
IntelliJ does have have full support for Scala (through an official plugin): https://www.jetbrains.com/help/idea/discover-intellij-idea-f...
What about remote work?
Isn't VSCode & Ionide plugin good enough?
VSCode doesn't hold a candle to Visual Studio. I know that's going to be an unpopular opinion around here. Sure there's Rider (which I own/support/like), but if MS can't be bothered to provide first-rate support for F#, why should I bother investing time into learning F# when there are more popular alternatives?
Here’s a Tour of F# by Microsoft:
https://docs.microsoft.com/en-us/dotnet/fsharp/tour
https://docs.microsoft.com/en-us/dotnet/fsharp/tour
I just bought Scott's book on Railway Oriented Domain Driven Design. So far so good. I am the domain expert though, so no revelation there.
The modeling of state machines using types and functions is pretty revolutionary to me for where I'm currently at development skill wise. Everything just seems so clean and elegant.
The modeling of state machines using types and functions is pretty revolutionary to me for where I'm currently at development skill wise. Everything just seems so clean and elegant.
The book is "Domain Modeling Made Functional"
https://fsharpforfunandprofit.com/books/
https://fsharpforfunandprofit.com/books/
While there's nothing you can do in C# that cannot be done in F#, the reverse is not true. The biggest thing that comes to mind is to influence the direction of the other language (C#). I've heard it said many times that if you want to see what features will be in C# in the future, look at F#. Too many features to cite (though Linq is the biggest that comes to mind) were in production use in F# long before they arrived in C#.
> While there's nothing you can do in C# that cannot be done in F#
Really? When did F# start supporting pointers?
> to influence the direction of the other language (C#)
Lately, it seems it's the other way around: C# is introducing features like Span<T> or default interface members and F# is (quickly) catching up.
Really? When did F# start supporting pointers?
> to influence the direction of the other language (C#)
Lately, it seems it's the other way around: C# is introducing features like Span<T> or default interface members and F# is (quickly) catching up.
To your last point, with the freedom they seem to feel after the Core breakage (like Span/Memory) C# might start innovating on its own again instead of just taking awesome pieces from f# and making them part of C#.
There's actually a couple of minor things (like covariance). I was surprised to learn F# doesn't support creating sealed methods on classes the other week when I was extending some OO code.
Thankfully F# and C# mix so well together I could've written a quick C# project to do it if needed, but I didn't want to break up my F# project into two + some C# glue
In the vast majority of cases though what you said is true. Discriminated unions, records, computation expressions, and type providers are total game changers
Thankfully F# and C# mix so well together I could've written a quick C# project to do it if needed, but I didn't want to break up my F# project into two + some C# glue
In the vast majority of cases though what you said is true. Discriminated unions, records, computation expressions, and type providers are total game changers
> Anything C# can do...
Yes, yes, you can do anything in F#, but what should you do?
My opinion is that that what F# is missing is a good set of idioms and a strongly opinionated set of guidelines. To my beginner's eyes, every F# codebase I've seen feels like it's written in a completely different language; it's like the opposite of Python's "one right way to do everything".
I've heard that F# is great for domain-specific languages, but in most cases a DSL is the cardinal opposite of what I want. I want a common language that I can use to express a multitude of different concepts. It seems like all of the guidance out there about F# is about showing off features, being extremely clever, or using F# to teach functional concepts, not actually about writing useful applications.
Yes, yes, you can do anything in F#, but what should you do?
My opinion is that that what F# is missing is a good set of idioms and a strongly opinionated set of guidelines. To my beginner's eyes, every F# codebase I've seen feels like it's written in a completely different language; it's like the opposite of Python's "one right way to do everything".
I've heard that F# is great for domain-specific languages, but in most cases a DSL is the cardinal opposite of what I want. I want a common language that I can use to express a multitude of different concepts. It seems like all of the guidance out there about F# is about showing off features, being extremely clever, or using F# to teach functional concepts, not actually about writing useful applications.
As a long time C# dev who has dabbled with F#, I kind of feel the same.
I always find myself structuring appa like an OO app, which invariably results in something that feels wrong.
For someone for which OO is so entrenched, it's really difficult to think differently - and there doesn't seem to be an idiomatic way to write F# code (not that I've found, anyway); every code base seems to take a different approach.
I always find myself structuring appa like an OO app, which invariably results in something that feels wrong.
For someone for which OO is so entrenched, it's really difficult to think differently - and there doesn't seem to be an idiomatic way to write F# code (not that I've found, anyway); every code base seems to take a different approach.
I started F# lately and found it absolutely amazing. I come from heavy C# programming, and always find myself reaching out to have sane default like immutable types.
But unfortunately there are still lot of libraries out there for F# which don't support .net core fully. Especially db access ones.
But unfortunately there are still lot of libraries out there for F# which don't support .net core fully. Especially db access ones.
... and exhaustive matching: https://github.com/mcintyre321/OneOf
I'm not saying it's as good as writing F#, or that C# shouldn't include these features of course.
I'm not saying it's as good as writing F#, or that C# shouldn't include these features of course.
If you want to try F#, here's the full F# compiler in the browser run using WebAssembly. Very fun to play with: https://tryfsharp.fsbolero.io/
And it also compiles to Javascript: https://fable.io/repl/
You can browse through some sample apps using the side bar on the left.
You can browse through some sample apps using the side bar on the left.
Thanks for posting that. Fable is fantastic
I think several interesting points were brought up in this thread regarding the assumption of functional aspects presented in F# by C#. LINQ being the most popular example. I am currently lead to believe that a purely functional application development domain is potentially an overreach of theory in terms of building things that can interact with the real world in very complex and 'functionally-leaky' ways.
My biased perspective as someone who hasn't really used F# very much is this: Perhaps an imperative language such as C# 8.0, with a few high-value functional features sprinkled in, is actually the best of both worlds when viewed through the lens of someone who has to interface with really weird business systems. I use imperative techniques for handling remote calls, exception handling, etc. Then, when I need to work with my internal business logic or models, I can use more functional techniques.
Based on my own understanding and other comments presented here, C# does not seem to preclude the usage of functional approaches to solving problems if you have the discipline and experience to do so. C# also brings with it a host of other benefits in terms of tooling support and simply being able to find other developers who can understand your codebase.
My biased perspective as someone who hasn't really used F# very much is this: Perhaps an imperative language such as C# 8.0, with a few high-value functional features sprinkled in, is actually the best of both worlds when viewed through the lens of someone who has to interface with really weird business systems. I use imperative techniques for handling remote calls, exception handling, etc. Then, when I need to work with my internal business logic or models, I can use more functional techniques.
Based on my own understanding and other comments presented here, C# does not seem to preclude the usage of functional approaches to solving problems if you have the discipline and experience to do so. C# also brings with it a host of other benefits in terms of tooling support and simply being able to find other developers who can understand your codebase.
I really encourage you to use F#, as someone who's done C# for a long time I find F# (while not perfect) does strike near to that ideal balance of FP / imperative you speak of. Writing functional code naturally is a breeze, while the language isn't going to punish you or feel awkward if you need to drop in some mutable state or OO programming
On the contrary, you have a huge advantage to interface with the dirty world using F# thanks to exhaustive pattern matching and you can make everything type safe to render invalid state unrepresentable.
For all the love Microsoft has been getting these days, I still don’t get how I’m supposed to write C# or F# without Visual Studio and Windows. Am I missing something? VSCode doesn’t support these languages, right? I’m a person who spent a long time trying to write Java in Vim, but switched to IntelliJ and wouldn’t want to write C#/F# without some comparable IDE.
F# in VS Code: https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/g...
F# in .NET CLI: https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/g...
C# in VS Code: https://docs.microsoft.com/en-us/dotnet/core/tutorials/with-...
Supported Linux versions: https://docs.microsoft.com/en-us/dotnet/core/linux-prerequis...
Supported macOS versions: https://docs.microsoft.com/en-us/dotnet/core/macos-prerequis...
Rider's also an option: https://www.jetbrains.com/rider/
F# in .NET CLI: https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/g...
C# in VS Code: https://docs.microsoft.com/en-us/dotnet/core/tutorials/with-...
Supported Linux versions: https://docs.microsoft.com/en-us/dotnet/core/linux-prerequis...
Supported macOS versions: https://docs.microsoft.com/en-us/dotnet/core/macos-prerequis...
Rider's also an option: https://www.jetbrains.com/rider/
Thank you for these links. I will look at them! But I am wondering qualitatively, along the lines of whb07’s sibling answer: is the experience good? Is it as good as on Visual Studio?
VS Code doesn't work for the older .NET Framework stuff (pre .NET Core).
As for doing .NET Core stuff, it depends a lot on your setup of both Code & Visual Studio. Code has some nice features that you would need extensions or an upper tier VS version to get. Code can be faster at times as well.
At the end of the day it is a different experience with a few pros & a few cons. It will greatly depend on the way you program.
As for doing .NET Core stuff, it depends a lot on your setup of both Code & Visual Studio. Code has some nice features that you would need extensions or an upper tier VS version to get. Code can be faster at times as well.
At the end of the day it is a different experience with a few pros & a few cons. It will greatly depend on the way you program.
> VS Code doesn't work for the older .NET Framework stuff (pre .NET Core).
This is not true for F#.
This is not true for F#.
C# was usable in VS Code even 3 years ago
How is it these days? Is it “usable” or actually something you want to and enjoy using? Will I be left wanting Visual Studio? I mean I really enjoy IntelliJ, it makes programming Java like slicing butter. But I do want to try F#, people talk so highly of it.
I work in VS Code (backed by Omnisharp language server) and I like it more than Visual Studio (it seems to be faster and has some good extensions). But it's not the same and does not contain all the features (and all extensions). Sometimes it annoys me that the debugger does not work as well. Other things that may annoy you is that you can't install R# and that VS Code basically ignores your solution file and uses directory structure.
My background is mostly .NET and web. I like VS Code a lot for JS/TS, but I hesitate to recommend it for C#. Using it about a year ago, I felt like I was missing a lot of the power of "real" Visual Studio and many language features were fairly buggy on my Mac.
Intellisense was working 100%, but I stopped using it after that because I switched platforms. I don't believe it's worse today, VS Code as an editor is a joy to use (I use it with TypeScript).
> I really enjoy IntelliJ, it makes programming Java like slicing butter.
In that case, I think you want an actual IDE and VS Code is not that. The options you have for .Net are Visual Studio and Rider (which is from the same company as IntelliJ and shares a lot of code with it).
In that case, I think you want an actual IDE and VS Code is not that. The options you have for .Net are Visual Studio and Rider (which is from the same company as IntelliJ and shares a lot of code with it).
It (well, OmniSharp) is 95%. The 5% can be pretty frustrating (such as the lack of override autocomplete).
I actually find the F# experience using VS Code + Ionide plugin in a Mac beyond what I’d ever thought was possible without something like a full blown ide.
The maintainers of Ionide also just got Microsoft $$ so that’s even better news.
But working with F# and it’s strong types while at the same being able to write something similar to Python should be a giant selling point to anyone.
If you’re on a Mac or linux just download the .net core sdk and you’re ready to go
The maintainers of Ionide also just got Microsoft $$ so that’s even better news.
But working with F# and it’s strong types while at the same being able to write something similar to Python should be a giant selling point to anyone.
If you’re on a Mac or linux just download the .net core sdk and you’re ready to go
VS Code supports both languages. Check out Ionide for F# support. You can also use JetBrains Rider. Visual Studio also works on macOs btw and if nothing satisfies your taste then you can always just use a plain text editor because all you need to build, run and test your code is provided by the dotnet CLI.
You can use Rider which is a very good crossplatform JetBrains IDE. I found it very fast too (I use it on Fedora in my laptop)
Rider is in some ways better than VS. If you have moderately large solutions and a powerful desktop, you will frequently be butting up against the 32-bit memory limit of VS, especially if you tear off any editor windows to put on another monitor (I don't know why this exacerbates the problem so badly, but I've been seeing it steady since VS 2013). Once you get around 2GB of memory in use, things drag to a crawl.
I recently switched to Rider after finally giving up on the performance issues in Visual Studio - VS is a fantastic IDE, but I'm sick of the perf issues and having my laptop permanently sounding like it's going to take off...
After setting up the theme and font and such... I love Rider! It's extremely customisable, and actually has some features than VS doesn't. And of course it's backed by ReSharper too. Highly recommended it!
After setting up the theme and font and such... I love Rider! It's extremely customisable, and actually has some features than VS doesn't. And of course it's backed by ReSharper too. Highly recommended it!
>I’m a person who spent a long time trying to write Java in Vim, but switched to IntelliJ and wouldn’t want to write C#/F# without some comparable IDE.
Rider is the comparative option for you. I wouldn't waste much time on VS Code, personally.
Rider is the comparative option for you. I wouldn't waste much time on VS Code, personally.
Plugin for F# VSCode:
https://marketplace.visualstudio.com/items?itemName=Ionide.I...
One line data types https://github.com/mcintyre321/ValueOf
this is really interesting.
I've been meaning to dig my teeth into F# sometime soon because of its highly functional base.
I've been meaning to dig my teeth into F# sometime soon because of its highly functional base.
I missed the examples with EF, WPF, Windows Forms, UWP, WCF.
OO in F#. there goes the language...
Considering that the article is from 2012, it "went" a long time ago.
OOP is not idiomatic F#. It is mostly for interop with C#.
I would not say that, sometimes it's quite powerful to combine these paradigms. I think they would not design a language for CLR only to force them to create a huge interop subsystem.
You are right, however, that OOP should not be the default way to write things in F#.
You are right, however, that OOP should not be the default way to write things in F#.
I definitely appreciate being able to drop into an OOP style when I find it's necessary. In a talk Don Syme (F#'s original designer) goes into aspects of OO he enjoys, those understands the usefulness of, and those he does not enjoy. I believe it was F# Code I Love, which gives some good insight into the thinking behind the language.
Not true. You actually are not to use OO in F# unless you really have to and there are certain cases where it helps
F# is a pragmatic dual paradigm language where both OO and FP are fully supported and encouraged. There is no "[don't use OO in F# unless you really have to]" sentiment anywhere.
It's a pity the tooling is comparatively immature, with F# (or at least that was my experience last time I tried to develop with it). I think Rider is getting there, though.
To go into more detail, the initial implementation in Rider was limited to not much more than syntax highlighting. Inspections were fairly limited, ASP.NET MVC integration was not as featureful.
On the C# side, it's much more developed and refined. Within Rider, it's obviously been the main focus so I suppose it's only natural it's received more polish.
To go into more detail, the initial implementation in Rider was limited to not much more than syntax highlighting. Inspections were fairly limited, ASP.NET MVC integration was not as featureful.
On the C# side, it's much more developed and refined. Within Rider, it's obviously been the main focus so I suppose it's only natural it's received more polish.
I've been developing F# in Rider for the last 4 weeks, and especially the last update made a huge step forward. It's stable, fast, the test-runner works perfectly, etc. It's definitely not at the same level as the C# tooling yet, but it's good enough to be productive. (I'm on macOS by the way, building Xamarin apps).
Glad to hear it's improved!