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.
I’ll add that features isn’t really a constructive way to think about the differences between C# and F#. C# has more ‘features’ than most other programming languages. One of the core features of F# is less features and churn. Also, I really appreciate the way F# maintainers agonize over how to maintain the language and keep it coherent. You don’t get the feel they’re chasing features at all.
As a 20+ year C# dev...where do I learn how to structure apps in F#? In C# my ASP.NET Controller might use a service (or a mediator) to execute some domain logic and that in turn will use a repository pattern (or EF DbContext) to update/query a database. How are dependencies injected in? It seems like there are multiple ways of going about it, but I don't have enough knowledge of F# to know 'the proper way' to do it.
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 suspect you're right. I just have to get over the hump of being uncomfortable/fumbling my way through things that I would otherwise know how to do in C#. Thanks!
An approach I moved from this to, was to use the DB trigger to write jobs directly to an Oban oban_jobs table.
Oban jobs run almost instantly when they are queued so there's no perceptible difference in speed, but you get all the benefits of resilience that Oban provides, so your webapp connection can go down, such as during a deploy, and still catch up reliably.
It's also handy to be able use the oban_jobs table for debugging purposes.
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 :-)
> 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.
As sibling comments point out, an opaque token can be stored elsewhere (though, to be fair, the session identifier which is in that cookie can be placed elsewhere too).
The cookies is mainly used to identity the user (e.g. his session and prior authentication), while the tokens are used to forward something to proof that the an application wants to access one or multiple apis.
So if you need the client to pass on sensitive (authentication/authorization) information to another party without that party having access to the original provider of that data (except its public key, I suppose). Then JWT is a usable format, with a lot of support.
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.
I am sorry. :D
If you like the layout and want to "dip" your feet in, go with a "let's split" first. That's what the tango is based on, but minus the milled case. I used this for a good 18 months until I recently decided to upgrade, realizing that despite my efforts to improve on it, this minimal layout was what stuck with me. I wrote a bit about it here, also made some potato pictures:
This is an amusing response given the parent's comment. You're perfectly happy with what you have, so what's the reason why you're interested in switching now after reading about a different keyboard?
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.
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.
As I got older I switched my focus to riding switch. While I'm not as solid riding switch I can keep up and often pass most I ride with.
Along with building up my switch skills I worked on frontside and backside 180s. Basically being able to flip from one to the other and back. Sometimes I forget which is my natural stance and which it switch.
I was progressing up to 360s from either stance but haven't been out enough the that couple of years.
I'm in my 50s. I do most of my riding in Vermont (mostly Killington) so my skills are almost legit ;)
Thank you, your comment back brought warm memories for me! I grew up in the Canadian rockies, but my family moved to Ontario in my teens. The skiing was terrible there so I switched to snowboarding to keep it interesting. But, we used to come down to Killington in the winter to get some real mountain time in. Thankfully I'm in California now so I've got some good mountains nearby. Thanks again and I hope Killington is still as great, or maybe even better, than it once was.
100%! Just got back from a week in the Zillertal and it was incredible and all I can think of is how to go back. Finally did it on my own gear this time too, what a massive difference a good board, binding, boot combo makes. I'm a late convert, so not a park rat at all, but just hitting reds all day (Europe, so just Blue, Red, Black grades) along with the mountain culture makes for my absolute favourite holidays.
* 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.