F# is a chimera of a language. The functional parts of the language are nicely designed: no nulls, discriminated unions (ADTs), you write simple functions in simple modules and there is nothing that is too clever to understand: it's very pragmatic. Then there is a whole lot of stuff like inheritance, classes, interfaces, nulls mainly there for dotnet interoperability that gets very ugly very fast. There are way too many variants of the same thing: records, classes, struct records, tuples, struct tuples etc, which are mainly there either for compatibility with similar c# stuff or because the default language constructs often result in suboptimal code. At the end I went with Rust because it has one way of doing such stuff. And for those interested in a gc language with functional features there is now Gleam
banashark · 5m ago
Well there are the 3 you mentioned (records, classes, and tuples) which should be easy enough to differentiate from each other. The struct versions aren't necessary to use in most cases, and are an optimization.
The thoughtful, but not breakneck speed of changes within the language is one thing I appreciate a lot. Things do get added (there are proposals and discussions that are fairly regular in the GitHub repo for language design matters). A recent example is adding a spread operator.
mrbluecoat · 35m ago
When your top reason for a language being mainstream is "interoperability with .NET", I think the argument is a stretch.
banashark · 8m ago
I understand where you're coming from, but I'd challenge your dismissal of that note by noting how seemingly powerful a large ecosystem of available packages is when onboarding people to an ecosystem.
I don't think Scala, Kotlin, or Clojure would have had as much adoption if they hadn't had access to the JVM ecosystem of libraries available.
While it's not the only benefit, I think one could just point at the usage of OCaml as the alternative to F#. While both are in the lower percentages of language popularity/usage, I've worked with at least 50 (dozens lol) people who were paid to write production F#.
jakebasile · 29m ago
Could be! Depends if MS starts putting some more money behind it, including marketing. They're pretty deep in an AI-everything spiral right now though.
I'm a Clojure guy, but the ML family (specifically OCaml and F#) have always interested me as another branch of functional programming. I started out in the before times as a .NET Programmer (VB6 -> VB.NET -> C#) and have toyed with F# a little since then. It's cool, but the tooling leaves a lot to be desired compared to what's available for OCaml unless you decide to use full fat Visual Studio.
What I particularly like about them is the middle ground of inferred types. I don't need types since maps, lists, and value types are enough for me in almost all cases, but if I must use a strongly typed system why not let the compiler figure it out for me? I always thought that was a neat idea.
CrimsonCape · 16m ago
I had a thought today, "when is Microsoft and/or Apple going to earnestly search out their next Steve Jobs?"
And I think the answer is that guys like Bill Gates and Tim Cook are too proud, too prideful to admit they are not kickass rockstars of tech, too jealous to find and cultivate their next super-figurehead. Instead they are safe and lame.
Microsoft needs a non-lame, non-MBA, engineer to take control and inject some younger mindset into making themselves cool again, focused back on tech, UI, user experience, and passion. Engineer tooling would be a great approach.
cjbgkagh · 4m ago
That was supposed to be Scott Guthrie but he got pulled into the Azure whirlpool.
hirvi74 · 6m ago
Oh my, please!
I haven't used F# too terribly much, but as a .Net dev, it's never gotten the love it deserves. I would probably have converted over if there was better third-party library support for the language. (I haven't check in a some years)
Beermotor · 9m ago
I became more proficient in one language than any other. Therefore this language is the best language ever and will take over the universe.
CharlieDigital · 27m ago
I tried F# when we were building out a scraper at a startup. After a bit, I realized that must of the things could also be done in C# and ended up using C# instead because it's just a bit more accessible. F# looks neat, but C# has a lot of parity at this point on some of the core selling points IMO.
mbac32768 · 19m ago
I do not understand how they could develop a language inspired by OCaml but not bring over labeled function arguments. A real L when it comes to ergonomics.
And they just have no plans to ever fix this??
AdieuToLogic · 2m ago
> I do not understand how they could develop a language inspired by OCaml but not bring over labeled function arguments. A real L when it comes to ergonomics.
Is this what you desire?
Named Arguments[0]
Arguments for methods can be specified by position in a
comma-separated argument list, or they can be passed to a
method explicitly by providing the name, followed by an
equal sign and the value to be passed in. If specified by
providing the name, they can appear in a different order
from that used in the declaration.
Not having exceptions doesn't seem like an advantage. My experience with either tough me that some infrastructure error are better as exceptions.
Kotlin handling of nulls is probably the most elegant. And you do not need. Net. When you want 20 pods in kubernetes you probably want some alpine image instead of windows
banashark · 3m ago
As noted in another sibling comment, f# has exceptions and they're a good tool to use.
C# was Microsoft’s response to Java, was F# their response to Scala and Clojure?
swader999 · 4m ago
Clojure is the youngest in that group.
azhenley · 17m ago
It was a Microsoft Research project based on OCaml and adapted for .Net.
moron4hire · 24m ago
It's a research language with legs. Microsoft's explicit strategy with F# is to test functional features they might decide to bring into C#.
sky2224 · 17m ago
IIRC F# was also sort of supposed to be used for their quantum efforts, which later resulted in Q# being spawned.
UncleOxidant · 35m ago
Wishful thinking, me thinks. How good are the AI coding agents at coding F#?
banashark · 18m ago
Comparisons to typescript/node (which I have more ai hours in, but equal experience)
Pros:
* type system is less flexible which simplifies things for the ai
* mostly functional code
* the language hasn’t evolved as much as others because it’s had a strong foundation of features for a while, leading to the corpus containing fairly common themes
Cons:
* smaller corpus
* no reliable hot reloading, which causes annoying iterations of starting a server in the background to test, then forgetting to stop it and hitting errors from starting it again. It does this even when attempting to prompt against it
* Struggles with some breaking changes and interfaces for dotnet things (using old apis, installing old versions of packages)
* file ordering dependency messes with its flow. Usually has to stop to reorder things every once in a while. Can create a mess in the fsproj
Overall my “tier-list” so far has f# below typescript, but above a number of other environments (Kotlin/jvm, Ruby, c#).
Last week I wrote out a 2 page prd for a small service and it got about 95% of the way there (not including tests). If you’re promoting doesn’t have to do with web framework stuff, or you have a repository with existing patterns, it does pretty well.
I gave it a task of “write an inertiajs 2.0 server compatibility library for the oxpecker framework” with a few extra things to create an example test and verify with the playwright mcp. It struggled pretty hard and didn’t end up anywhere close to what I had in my head.
So I’d definitely say that directing it more than vibing would yield a higher chance at success.
electroly · 7m ago
> then forgetting to stop it and hitting errors from starting it again
This one is easy to fix. Give it a script that both kills the old process and starts the new one. Then it can't forget. This is what I do; categorically solved the problem.
ackfoobar · 40s ago
> Give it a script
Ideally the build tool does that for you, e.g. `./gradlew run -t`.
lihaciudaniel · 9m ago
If you do not believe in the python supremacy you are an idiot. C#, F#, M#, G# these are chords not programming languages.
smoothdeveloper · 44m ago
Just a polling of HN hive mind on this critical matter.
Worst case, let the "tried F# once/for real" ramblers unload their bag once more :)
adastra22 · 35m ago
The very first advantage listed is actually a disadvantage for 95% of developers.
“Wedded to the dotnet ecosystem.”
taberiand · 31m ago
Nonsense, .NET is one of the best ecosystems available. Your sentiment is one I tend to hear mostly from people who think it's still .NET Framework and Windows only
CharlieDigital · 21m ago
Indeed. I read a great write up by Sam Cox of Tracebit[0] on his selection of C# and his focus on productivity nails it on the head. One of the best ORMs, rich standard libraries and first party packages, and has been converging with TypeScript and JavaScript over the last decade[1] while having all of the advantages of runtime type safety.
Folks that last looked at C# over a decade ago don't know what they are missing.
Not only. I don't want to use Microsoft technologies unless forced to or no better alternatives (GitHub/ vscode)
moron4hire · 17m ago
If you feel forced to use vscode due to "lack of better alternative" but then stop at using .NET, then you're really missing out on tools that lack better alternatives.
.NET has spoiled me so badly with C#, NuGet, and the debugger that I just don't have the patience for any other languages with their half-assed build systems, janky package managers, and after-thought debuggers.
MSBuild and the dotnet CLI tool may not be fancy, but they work and I generally find "fanciness in the build system" to be a gateway drug to "broken-ass builds that invite new layers of new broken-ass build tools on top".
Every .NET project I've worked on in the last 15 years I could pull from the repo and build-and-run immediately. I can't really say that for almost any other platform.
I was onboarding some Python developers into a C# project at work. I walked them through installing the SDK, cloning the repo, and running the app. One of them piped up,
"That's it?"
"Yeah, that's it. What do you mean?"
"What about virtual environments?"
"Uhh, I'm not sure what you're getting at."
"What if I have multiple versions of the SDK for different projects, how do I keep them from clashing?"
"Oh, yeah, don't worry about that. They all can co-exist side-by-side. Which version a project uses is part of its build settings. Venv just isn't a thing in .NET."
akkad33 · 5m ago
> NET has spoiled me so badly with C#, NuGet, and the debugger that I just don't have the patience for any other languages with their half-assed build systems, janky package managers, and after-thought debuggers.
Rust and cargo are pretty good and only getting better. I don't really see a good use case for anything dotnet when JVM exists
bb88 · 25m ago
Microsoft historically abuses their market position. I think if you're wedding yourself to any MS technology, you need to be able to have a clear divorce strategy.
Maybe true for all companies but especially true for Microsoft (perhaps Google, Apple, etc. as well)
kstrauser · 16m ago
That’s right. I wouldn’t chose a Microsoft tech unless there were a clear, independent path forward when they decide to break it.
binarysneaker · 29m ago
Nope.
sheepscreek · 20m ago
I think, we’re not far from the day when LLMs will be spitting out highly optimized ilasm/byte-code (dotnet intermediate language representation). So your programming language will well and truly be a bunch of prompts. That’s it.
suprjami · 14m ago
I think that's unlikely to get widespread traction.
Source code is not for computers, it is a way for human developers to communicate with each other.
Compilers/interpreters are a consumer of that communication.
Without easy communication of ideas, software does not work. That's why very few people write in raw assembly (hardware or bytecode) and why so many people write in programming languages.
LLMs will not remove the human interchange of ideas. At least not the current generation of generative LLMs.
adzm · 14m ago
What would be the benefit to this versus generating highly optimized c# for example?
lihaciudaniel · 4m ago
The benefit to this is that we talk in tokens, no longer bytes. The Microsoft era where you had to work in bytes is over, now we work with tokens e.g: I build a snake game with 500 tokens, welcome to the future!
The thoughtful, but not breakneck speed of changes within the language is one thing I appreciate a lot. Things do get added (there are proposals and discussions that are fairly regular in the GitHub repo for language design matters). A recent example is adding a spread operator.
I don't think Scala, Kotlin, or Clojure would have had as much adoption if they hadn't had access to the JVM ecosystem of libraries available.
While it's not the only benefit, I think one could just point at the usage of OCaml as the alternative to F#. While both are in the lower percentages of language popularity/usage, I've worked with at least 50 (dozens lol) people who were paid to write production F#.
I'm a Clojure guy, but the ML family (specifically OCaml and F#) have always interested me as another branch of functional programming. I started out in the before times as a .NET Programmer (VB6 -> VB.NET -> C#) and have toyed with F# a little since then. It's cool, but the tooling leaves a lot to be desired compared to what's available for OCaml unless you decide to use full fat Visual Studio.
What I particularly like about them is the middle ground of inferred types. I don't need types since maps, lists, and value types are enough for me in almost all cases, but if I must use a strongly typed system why not let the compiler figure it out for me? I always thought that was a neat idea.
And I think the answer is that guys like Bill Gates and Tim Cook are too proud, too prideful to admit they are not kickass rockstars of tech, too jealous to find and cultivate their next super-figurehead. Instead they are safe and lame.
Microsoft needs a non-lame, non-MBA, engineer to take control and inject some younger mindset into making themselves cool again, focused back on tech, UI, user experience, and passion. Engineer tooling would be a great approach.
I haven't used F# too terribly much, but as a .Net dev, it's never gotten the love it deserves. I would probably have converted over if there was better third-party library support for the language. (I haven't check in a some years)
And they just have no plans to ever fix this??
Is this what you desire?
0 - https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...Kotlin handling of nulls is probably the most elegant. And you do not need. Net. When you want 20 pods in kubernetes you probably want some alpine image instead of windows
Some folks opt to go full "railroad-oriented programming" mode, but using both has more benefits. Here is a good article on it: https://medium.com/@lanayx/practical-error-handling-in-f-c3c...
https://learn.microsoft.com/en-us/dotnet/core/install/linux-...
Welcome to 2025.
Pros:
* type system is less flexible which simplifies things for the ai
* mostly functional code
* the language hasn’t evolved as much as others because it’s had a strong foundation of features for a while, leading to the corpus containing fairly common themes
Cons:
* smaller corpus
* no reliable hot reloading, which causes annoying iterations of starting a server in the background to test, then forgetting to stop it and hitting errors from starting it again. It does this even when attempting to prompt against it
* Struggles with some breaking changes and interfaces for dotnet things (using old apis, installing old versions of packages)
* file ordering dependency messes with its flow. Usually has to stop to reorder things every once in a while. Can create a mess in the fsproj
Overall my “tier-list” so far has f# below typescript, but above a number of other environments (Kotlin/jvm, Ruby, c#).
Last week I wrote out a 2 page prd for a small service and it got about 95% of the way there (not including tests). If you’re promoting doesn’t have to do with web framework stuff, or you have a repository with existing patterns, it does pretty well.
I gave it a task of “write an inertiajs 2.0 server compatibility library for the oxpecker framework” with a few extra things to create an example test and verify with the playwright mcp. It struggled pretty hard and didn’t end up anywhere close to what I had in my head.
So I’d definitely say that directing it more than vibing would yield a higher chance at success.
This one is easy to fix. Give it a script that both kills the old process and starts the new one. Then it can't forget. This is what I do; categorically solved the problem.
Ideally the build tool does that for you, e.g. `./gradlew run -t`.
Worst case, let the "tried F# once/for real" ramblers unload their bag once more :)
“Wedded to the dotnet ecosystem.”
Folks that last looked at C# over a decade ago don't know what they are missing.
[0] https://tracebit.com/blog/why-tracebit-is-written-in-c-sharp
[1] https://typescript-is-like-csharp.chrlschn.dev/
.NET has spoiled me so badly with C#, NuGet, and the debugger that I just don't have the patience for any other languages with their half-assed build systems, janky package managers, and after-thought debuggers.
MSBuild and the dotnet CLI tool may not be fancy, but they work and I generally find "fanciness in the build system" to be a gateway drug to "broken-ass builds that invite new layers of new broken-ass build tools on top".
Every .NET project I've worked on in the last 15 years I could pull from the repo and build-and-run immediately. I can't really say that for almost any other platform.
I was onboarding some Python developers into a C# project at work. I walked them through installing the SDK, cloning the repo, and running the app. One of them piped up,
"That's it?"
"Yeah, that's it. What do you mean?"
"What about virtual environments?"
"Uhh, I'm not sure what you're getting at."
"What if I have multiple versions of the SDK for different projects, how do I keep them from clashing?"
"Oh, yeah, don't worry about that. They all can co-exist side-by-side. Which version a project uses is part of its build settings. Venv just isn't a thing in .NET."
Rust and cargo are pretty good and only getting better. I don't really see a good use case for anything dotnet when JVM exists
Maybe true for all companies but especially true for Microsoft (perhaps Google, Apple, etc. as well)
Source code is not for computers, it is a way for human developers to communicate with each other.
Compilers/interpreters are a consumer of that communication.
Without easy communication of ideas, software does not work. That's why very few people write in raw assembly (hardware or bytecode) and why so many people write in programming languages.
LLMs will not remove the human interchange of ideas. At least not the current generation of generative LLMs.