Top
Best
New

Posted by bozhidar 4/1/2025

Why F#?(batsov.com)
447 points | 413 commentspage 3
BenGosub 4/1/2025|
Two nice things about F# are that you can introduce it into an organisation using the dotnet ecosystem and that you can use all libraries in dotnet, which is a huge advantage over OCaml.

Otherwise, I am happy with OCaml, but F# has also a place in this world.

UlisesAC4 4/2/2025|
You can use adapters via Foreign Function Interface and interact with C++ code. The deal breaker is that memory is separated, C++ code has its own heap and Ocaml too. Quiet different to F# in which operating with C# is seamless and the runtime is the same.
DeathArrow 4/2/2025||
You can call C++ code from F#, too.
aaronmu 4/1/2025||
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.

nickpeterson 4/1/2025||
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.
GiorgioG 4/1/2025||
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.
JohnyTex 4/1/2025|||
The situation is a bit more complex in F# than C#, as there are multiple ways to do it. Scott Wlaschin has a good overview post about it here:

https://fsharpforfunandprofit.com/posts/dependencies/

FWIW you can do it exactly the same way you do it in C#; it’s not “wrong”, it might just feel a bit out of place.

Lanayx 4/2/2025||||
I wrote an article about it. https://medium.com/@lanayx/dependency-injection-in-f-the-mis...
aaronmu 4/2/2025|||
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.
GiorgioG 4/3/2025||
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!
tubthumper8 4/4/2025||
"pit of success" from the previous comment might refer to this video, which is long but good especially to adjust to a different mindset

https://youtu.be/US8QG9I1XW0?si=N07ZsYSYfA12mGVc

justanotheratom 4/1/2025||
F# was my favorite language, but - You have to chose the language of the Domain that you are working in, e.g, Swift for native iOS Development. Supabase Backend requires TypeScript, etc. - LLMs don't care about F#.
systems 4/1/2025||
The problem with F#, Clojure and Elixir (hosted languages)

For F# , you need some basic C# knowledge For Clojure, you need some basic Java knowledge For Elixir, you need some basic Erlang knowledge

I like all 3 languages but usually each vm have a primary language, and each hosted language eventually become hosted on that primary language not the vm

I understand that for many task simple, to medium complexity, you might not need that, but it seem as you try to be more advanced you hit the wall of having to learn you host vm primary language

skrebbel 4/1/2025||
> For Elixir, you need some basic Erlang knowledge

As an Elixir programmer, this does not resonate. Basically the only thing I've ever felt I needed to understand Erlang for was ets, but let's be honest, that's not really proper Erlang but just the terrible ets query syntax. And all this requires is "ability to read enough erlang term syntax to be able to understand the ets manual". I don't think I could write a single line of correct Erlang by heart.

I feel like that's different in F#, where you still need to know lots of .NET internals which are all documented in C#y terms with C# examples etc. Elixir wraps pretty much all good Erlang/OTP internals in nice Elixiry modules, which solves that quite nicely.

Elixir has its warts but this really isn't one of them.

graemep 4/1/2025||
Thanks. I know a bit of Erlang (put some effort into learning, but never used it in real life, probably forgotten what I learned) and want to learn Elixir which seems better suited to what I want to do in the short to medium term.
graemep 4/1/2025|||
Erlang is not a difficult language. Unusual, but actually quite sane syntax. If you are already familiar with Elixir it would probably be pretty easy to learn the basics of Erlang.
LandR 4/2/2025|||
I've written a lot of Clojure now, and I've managed to avoided learning any Java really.
chamomeal 4/2/2025||
That’s a reassuring thing to hear as a new clojure learner who has little interest in java.

What bits of java have you ended up needing? Like do you often use java libraries that don’t have clojure wrappers?

I feel like I’m often running up against little things. I’ll google “how to do xyz in clojure” and the top SO answer is to use a java library that apparently everybody already knows about, cause so many clojurists came from java first!

iLemming 4/2/2025||
> What bits of java have you ended up needing?

The same with Clojurescript and JS (and probably with Clojure-Dart) - you have nice interop with the hosting platform. The need for learning anything about Java (while writing Clojure) basically boils down to finding API documentation for a specific class and simply using it. That's all. That's all you'd ever need.

iLemming 4/2/2025|||
> For F# , you need some basic C# knowledge For Clojure, you need some basic Java knowledge For Elixir, you need some basic Erlang

Honestly, none of this really rings a bell. Having used all three options, I never felt that. Well, I already knew C# before getting into F#, but honestly, it felt like my C# knowledge at the time was more of a distraction. Been using Clojure for nine years, never done any serious Java and have not felt any need for it. Not knowing Erlang wasn't a problem with Elixir, like at all.

innocentoldguy 4/1/2025||
I worked with Elixir for over five years without knowing anything about Erlang. I know Erlang now, but only because I was interested in learning it, not because I needed to do so to write Elixir code.
lysecret 4/1/2025||
I worked a lot in F# and loved it. I love that it has a lot of great functional ideas without being too pedantic about being 100% functional all the time. (You can have mutating state or just call arbitrary C#.) I took a lot of its insights into my daily python code too. I especially love match.
mrkeen 4/1/2025|
There's no need to be functional 100% of the time, and it's not pedantry.

You mark your functions and non-functions as such, so the compiler can get your back.

Aldipower 4/1/2025||
"Why the F#?" perhaps would be a better title. :-)
phplovesong 4/1/2025||
Last time i tried F# i got bit by the weird concurrency story. There was async/task and somwhow they did not play well together. Also the dev tooling (for vim) was subpar, compared to ocaml (lsp). Compile times also was on the slower side.
neonsunset 4/1/2025||
If you use task { } CE's you will get really good UX (it is recommended to use them over async CE's). They were introduced in F# 6.0 to address outstanding interoperability issues. As of now, writing asynchronous code is more convenient than C# (which is more convenient than Go or other languages which are less expressive w.r.t. writing highly concurrent code).
110bpm 4/1/2025||
`async` is F#'s original implementation of async programming. It is the precursor to C#'s await/async.

`task` targets the .NET TPL instead, which is also what C#'s await/async and all of .NET *Async methods use.

While the `async` implementation still offers some benefits over `task` (cold vs. hot starts [0]), my advice is - if you're doing backend code on .NET, you should use task. The tigher integration with the .NET ecosystem & runtime results in better exception stack traces, easier debugging and faster performance.

[0] https://github.com/TheAngryByrd/IcedTasks?tab=readme-ov-file...

FrustratedMonky 4/1/2025||
F# on front page? And popular?

ahhh, Its April Fools?

JK, I love F#. Please get over the hump and be a big language.

DeathArrow 4/2/2025||
Iove the ideas behind functional programming but I never properly learned a functional programming language. I will probably never have the opportunity to use it professionaly and learning it just for hobby doesn't make sense to me.

If I am developing something in my spare time I also like to use something I can earn money with so I can hone and maintain my earning skills. Maybe sounds like min maxing.

If I would be in a situation where I can develop software just out of pleasure or pure curiosity, I would use just whatever language I deem interesting.

rawoke083600 4/2/2025|
I'm waiting for the excellent F# Article about railroad-coding to be posted here. Required F#e reading :) No not trolling. Am on mobile and traveling else I would have searched-posted
smcl 4/2/2025|
I assume you're talking about Scott Wlaschin's "Railway Oriented Programming": https://fsharpforfunandprofit.com/rop/
More comments...