Introduction to the 'Why use F#' series (2012)(fsharpforfunandprofit.com)
fsharpforfunandprofit.com
Introduction to the 'Why use F#' series (2012)
https://fsharpforfunandprofit.com/posts/why-use-fsharp-intro/
35 comments
I recently came back to F# after a long-ish (about 5 years) hiatus, and I'm coming to agree. It does lack some of the features of more purely functional languages, but, in return, you get some very pragmatic features that I expect to be a net win for maintainability in a team setting.
The one thing I still wish I could have is some sort of higher-kinded polymorphism, because I think that could make the business domain modeling even easier than it already is. But, as a Scala dropout, I also appreciate the eminent sobriety of being so cautious about introducing features that would create friction with the rest of the ecosystem.
The one thing I still wish I could have is some sort of higher-kinded polymorphism, because I think that could make the business domain modeling even easier than it already is. But, as a Scala dropout, I also appreciate the eminent sobriety of being so cautious about introducing features that would create friction with the rest of the ecosystem.
Have you taken a look at FSharpPlus [0] ? It attempts at... "reproducing" higher-kinded polymorphism by means of abstract classes and operators for Functor, Monad, Applicative, and so on. It's a bit clunky (and if compilation goes wrong, you may get some epic-length error messages), but when you set up your tipes just right, it's pretty magical.
[0] https://github.com/fsprojects/FSharpPlus
[0] https://github.com/fsprojects/FSharpPlus
Seconding the use of FSharpPlus for this kind of programming. It's certainly not for beginner F# programmers, but the library is very well-crafted by some expert F# developers who really know what they're doing.
"For me, F# is a beautiful, goldilocks language that has both the expressiveness and elegance of Python/Ruby and the strictness/compile-time safety of a statically-typed language, all backed by the .net ecosystem. There's also low ceremony to get things done in F# and I use it for everyday tasks, like reading CSVs and loading relational databases."
If I replaced F# for Scala in this paragraph it would sum up my feelings about Scala (swapping .net for Java obv).
I'm intrigued by F#, would love to try it one day. I definitely agree about the intersection between DDD and these sorts of FP languages. It's still not fully appreciated how nicely these two things fit together.
If I replaced F# for Scala in this paragraph it would sum up my feelings about Scala (swapping .net for Java obv).
I'm intrigued by F#, would love to try it one day. I definitely agree about the intersection between DDD and these sorts of FP languages. It's still not fully appreciated how nicely these two things fit together.
Agree, F# is my go-to language for personal projects and client libs at work when I can get away with it. You can't beat the combination of the expressive power of F# with the entire .NET/ASP.NET (Giraffe) ecosystem underneath it.
Speaking of domain-driven design, the author of this article wrote a great book called 'Domain Modeling Made Functional', which I heartily recommend (even if you don't have a specific interest in learning F#) https://www.amazon.com/Domain-Modeling-Made-Functional-Domai...
An excellent book and one that I used together with Stylish F# and F# Deep Dives to get my current job. Been writing F# full time now for over a year and I must say that it's nothing short of a brilliant language.
Came here from 10 years of Scala with no .NET experience what so ever.
Just overall one of the nicest experiences so far. 9/10, would recommend!
Came here from 10 years of Scala with no .NET experience what so ever.
Just overall one of the nicest experiences so far. 9/10, would recommend!
I have been debating whether to learn Scala or F# in my spare time. F# seems to be the more pragmatic choice. Doesn't go the insane way of FP that Scala does with complicated libraries or convoluted inheritance hierarchies. The Scala community seems more divided than the F# one with multiple competing ecosystems/libraries for achieving the same thing. My interest lies in webdev/backend and F# seems to be an obvious choice with asp.net and it's supplanting libraries. Not sure how Scala fares, but i guess it's not the primary use case for it. On the surface I kind of like the syntax of Scala, it's very familiar but I fear that I would get more frustrated the deeper I would dig because eventually you have to integrate other people's code and the way most of it is written looks to be like haskell in disguise. Not really sure about the pros/cons.
I've used Scala, Clojure, Haskell, and F#. I'd say F# does a great job of providing a happy middle path between the strict side effect management of Haskell and the advanced OOP features of Scala. It also brings the well-designed ASPNET CORE stack.
If I was starting from scratch and just wanted to learn, I'd say you'll learn plenty from any of them. Haskell has the most to teach about purity in FP, Scala the most about OOP, and Clojure the most about metaprogramming.
F# has the most to offer for just getting things done quickly. It is a language of practical compromises. It's not the most pure, it doesn't bring the most advanced OOP, and it's metaprogramming is tricky. However F# is what I grab first when I want to build production software quickly and safely.
If I was starting from scratch and just wanted to learn, I'd say you'll learn plenty from any of them. Haskell has the most to teach about purity in FP, Scala the most about OOP, and Clojure the most about metaprogramming.
F# has the most to offer for just getting things done quickly. It is a language of practical compromises. It's not the most pure, it doesn't bring the most advanced OOP, and it's metaprogramming is tricky. However F# is what I grab first when I want to build production software quickly and safely.
Veteran Scala dev here. I'm not here to convince you to choose it over F# but I can tell you that it's a beautiful language. Scala is used heavily for backend web dev, in fact, it's all I use it for.
Don't worry about advanced concepts, you'll get to those when / if you need them. They have their uses but it depends on what you're working on. I think many people just succumb to the blub paradox too quickly with these sorts of languages. It's a real shame.
It's honestly overstated how hard it is. I started as a junior dev with Scala and was highly productive within months. I don't think there's anything special about me. I was highly motivated by my love for the language I guess.
Don't worry about advanced concepts, you'll get to those when / if you need them. They have their uses but it depends on what you're working on. I think many people just succumb to the blub paradox too quickly with these sorts of languages. It's a real shame.
It's honestly overstated how hard it is. I started as a junior dev with Scala and was highly productive within months. I don't think there's anything special about me. I was highly motivated by my love for the language I guess.
[deleted]
if I might ask, where do you work? and/or in what domain?
Work at a large:ish private bank i Sweden basically doing "digitization" of all customer processes.
I'm mostly doing Golang/Typescript nowadays and worked with C# in the past, but F# looks really intriguing.
While I'm generally productive with Golang, I'm not really happy with the language itself. It's a bit too simplistic for my taste. F# on the other hand looks like pure elegance. The big question is how long it takes you to be really productive with it, say for a GraphQL/REST backend for some SPA. I'm also a bit worried about the small community. I guess if things go wrong, you can always fallback on C#. Any tips to get up to speed quickly?
While I'm generally productive with Golang, I'm not really happy with the language itself. It's a bit too simplistic for my taste. F# on the other hand looks like pure elegance. The big question is how long it takes you to be really productive with it, say for a GraphQL/REST backend for some SPA. I'm also a bit worried about the small community. I guess if things go wrong, you can always fallback on C#. Any tips to get up to speed quickly?
Download Rider, and use it to generate a dotnet core 5.0 web api in F#.
That will give you a restful api using F# that you can immediately modify to build out an endpoint. Figure out how to add in authn/authz using just regular aspnet core and you'll be ready to go. I like dapper for data access in F#, but plenty prefer a more traditional ORM like nhibernate or EF6.
You'd be surprised how much you can do with F#, the only caveat is learning to read docs in C#. Since that's considered the lingua franca of .NET, almost all docs will be in C# and need to be transliterated into F#. This is a skill that only takes a day or two to learn.
That will give you a restful api using F# that you can immediately modify to build out an endpoint. Figure out how to add in authn/authz using just regular aspnet core and you'll be ready to go. I like dapper for data access in F#, but plenty prefer a more traditional ORM like nhibernate or EF6.
You'd be surprised how much you can do with F#, the only caveat is learning to read docs in C#. Since that's considered the lingua franca of .NET, almost all docs will be in C# and need to be transliterated into F#. This is a skill that only takes a day or two to learn.
I would like to use F# but don't because of .NET. I've been impressed with Caml (but not the "O") since I discovered it years ago and was interested in F# as soon as I heard of it. The problem was that I had no interest in developing on Windows, and Mono didn't look appealing either. With the advent of .NET Core, it looked like F# was finally going to be convenient for cross-platform development. I spent a few days downloading various releases and trying to get them working on a few different Windows machines before giving up. I'm not a professional programmer but write code for research. I decided that if I was having that much trouble setting up a working environment before even starting on the substantial effort required to understand the ecosystem, it was unsuitable for sharing work with colleagues or introducing to students. My story may seem irrelevant, since discussion of F# seems to always assume that you are already a .NET developer, but just remember that .NET itself is a major hurdle.
.NET is a big advantage of F#. Like with Scala and JVM, it gives you access to a mainstream ecosystem of libraries. A lack of libraries is usually what makes niche languages unsuitable for production, but F# handily side-steps this. Arguably, F# has a larger ecosystem than C#, since it can also consume JS libraries using Fable!
Mono is no longer required to get started with F#. All you need now is .NET Core.
Mono is no longer required to get started with F#. All you need now is .NET Core.
I use F# on my Macbook Pro via dotnet 5.0 with the VS Code editor and Ionide plugin. It works nice :).
With all of the enhancements to C# over the last decade, is this still relevant in 2021? None of the benefits listed seem that compelling. (Serious question, not trolling.)
Yes. F# has solidified my belief that syntax and the "feel" of a language matter a lot. You might think just a few extra lines of boilerplate or a few keywords in C# are not a big deal, just like Java programmers may think multiple classes per file are just a gimmick, but those things really matter to how I perceive and use a language.
Extra keywords and extra files are annoyances that I try to instinctively minimise. I don't want to say I take the path of "least annoyance", but it's definitely one of the factors that strongly influence how I write code. F#'s lean tagged union type syntax is functionally inferior to Scala 2's case classes, but I use sum types more in F#, because they're less annoying. In C#, I might as well use classes, because I can't declare free functions.
I often hear that Java is good for teams, because it railroads programmers into writing maintainable, pure OOP code. Well, F# railroads you into writing data-driven, mostly functional, multi-paradigm code, and I think the result is much nicer code than what you'd get when trying that in most other languages.
Extra keywords and extra files are annoyances that I try to instinctively minimise. I don't want to say I take the path of "least annoyance", but it's definitely one of the factors that strongly influence how I write code. F#'s lean tagged union type syntax is functionally inferior to Scala 2's case classes, but I use sum types more in F#, because they're less annoying. In C#, I might as well use classes, because I can't declare free functions.
I often hear that Java is good for teams, because it railroads programmers into writing maintainable, pure OOP code. Well, F# railroads you into writing data-driven, mostly functional, multi-paradigm code, and I think the result is much nicer code than what you'd get when trying that in most other languages.
You can have multiple public classes in a file in Java. You just have to wrap them in an outer class, that acts like a module, and declare them “public static”. You can then “import static” the module class in other files, and you can use all these classes simply by name (without having to write OuterC.InnerClass everywhere).
Thanks, but I still can't see it from where I am. The problem isn't that I can't see the use of (to take your example) sum types. I've coded around C#'s lack of them before, and sure, it was clunky and painful. But I've needed them like < 1% of the time.
If I had them as a first-class language feature, would I use them more? What for?
If I had them as a first-class language feature, would I use them more? What for?
I think you would. It's hard to see from the perspective of using another language, because you don't think of the code you write as emulating sum types.
For example, in my biggest F# project I parse a local standard for public transport timetables. In that format a trip can either drive through a stop, drive around it or stop there at a particular time. With a sum type, I can represent all three of these cases without worrying about a value of that type having both "driving through" and a time set. When you've got a language that effortlessly allows something like this, you'll find uses for these paradigms.
For example, in my biggest F# project I parse a local standard for public transport timetables. In that format a trip can either drive through a stop, drive around it or stop there at a particular time. With a sum type, I can represent all three of these cases without worrying about a value of that type having both "driving through" and a time set. When you've got a language that effortlessly allows something like this, you'll find uses for these paradigms.
Okay, that makes sense. I appreciate the concrete example.
You would absolutely use them more, provided that the mechanism for working with them (pattern matching) is also in place. In F# coding you not only model your domain with sum types, but you operate on instances of them with pattern matching that gives you completeness checking. This does two things:
1. Allows you to make failure scenarios intrinsic to your domain, and the compiler then is a tool for domain correctness.
2. It provides a beautiful symmetry between how you define your domain and how you operate on it. The syntax is even almost identical. The features "fit" incredibly well because of that.
Beyond that, with optionals and results defined as sum types you find that any time you're in a "It may explicitly give me nothing" or "It may explicitly give me an error" scenario these types are the first your reach for in your toolbag.
Sum types don't completely obviate classes, but they are a better tool than classes for several scenarios.
1. Allows you to make failure scenarios intrinsic to your domain, and the compiler then is a tool for domain correctness.
2. It provides a beautiful symmetry between how you define your domain and how you operate on it. The syntax is even almost identical. The features "fit" incredibly well because of that.
Beyond that, with optionals and results defined as sum types you find that any time you're in a "It may explicitly give me nothing" or "It may explicitly give me an error" scenario these types are the first your reach for in your toolbag.
Sum types don't completely obviate classes, but they are a better tool than classes for several scenarios.
I think information density per visible page of code in the IDE matters. It relieves you of a lot of mental overhead. By visible density I include mouse-over tooltips. For this reason I don't like code lenses because IMO they waste lines in the visible reagion. When I want to look at a signature I mouse over it.
I think from the syntax, strong typing, and algebraic type signatures F# is the most information dense language I have come across, while still allowing for readability. Maybe something like brainfuck is more information dense.
I think from the syntax, strong typing, and algebraic type signatures F# is the most information dense language I have come across, while still allowing for readability. Maybe something like brainfuck is more information dense.
C# still doesn't have algebraic data types, though I believe they are slated for C# 10. Honestly (hot take) I consider a language to be unfit for purpose if it's incapable of representing dumb data without boilerplate!
Alternative to the main website if it fails to respond: https://archive.is/NkDyg
I just wish we had F# on the JVM that would be a game changer imho
While I think it would increase the popularity of F# for sure I'm not sure that from a performance perspective this would be a good thing. Refied generics (as opposed to type erasure) as an example is leveraged heavily in F# for partial application, and IMO .NET has more room these days to get good performance than the JVM if you put in more effort into it (e.g. Span support, Struct Types with no boxing, full generics support at the JIT level, etc). F# is designed to use these features - the .NET runtime even built some of those features to enable F# (generics) from what I understand.
why a link from 2012 ... is there no new content for F# or did the language not evolve that much ?
There's a substantial amount of new F# content (you can start with official docs for example) but this site in particular is wonderful because it's managed to feel relevant to F# programmers for almost a decade. Fantastic content.
It's more because the website is set up to teach the principles, the reasoning, and the possibilities behind F#, and those are basically timeless.
If you're into domain-driven design, I find F# makes it easier to model your code after your line of business. I also like how F# nudges my code into an "onion-layer" architecture, where the domain of my business logic is at the core and is wrapped around with functionality like reading and validating inputs from external sources.
I also like Elm and the idea of ReasonML, so I plan to seriously check out Fable, which compiles F# to Javascript, and Elmish. There's also Saturn, which is built on top of asp.net-core