aaronmu's comments

Just start. Use whatever style you are used to. Use controllers. Adapt your style as F# pulls you deeper inside the pit of success. You'll struggle the first couple of features, but you'll reach a sweet spot between your current style and functions relatively fast.

I've been using F# professionally for the past seven years across different contexts. First in a small software shop and now while bootstrapping a SaaS company. Some observations:

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

For the small price of 10x slower tooling.

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.

Very interesting project, thanks for linking. Was thinking about building something like Oban.Peer a while ago. We're not using Elixir. Might use Oban as an example :-)

This is all fun and games but how do you catch-up after a disconnect? Why choose this over logical replication?

> F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

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.

What's the difference between an opaque token and a cookie that has a single session identifier in it? 'y know - the way we did it in the 90's.

Implementing pdf.js is a lot of work. $199 for a decent implementation would be a steal.

I've been using a Planck for the past couple of months but after seeing your post I'll have to get a "Let's Tango". Why oh why did I have to see this. I was satisfied.

It's a lot easier to catch a fish in a small pond if you're the only one fishing. Was a lot easier to hire a competent F# developer than it was to hire a competent C# developer.

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.

Learned a bunch, thanks!

I see a lot of snowboarders get into an identity crisis as they get older. Should I still snowboard if I'm not sending jumps and jibs all the time? Yes. Yes you absolutely should.

The truth is that there is just no feeling like laying down a sick carve on a snowboard. Nothing compares.

It runs on Windows, Linux, and macOS.

https://dotnet.microsoft.com/en-us/learn/dotnet/what-is-dotn...

I've been using F#, Giraffe, Fable.React/Feliz, and Fable.Remoting in production for the past four years. Fable enabled us to grow and maintain a stable team of people that work both server- and client-side. You can join our team without any prior javascript experience and we'll have you productive in days.

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

Using F# on Ubuntu for two years, it’s lovely!

The company I work for defaults to F# when choosing tech for a specific project.

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.

The swelling is a battery issue. Myself and two other colleagues experienced the problem and had it fixed.

I totally agree with you! I've used react and redux in almost every project last year, but that doesn't mean the entire web app was written using react and redux. 50 ~80% was plain old static content rendered on the server.

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.

I am well aware of server side rendering but you still need to send all that javascript to the client, whether it ran on the server or not. Wouldn't exactly call this a "little bit of js" on top :p

I'm amazed at how many people use a client side framework, am I the only one who prefers good old server side rendered static html with maybe a little bit of javascript on top?

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