aaronmu

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.

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.

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!