115 karma · joined January 27, 2015
* It’s easier to attract smart developers to an F# project than to a [mainstream language] project. This was one of my driving beliefs when I introduced F# seven years ago. https://www.paulgraham.com/pypar.html. This is probably just as true for languages like Elixir, Clojure, ... But F# is what we went with.
Small Software Shop Context
* We operated in a small market where customers eventually dictated our tech stack (.NET & React). In that market, F# was a major advantage—it allowed junior developers to build apps that "just worked" with minimal regressions. Even with mediocre code quality, I felt confident that we could refactor safely at any time.
* I constantly had to justify F# to clients, which was exhausting. We always delivered decent results, so it worked out, but my partners were never as confident in defending F#.
Bootstrapping a SaaS Company
* F# has been invaluable for shipping features quickly and taking shortcuts when needed.
* Three years in, our codebase is large and contains its fair share of messy parts. But we can still develop new features at high speed with minimal regressions. Refactoring is relatively safe and straightforward.
* Compilation speed is the Achilles’ heel. If you don’t monitor it, the compiler slows down to the point where it impacts productivity. Earlier this year, waiting over a minute for feedback after a small change became unbearable. A lot of our "clean-up" work focuses on optimizing compilation times. We're still learning, but we’re optimistic that we can restructure the project to significantly improve build performance.
EDIT: maybe one more point. I see a lot of C# vs F# popping up here. Yes, C# has all the features that F# has. But do not underestimate how well designed F# is. It is an extremely simple language to learn compared to C#. There is a very limited amount of keywords to learn. And they compose extremely well. If you learned F# 7 years ago, took a break, and came back today, you'd simply write the same boring code that you would have written 7 years ago. And along the way you'd find out that some things have gotten a bit nicer over time.
I’ve been using F# full-time for 6 years now. And compiler/tooling gets painfully slow fast.
Still wouldn’t trade it for anything else though.
C# will always be more popular because it easier to learn. Why? Because it looks familiar to most developers. Why would you learn this unfamiliar thing called F# if C# is right there and you basically already know it? On top of that, C# almost has feature parity with F#.
However, F# is a simpler language than C#. That is a fact. It has less concepts that you need to learn. I've found that onboarding someone in an F# codebase takes a lot less time compared to onboarding someone in a typescript,C#,... codebase. A lot less time. I've found that new people can start contributing after a single introduction. The things they build often just work.
I think that an F# code base costs a lot less money to maintain over longer periods of time. Can't prove it but I think that the difference is huge.
No one ever got fired for buying IBM. Technology that is unknown to the buyer is significantly harder to sell. You will lose sales because of your exotic technology choice. If you told me this 4 years ago, I'd have argued that the implementation details don't matter but it turns out that they do.
The truth is that there is just no feeling like laying down a sick carve on a snowboard. Nothing compares.
https://dotnet.microsoft.com/en-us/learn/dotnet/what-is-dotn...
It does not and cannot take away the complexity of writing an SPA in React. If you want to write a high quality SPA in React using Fable, you'll still need React, webpack, ... expertise in the team.
I know that in theory we all write perfect apps and have test suites with 100% coverage that do not hinder us as we change the codebase. Reality is much different though. You are behind on a deadline, your spouse and kids are home with COVID, and the junior has made 20 changes that should've been in prod last week but aren't because you haven't had the chance to review them. This is where F# shines. Merge the shit code to prod (after maybe some manual testing :P). You will be able to refactor it later with relatively high confidence.
The interest on technical debt in F# is so much lower compared to any other language I've used in prod (C#, Typescript, Javascript, and PHP).
We defaulted to PHP and C# in the past.
We have quite some experience training people who just graduated and even people with backgrounds outside of tech.
Training someone from zero to autonomously writing production code is a lot easier in F# compared to PHP and C#.
We educate people in Elm and Haskell and switch over to F# when they’re ready to try building the first real thing end to end.
A dynamic client side UI is more expensive to build compared to static html rendered on the server. Our software usually aims to solve a business problem for as little money as possible so we only build these dynamic ui's when they're absolutely required.
When I need a more dynamic page, I create a react app specifically for this one page.
Whenever I need to write JS these days, I go for either TypeScript or F# using Fable (an F# to javascript compiler).
TLDR: orm’s + large transactions resulted in a lot of unexpected complexity.
At some point you get really big transactions because one write triggers five process managers which all trigger more writes and so on and so on. Performance was not a problem but I was surprised by the complexity of these big transactions in combination with an orm.
I dont have a concrete example but over the course of two years we have encountered multiple bugs that took days to solve. Theres one of these bugs that we fixed without identifying the root cause until this day.
Humans think that we can tell cause from effect but this is rarely the case.
JavaScript Allongé, the "Six" Edition by Reginald Braithwaite
Are Your Lights On? by Gerald M. Weinberg