Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why F#?

batsov.com

Post reply on HN
Print view View original

81–90 of 424 posts

Re: Why F#?

#81

Post by Akronymus »

GiorgioG wrote: post #47

As a 20+ year C# developer I’ve tried several times to learn/use F#. Despite being interested in FP, my brain is having trouble figuring out how to structure my code in F#. In C# I’d either build a service (or use the mediator pattern) for the domain and a repository for data access. With F# it’s functions all the way down and it feels unnatural (as silly as that may sound).

along with what jcmontx said: F# is structured bottom from top. As in you can't reference something that is later defined earlier. I find that naturally leads to getting a decent enough structure "for free" because it forces you to have your basic functionality early on and build on that later.

That also, IMO, makes untangling/splitting up parts of the codebase easier as well.

Re: Why F#?

#82

Post by nudpiedo »

Same as many, I had wonderful experience with F# in the past, I would use it again if:

- fable would 100% detach from dotnet - keeps up yo the LLM rush, specially vibe coding on cursor

Last LLM experience it generated obsolete grammar (not much but a bit).

Such la gauges are key for vibe coding experience and modeling.

Re: Why F#?

#83

Post by 8s2ngy »

rockyj wrote: post #29

I did try F#, but I was new to .NET ecosystem. For 1 "hello world" I was quite surprised by how many project files and boilerplate was generated by .NET, which put me off. I am all for FP, immutable, and modern languages. But then where are the jobs and which companies care if you write good code? Now everyone wants languages which are easy to use with AI, while reducing workforce and "increased productivity". I have…

I understand your perspective. I like to view niche languages as a medium for learning. For instance, I enjoy using Rust in my personal projects—even if many of these projects may never be released—because the lessons on immutability, functional programming constructs, and trait-oriented programming significantly enhance my day-to-day work. Therefore, I believe that learning niche languages, even in the absence of a robust job market, is worthwhile.

Re: Why F#?

#84

Post by sodapopcan »

rockyj wrote: post #29

I did try F#, but I was new to .NET ecosystem. For 1 "hello world" I was quite surprised by how many project files and boilerplate was generated by .NET, which put me off. I am all for FP, immutable, and modern languages. But then where are the jobs and which companies care if you write good code? Now everyone wants languages which are easy to use with AI, while reducing workforce and "increased productivity". I have…

> But then where are the jobs and which companies care if you write good code?

Oh man, that is poignant :( They always say they do in the job description, but it always a different story once you get there.

Re: Why F#?

#85

Post by aaronmu »

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.

Re: Why F#?

#86

Post by marcosdumay »

twodave wrote: post #59

In the case of F#, the use cases are diminishing with every new C# release, since C# is getting better and better at the things F# is supposed to be strong at (record types, pattern-matching, etc.). Better to write the thing in C# using modern features of the more popular and capable language.

You may start to get a point when C# gets a two-directional type inference system. As it's now, any functional-looking code requires so much boiler plate that it's shorter and less bug-prone to copy your functions code everywhere you want to use them.

Re: Why F#?

#87

Post by UK-Al05 »

bob1029 wrote: post #43
pjc50 wrote: post #22

Earlier quoted context omitted.

The funny thing is that you can write very similar code in C#, so maybe you don't need to switch which language you're using as a CLR frontend. using System.Linq; using System; var names = new string[] {"Peter", "Julia", "Xi" }; names.Select(name => $"Hello, {name}").ToList().ForEach(greeting => Console.WriteLine($"{greeting}! Enjoy your C#")); LINQ is such a good library that I miss it in other languages. The Java s…

You can write a vast majority of your C# codebase in a functional style if you prefer to. All the good stuff has been pirated from F# land by now: First-class functions, pattern matching, expression-bodied members, async functional composition, records, immutable collections, optional types, etc.

A language is just as much about what it can't do, then what it can do.

Re: Why F#?

#88

Post by skrebbel »

systems wrote: post #73

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 mi…

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

Re: Why F#?

#89

Post by Akronymus »

speed_spread wrote: post #75
munchler wrote: post #20

Earlier quoted context omitted.

F# is up to version 9 now, and has only improved over time, IMHO. Type providers are a very small part of the story and can be avoided entirely if you want.

Why would type providers be avoided? It seemed to me like a nice metaprogramming feature, akin to what Zig does with comptime types (except runtime?)

Type providers can be extremely brittle IME. Altough, I guess if it is referring to version controlled example data that probably works better than referring to a DB or something like that directly that the dev has to provide.

Re: Why F#?

#90

Post by klysm »

pjc50 wrote: post #22
eknkc wrote: post #3

As far as I can tell F# is one of those things where every single user is extremely happy. This happens rarely and I really am curious about the thing but never had time to get into it. I'm also pretty well versed in the .net ecosystem so it's probably gonna be easy. Any tips? What kind of workflows might benefit the most if I were to incorporate it (to learn..)?

The funny thing is that you can write very similar code in C#, so maybe you don't need to switch which language you're using as a CLR frontend. using System.Linq; using System; var names = new string[] {"Peter", "Julia", "Xi" }; names.Select(name => $"Hello, {name}").ToList().ForEach(greeting => Console.WriteLine($"{greeting}! Enjoy your C#")); LINQ is such a good library that I miss it in other languages. The Java s…

This isn’t a great example of what linq is good at. There’s no reason to do ToList there, and the ForEach isn’t particularly idiomatic
Post reply on HN