Why F# could be the next mainstream programming language (2024)(blog.snork.dev)
blog.snork.dev
Why F# could be the next mainstream programming language (2024)
https://blog.snork.dev/posts/why-f--could-be-the-next-mainstream-programming-language-.html
98 comments
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
C# will eventually have unions that will undoubtedly be incompatible too, I worry about source generators becoming ubiquitous as well.
This was also my experience with F#, phenomenal language dragged down by ugly interop with an ecosystem that barely acknowledges its existence and I feel is incompatible with its ideals.
Shame too because there’s some genuinely great stuff in the community like fable [1] where if you were to chuck in JSX like templating you’d have an absolute killer web tool rather than the mess blazor is.
It’s ironic that I found js interop less annoying than .net interop.
[1] https://github.com/fable-compiler/Fable
This was also my experience with F#, phenomenal language dragged down by ugly interop with an ecosystem that barely acknowledges its existence and I feel is incompatible with its ideals.
Shame too because there’s some genuinely great stuff in the community like fable [1] where if you were to chuck in JSX like templating you’d have an absolute killer web tool rather than the mess blazor is.
It’s ironic that I found js interop less annoying than .net interop.
[1] https://github.com/fable-compiler/Fable
> There are way too many variants of the same thing: records, classes, struct records, tuples, struct tuples etc, [...]
> At the end I went with Rust because it has one way of doing such stuff.
I haven't looked at C# in 20 years, but Rust certainly has a LOT of ways to do similar things too:
Anyways, I haven't used Rust in a few years now either, and I'm sure I've made some mistakes and omissions above, but I don't remember it as the poster child for Python's "There should be one-- and preferably only one --obvious way to do it".
> At the end I went with Rust because it has one way of doing such stuff.
I haven't looked at C# in 20 years, but Rust certainly has a LOT of ways to do similar things too:
struct Foo { x: f64, y: f64 } // Struct
struct Foo(f64, f64) // Tuple Struct
let f = (1.0, 2.0) // Tuple
enum U { Foo(f64, f64) } // Enum Tuple
enum V { Foo { x: f64, y: f64 } } // Enum Struct
[ 1.0, 2.0 ] // Size-2 Array
&[ 1.0, 2.0 ] // Slice
vec![1.0, 2.0] // Vec
Anyways, I haven't used Rust in a few years now either, and I'm sure I've made some mistakes and omissions above, but I don't remember it as the poster child for Python's "There should be one-- and preferably only one --obvious way to do it".
> struct Foo { x: f64, y: f64 } // Struct
struct Foo(f64, f64) // Tuple Struct
let f = (1.0, 2.0) // Tuple
enum U { Foo(f64, f64) } // Enum Tuple
enum V { Foo { x: f64, y: f64 } } // Enum Struct
[ 1.0, 2.0 ] // Size-2 Array
&[ 1.0, 2.0 ] // Slice
vec![1.0, 2.0] // Vec
I don't know, I'm not too bothered by this. If you take struct tuple and struct, Yes synctacticqlly they are different but functionally they are quite similar. You have values lying in memory. There's no reason to prefer one to the other except convenience. Program behaviour will not change. This is not the the case for fsharp classes and records and structs. Same way Fsharp has two types of lists. It also has an array type and all these are different but they look the same. In rust case they all have different names but behaviour wise they are same: data stored in contiguous memory with some differences in what you can do with them. I do like fsharp as a language but it can't go full on its promises because of dotnet. One glaring one is nulls. The language itself claims to be null safe. Except if you use dotnet types like strings. Then the compiler doesn't warn you. Honestly Kotlin does this better with non nullable types and null chaining
I don't know, I'm not too bothered by this. If you take struct tuple and struct, Yes synctacticqlly they are different but functionally they are quite similar. You have values lying in memory. There's no reason to prefer one to the other except convenience. Program behaviour will not change. This is not the the case for fsharp classes and records and structs. Same way Fsharp has two types of lists. It also has an array type and all these are different but they look the same. In rust case they all have different names but behaviour wise they are same: data stored in contiguous memory with some differences in what you can do with them. I do like fsharp as a language but it can't go full on its promises because of dotnet. One glaring one is nulls. The language itself claims to be null safe. Except if you use dotnet types like strings. Then the compiler doesn't warn you. Honestly Kotlin does this better with non nullable types and null chaining
Yeah, having the multiple "record" types in Rust doesn't bother me either. I just disagreed that the situation is clearly simpler than it is in F#.
If you think of using C# libraries from F# as comparable to using other people's crates in Rust, you're going to get exposed to other people's choices for data structures in both.
If you think of using C# libraries from F# as comparable to using other people's crates in Rust, you're going to get exposed to other people's choices for data structures in both.
It’s not so much that you’ve made any mistakes or omissions as much as all of these things do different, similar things, but don’t do the exact same thing.
For example, an array and a tuple are both aggregate types, but arrays store multiple value of a single type, and tuples store multiple values of the same type.
Some of these do boil down to “named or anonymous” but that’s also two different things.
For example, an array and a tuple are both aggregate types, but arrays store multiple value of a single type, and tuples store multiple values of the same type.
Some of these do boil down to “named or anonymous” but that’s also two different things.
More power to you for defending or explaining Rust, but the context of the conversation is comparing multiple "record" types in C# as "bad" to the "one way" in Rust. It's hard to argue that Rust has a simpler story than C#.
There are a lot of almost orthogonal features one might choose for a record type:
Accessor: rec.x, rec.0, rec[0], match
Constant vs Mutable
Reference vs Value
Nominal vs Structural/Anonymous typing
Subtyping for inheritance
Subtyping for sum/union types
And more depending on the language (ownership in Rust)
> tuples store multiple values of the same type.
I'm sure this was a typo. :-)
There are a lot of almost orthogonal features one might choose for a record type:
Accessor: rec.x, rec.0, rec[0], match
Constant vs Mutable
Reference vs Value
Nominal vs Structural/Anonymous typing
Subtyping for inheritance
Subtyping for sum/union types
And more depending on the language (ownership in Rust)
> tuples store multiple values of the same type.
I'm sure this was a typo. :-)
It was a typo, thanks :)
I’m not trying to pass judgement on C#. I just don’t see a lot of these things as being that similar to each other.
I’m not trying to pass judgement on C#. I just don’t see a lot of these things as being that similar to each other.
Heh, I just remembered that Rust has like 6 or 7 ways to do strings too.
Rust has one string type in the language, and three more in the standard library. This boils down to the intersection of “owned vs borrowed” and “Rust native strings vs C native strings,” and you only need the C variants when doing FFI.
I'm (basically) aware of the details (String, &str, OsString, OsStr, CString, CStr, "star" c_char, and probably some others ("star" const i8, &[u8], ???), and you and I have had this conversation a while back when I had a stronger interest in Rust. I'm not sure if you're correcting me, but you're basically confirming what I said.
As for only needing them when you need them, how could it be otherwise? :-)
As for only needing them when you need them, how could it be otherwise? :-)
One thing I would say is if you're writing a normal Rust application or library and do not care about c interoperability, you could get by without being aware of anything other than the first 2 types. However in Fsharp you are forced to learn about all other ways of doing things, plus how C# does things, because it is almost impossible to do anything useful without interoperating with C# and dotnet
I think any new user would stumble on Path, OsString, and OsStr pretty quickly when working with files and directories. Rust tried really hard to avoid string related errors at runtime by not allowing strings to have invalid data. It's a defensible goal, and the cost is having multiple string types. And then they've got another doubling of types because of their ownership model.
It's not the choice I would make, but my opinion doesn't really matter. Real world strings (UTF-8, WTF-8, UCS-16, arbitrary bytes) don't follow the rules 100% of the time, so you're always going to end up dealing with that complexity at runtime in one place or another. I think you might as well have one simple string type and accept that. This is what Go chose (not that I'm a regular Go user either).
It's not the choice I would make, but my opinion doesn't really matter. Real world strings (UTF-8, WTF-8, UCS-16, arbitrary bytes) don't follow the rules 100% of the time, so you're always going to end up dealing with that complexity at runtime in one place or another. I think you might as well have one simple string type and accept that. This is what Go chose (not that I'm a regular Go user either).
Yes, this is what I was trying to say. Saying “six or seven types” makes it sound far more complex than it actually is.
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.
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.
Yeah those examples I gave are not the best. But why records and classes when records can also have methods. What I was getting at was the language looks good until you dive deeper and get into all those rough edges of dotnet interoperability. An example I can think of is functions/methods. I think F# style is to write curried functions (no brackets for function inputs), except class methods are written mostly non curried. Computation expressions are non curried also even though that is an F# only features. Then there are two ways of writing generics: C# reified generics and rust like monomorphised generics (with inline keyword) and they used to have two different syntaxes until recently
Yeah typically if you're exposing F# code out to C# as a library, you'd want to keep the external API utilizing features that have better interoperability (classes), whereas code that's written in F# and only expected to be called by F# can use things like currying and such.
In practice, this ends up being mostly simple to deal with.
In the other direction, consuming C# libraries historically hasn't had too much trouble other than they don't really design them with any functional-leaning in mind. The real problem that's growing recently is the dotnet teams move towards C#-centric features. Things like source-generators, roslyn, etc that are "C# features" and not "dotnet features". These types of things could create a big enough rift to break practical usage of F# as a dotnet interoping language if it goes unchecked.
In practice, this ends up being mostly simple to deal with.
In the other direction, consuming C# libraries historically hasn't had too much trouble other than they don't really design them with any functional-leaning in mind. The real problem that's growing recently is the dotnet teams move towards C#-centric features. Things like source-generators, roslyn, etc that are "C# features" and not "dotnet features". These types of things could create a big enough rift to break practical usage of F# as a dotnet interoping language if it goes unchecked.
> But why records and classes when records can also have methods.
Records have built in equality logic, Classes don't.
And, because of the interop story, they wanted to be able to define classes.
> C# reified generics and rust like monomorphised generics (with inline keyword) and they used to have two different syntaxes until recently
I almost prefer the old way, where SRTPs required the other syntax. On the other hand I guess between 'inline' and constraints the compiler makes the 'best choice' now...
Also, just minor pedantic comment, both C# and F# will monomorphize for struct of T
Records have built in equality logic, Classes don't.
And, because of the interop story, they wanted to be able to define classes.
> C# reified generics and rust like monomorphised generics (with inline keyword) and they used to have two different syntaxes until recently
I almost prefer the old way, where SRTPs required the other syntax. On the other hand I guess between 'inline' and constraints the compiler makes the 'best choice' now...
Also, just minor pedantic comment, both C# and F# will monomorphize for struct of T
> Records have built in equality logic, Classes don't.
I'm aware of this but i feel this is confusing. Just putting () changes semantics a whole lot
> Also, just minor pedantic comment, both C# and F# will monomorphize for struct of T
I wasn't aware thanks
I'm aware of this but i feel this is confusing. Just putting () changes semantics a whole lot
> Also, just minor pedantic comment, both C# and F# will monomorphize for struct of T
I wasn't aware thanks
You can choose which constructs you use. Avoiding classes in F#, while possible, would be a mistake as they are a way to hide data and functions where these are not intended to be part of the public API. F# is outstandingly pragmatic and the struct types for performance have been a nice addition. As a beginner you can ignore those if you are not interested in getting max perf.
Dotnet does have some minor annoyances (exceptions being one) but gives the ability to deploy everywhere, GUI apps on all platforms, web, backend is fantastic. Lack of native GUI apps would be the main deficiency for me from Gleam, plus the fact that they have decided their community is explicitly politically woke-liberal.
Rust has been a fantastic addition to the language ecosystem, but recursive types, which are the bread and butter of ML-family code, are just too hard to write in Rust.
Dotnet does have some minor annoyances (exceptions being one) but gives the ability to deploy everywhere, GUI apps on all platforms, web, backend is fantastic. Lack of native GUI apps would be the main deficiency for me from Gleam, plus the fact that they have decided their community is explicitly politically woke-liberal.
Rust has been a fantastic addition to the language ecosystem, but recursive types, which are the bread and butter of ML-family code, are just too hard to write in Rust.
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.
C# can't fix the wrong defaults, still lots more mutable by default, and statement oriented, as an example.
average C# codebase looks different depending language version idioms, not so in F# (because initial release already had >80% of things that C# today doesn't even have and won't be able to fix).
But C# is great too, nonetheless.
average C# codebase looks different depending language version idioms, not so in F# (because initial release already had >80% of things that C# today doesn't even have and won't be able to fix).
But C# is great too, nonetheless.
I recently left a c# shop in finance. My background c/c++. I was very interested to see if c# was less work: easier to write and build.
I was not impressed by what I saw - it was junk code. One of the major errors was writing apps as MS services which dragged in tons of MS OS junk.
I cannot totally blame c#; i think the staff there were not engineers but more guys doing stuff.
The code was complex; replete with async calls. Build artifacts were entire directories of dlls, exes, json eg 50+ files per task.
The code was littered with warnings. The company could not or would not do hardly anything outside Visual Studio.
There were entire repos of code without comments; no method contracts, obscene reliance on exceptions.
I'm prepared to think f# could be better but never underestimate how bad things can be with a good language if the devs are not engineering grade developers.
I was not impressed by what I saw - it was junk code. One of the major errors was writing apps as MS services which dragged in tons of MS OS junk.
I cannot totally blame c#; i think the staff there were not engineers but more guys doing stuff.
The code was complex; replete with async calls. Build artifacts were entire directories of dlls, exes, json eg 50+ files per task.
The code was littered with warnings. The company could not or would not do hardly anything outside Visual Studio.
There were entire repos of code without comments; no method contracts, obscene reliance on exceptions.
I'm prepared to think f# could be better but never underestimate how bad things can be with a good language if the devs are not engineering grade developers.
Never under-estimates wrong defaults in a language, for example:
C++, const modifier, verbose for more correct code (less mutable state, etc.) Rust, mut modifier, verbose for less correct code
C/C++, bothersome to have tight scopped values, due to split of expression & statement ML languages, nesting of let bound values, everything is tight scoped, even recycling local names non destructively via shadowing.
C#: mostly, all flaws of C/C++/Java F#: mostly all right things of ML, OCaml, Rust
F#: Structural comparison of ML types from day 1 C#: just adding records recently; most of libraries, idioms, and semantics geared towards reference comparison
idioms
C#: mainly OO, noisy syntax, low expressivity (constructing immutable values out of generators or expressions), lots of navigation due to adhoc things needed to be named, poor type inference F#: data & functions, concise end non noisy syntax, high expressivity (list expressions, computation expression values), less scrolling & navigation, object expression rather than defining type used once, great type inference (less noisy diff on refactorings)
etc.
So average F# codebase is by construct, more sound, than average C# codebase, however F# code quality may be poor, and C# great, still, more soundness in F#, IMHO.
C++, const modifier, verbose for more correct code (less mutable state, etc.) Rust, mut modifier, verbose for less correct code
C/C++, bothersome to have tight scopped values, due to split of expression & statement ML languages, nesting of let bound values, everything is tight scoped, even recycling local names non destructively via shadowing.
C#: mostly, all flaws of C/C++/Java F#: mostly all right things of ML, OCaml, Rust
F#: Structural comparison of ML types from day 1 C#: just adding records recently; most of libraries, idioms, and semantics geared towards reference comparison
idioms
C#: mainly OO, noisy syntax, low expressivity (constructing immutable values out of generators or expressions), lots of navigation due to adhoc things needed to be named, poor type inference F#: data & functions, concise end non noisy syntax, high expressivity (list expressions, computation expression values), less scrolling & navigation, object expression rather than defining type used once, great type inference (less noisy diff on refactorings)
etc.
So average F# codebase is by construct, more sound, than average C# codebase, however F# code quality may be poor, and C# great, still, more soundness in F#, IMHO.
I would be very reluctant to use it because of the fear that at some point Microsoft just kills it. You have to wonder why they are keeping it alive so long as they are probably getting not much value out of it (some people here say they are using it as a testbed for functional features in C# but I don't believe this - I guess the C# team has enough resources to do their explorations on their own). I guess if Don Syme leaves Microsoft or retires that will be the end of it.
I can tell you, that the community keeps it alive for all these years already.
F# used to be the project #1 across all the thousands of repositories of Microsoft in terms of community contributions to the ecosystem, compared to the contributions by paid employees.
Next, F# has already been a very refined language 10 years ago, so it doesn't get a lot of things added to begin with. Slow and steady evolution, with lots of care is the topic of this game.
Also: A lot of the paid work went into the tooling, which has finally reached a point, where I consider it industry ready.
By the way: Don isn't paid to work on F# anymore for quite some time.
The world still moves on.
From my personal perspective, would it change little, when Microsoft would F# let go.
And did you know, that they finance the development of Haskell since decades?
Simon worked literally on the same floor as Don for years.
They won't let it go. Paying 2, 3 devs is peanuts for them. They don't even notice it.
I am just scared, what will happen if F# truly competes with C# for market share.
The internal competition amongst projects at Microsoft can become quite nasty at times.
F# used to be the project #1 across all the thousands of repositories of Microsoft in terms of community contributions to the ecosystem, compared to the contributions by paid employees.
Next, F# has already been a very refined language 10 years ago, so it doesn't get a lot of things added to begin with. Slow and steady evolution, with lots of care is the topic of this game.
Also: A lot of the paid work went into the tooling, which has finally reached a point, where I consider it industry ready.
By the way: Don isn't paid to work on F# anymore for quite some time.
The world still moves on.
From my personal perspective, would it change little, when Microsoft would F# let go.
And did you know, that they finance the development of Haskell since decades?
Simon worked literally on the same floor as Don for years.
They won't let it go. Paying 2, 3 devs is peanuts for them. They don't even notice it.
I am just scared, what will happen if F# truly competes with C# for market share.
The internal competition amongst projects at Microsoft can become quite nasty at times.
Are you contributing to FUD? :D
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 :)
Worst case, let the "tried F# once/for real" ramblers unload their bag once more :)
The very first advantage listed is actually a disadvantage for 95% of developers.
“Wedded to the dotnet ecosystem.”
“Wedded to the dotnet ecosystem.”
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
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.
[0] https://tracebit.com/blog/why-tracebit-is-written-in-c-sharp
[1] https://typescript-is-like-csharp.chrlschn.dev/
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/
The language has also made great strides to increase readability and decrease verbosity. I have been loving a lot of the changes over the years.
Yes; very underrated in this regard with respect to how terse the language is now. Especially switch expressions and pattern matching. C# pattern matching is incredibly rich[0], terse, while being eminently readable.
[0] https://timdeschryver.dev/blog/pattern-matching-examples-in-...
[0] https://timdeschryver.dev/blog/pattern-matching-examples-in-...
Not only. I don't want to use Microsoft technologies unless forced to or no better alternatives (GitHub/ vscode)
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."
.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."
> 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
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
To be fair dotnet is much better than JVM, mainly from having learned from Java’s mistakes.
I don’t want to use either though.
I don’t want to use either though.
> 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.
Definitely not for any NPM project. At work when we didn't touch a project for half a year it was impossible to build due to some changes in dependencies. They require continuous maintenance.
Definitely not for any NPM project. At work when we didn't touch a project for half a year it was impossible to build due to some changes in dependencies. They require continuous maintenance.
This is a fair criticism, but I think it's more accurate to say that "Venv is built-in", more than "isn't a thing"; it sounds like something is managing it for you, if they can co-exist somehow.
Python is (slowly) getting there; `uv` gets pretty close: `uv run -m $module_name` will install required dependencies & run.
(But even then, we use it at work, and there are a few complications around macOS, native libraries, and private repositories.)
Python is (slowly) getting there; `uv` gets pretty close: `uv run -m $module_name` will install required dependencies & run.
(But even then, we use it at work, and there are a few complications around macOS, native libraries, and private repositories.)
> I don't want to use Microsoft technologies unless forced to or no better alternatives
Agreed there.
> (GitHub
Github is probably in the "forced to" category, since the employer, not employee, decides, I assume.
> / vscode)
… but really? Vim. I've yet to see someone using VSCode on a VC meeting stream that isn't seemingly floundering. What does VSCode get me, aside from a proprietary editor from a company I do not trust? Telemetry and AI slop built in?
Or, you know, ed is the standard editor. /s
Agreed there.
> (GitHub
Github is probably in the "forced to" category, since the employer, not employee, decides, I assume.
> / vscode)
… but really? Vim. I've yet to see someone using VSCode on a VC meeting stream that isn't seemingly floundering. What does VSCode get me, aside from a proprietary editor from a company I do not trust? Telemetry and AI slop built in?
Or, you know, ed is the standard editor. /s
I guess vscode is convenient and I don't want to spend the rest of my life configuring vim
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)
Maybe true for all companies but especially true for Microsoft (perhaps Google, Apple, etc. as well)
That’s right. I wouldn’t chose a Microsoft tech unless there were a clear, independent path forward when they decide to break it.
There’s nothing wrong with dotnet. There’s lots wrong with being forced to use nothing else.
When your top reason for a language being mainstream is "interoperability with .NET", I think the argument is a stretch.
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#.
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#.
After reading Paul Biggar's experiences with OCaml when building darklang, and the importance of ecosystem when building distributed systems in the cloud, I don't think I'd ever build a business on a non-hosted functional language.
There are some hefty businesses built on top of OCaml so it definitely can be done, but it sounds too expensive to get a small business up and running if the code itself isn't the product.
So that basically leaves Scala, Clojure and F#
There are some hefty businesses built on top of OCaml so it definitely can be done, but it sounds too expensive to get a small business up and running if the code itself isn't the product.
So that basically leaves Scala, Clojure and F#
Depends on the use case.
Erlang, Elixir, and Gleam are hosted on their own platform, and lots of use cases can be covered that way.
Also, Flix is a thing, and some Scheme/CommonLisp/StandardML implementations compile to C.
Ecosystem there. Purescript, Gleam and others compile to JS.
Oh, and WebAssembly becomes valuable as compilation target as well.
Also: Kotlin is almost a functional first language like F#
Erlang, Elixir, and Gleam are hosted on their own platform, and lots of use cases can be covered that way.
Also, Flix is a thing, and some Scheme/CommonLisp/StandardML implementations compile to C.
Ecosystem there. Purescript, Gleam and others compile to JS.
Oh, and WebAssembly becomes valuable as compilation target as well.
Also: Kotlin is almost a functional first language like F#
It's Scala all over again.
Wishful thinking, me thinks. How good are the AI coding agents at coding F#?
For me, AI code generation for F# has been pretty good! There's one annoying thing Opus/Sonnet do (honestly don't remember what other models do): use old syntax for array indexing.
Yesterday, it did try to hallucinate a function that doesn't exist; compilation failed, so the agent changed the function to a fold and everything was hunkey-dorey.
values.[index] // Old way of indexing required a .
values[index] // Supported for awhile now
Yesterday, it did try to hallucinate a function that doesn't exist; compilation failed, so the agent changed the function to a fold and everything was hunkey-dorey.
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.
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.
> 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.
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.
> Give it a script
Ideally the build tool does that for you, e.g. `./gradlew run -t`.
Ideally the build tool does that for you, e.g. `./gradlew run -t`.
Nope.
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.
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.
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.
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.
Gates hasn't been involved in Microsoft technically since 2008 when he stepped down as chief software architect. It doesn't make sense that he's somehow standing in the way.
That was supposed to be Scott Guthrie but he got pulled into the Azure whirlpool.
C# was Microsoft’s response to Java, was F# their response to Scala and Clojure?
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#.
IIRC F# was also sort of supposed to be used for their quantum efforts, which later resulted in Q# being spawned.
It was a Microsoft Research project based on OCaml and adapted for .Net.
Clojure is the youngest in that group.
F# came out within a 18 months of Scala, It's 'possible' it was a response but my understanding is that many of the folks who created F# were instrumental in adding generics to NET2.0, so it's hard to say for sure.
.NET was initially planned as a multi language VM.
The first plan was to bring over Haskell, and Don (the creator of F#) implemented support for generics in dotnet.
The reason, why C# has an edge over Java, when it comes to generics. ;)
Then he noticed that Haskell wouldn't run on that runtime back then, and they chose OCaml instead.
The first plan was to bring over Haskell, and Don (the creator of F#) implemented support for generics in dotnet.
The reason, why C# has an edge over Java, when it comes to generics. ;)
Then he noticed that Haskell wouldn't run on that runtime back then, and they chose OCaml instead.
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
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
C# runs fine on Alpine.
https://learn.microsoft.com/en-us/dotnet/core/install/linux-...
Welcome to 2025.
https://learn.microsoft.com/en-us/dotnet/core/install/linux-...
Welcome to 2025.
You can have your cake and eat it too with dotnet core on Linux if we're talking remote / web servers.
F# has exceptions though
As noted in another sibling comment, f# has exceptions and they're a good tool to use.
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...
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...
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.
What would be the benefit to this versus generating highly optimized c# for example?
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!
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.
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.
How to you review the resulting bytecode? Or will you just go on running it blindly on some computer on the Internet?
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??
And they just have no plans to ever fix this??
> 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?
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.
Kinda. Except in OCaml this deficiency does not exist:
> Named arguments are allowed only for methods, not for let-bound functions, function values, or lambda expressions.
> Named arguments are allowed only for methods, not for let-bound functions, function values, or lambda expressions.
> Kinda. Except in OCaml this deficiency does not exist:
Still, the original concern was identified thusly:
>> I do not understand how they could develop a language inspired by OCaml but not bring over labeled function arguments.
0 - https://en.wikipedia.org/wiki/ML_(programming_language)
Named arguments are allowed only for methods, not for
let-bound functions, function values, or lambda expressions.
Still, the original concern was identified thusly:
>> I do not understand how they could develop a language inspired by OCaml but not bring over labeled function arguments.
0 - https://en.wikipedia.org/wiki/ML_(programming_language)
You can read this suggestion, and upvote, comment, contribute: https://github.com/fsharp/fslang-suggestions/issues/1434
If you do not believe in the python supremacy you are an idiot. C#, F#, M#, G# these are chords not programming languages.
I became more proficient in one language than any other. Therefore this language is the best language ever and will take over the universe.
That language isn’t the same language I became more proficient in, so are you sure it’s not terrible, useless, and will lose handily to the one I use for my specific purposes?
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)
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)
Seems unlikely as most of us are ditching .net
I was a Microsoft fanboy years ago but even I am completely uninterested these days.
I was a Microsoft fanboy years ago but even I am completely uninterested these days.
This feels like "This year is the year of Linux on the Desktop"
I've been hearing about F# hitting mainstream for over a decade. Unlike Linux, which is now fairly popular on the Desktop, I predict that F# won't ever be mainstream.
I've been hearing about F# hitting mainstream for over a decade. Unlike Linux, which is now fairly popular on the Desktop, I predict that F# won't ever be mainstream.
not to get into this debate, but linux is far from mainstream
(he types from his android phone)
Not a desktop. :) ChromeOS is closer to counting, but while it's technically Linux, that's really just an implementation detail in the same way it would be for a mall kiosk. It's hard to do actually Linuxy things with it that desktop Linux enthusiasts envision.
The meaning and purpose of “desktop” has changed over the years. The “year of Linux on the desktop” was about Linux going mainstream and being used by average joes. Well the average joe doesn’t even use a desktop anymore on a daily basis—the smartphone or tablet has replaced that, and the majority of these devices run Linux.
Also I’m channeling my inner stallman here, but Linux is just the kernel.
Also I’m channeling my inner stallman here, but Linux is just the kernel.
The desktop is much less important than it was when people started touting "this is the year of Linux on the desktop" (which IIRC was around 2000)
Functional programming people have been hoping for their favorite functional language to go mainstream for a long time but it never happens.
Speaking as a C# developer, who had in the past wanted to learn F#, but never got very far. What discourages me every time:
- C#'s good enough. Nothing's stopping you from writing functionally-oriented code in C# (and I do prefer that over traditional "enterprisey" object-orientation.)
- It's relatively difficult to have a codebase that is partly in C# and F# for incrementally trying things out. (I understand this is not really F#'s fault, owing to the .NET compilation model where C# and F# compilers each produce their own assemblies. And that Microsoft hardly cares about F#, and the tooling leaves a lot to be desired - admittedly I'm spoiled by C# tooling. )
- F# having its own implementations of concepts like async, option types introduces friction with C# obviously. I get that F# async is more powerful in some ways, but then again... F#'s option type is a reference type unlike C#'s Nullable<> value type, it's hard to see what's the advantage in that other than worse performance. One almost gets the impression that F# designers don't care about performance (while C# designers do in the past few years with additions to the ecosystem like Span<T>). This makes it hard to justify coding in F# for infrastructure libraries (which is what I often do).
- C#'s good enough. Nothing's stopping you from writing functionally-oriented code in C# (and I do prefer that over traditional "enterprisey" object-orientation.)
- It's relatively difficult to have a codebase that is partly in C# and F# for incrementally trying things out. (I understand this is not really F#'s fault, owing to the .NET compilation model where C# and F# compilers each produce their own assemblies. And that Microsoft hardly cares about F#, and the tooling leaves a lot to be desired - admittedly I'm spoiled by C# tooling. )
- F# having its own implementations of concepts like async, option types introduces friction with C# obviously. I get that F# async is more powerful in some ways, but then again... F#'s option type is a reference type unlike C#'s Nullable<> value type, it's hard to see what's the advantage in that other than worse performance. One almost gets the impression that F# designers don't care about performance (while C# designers do in the past few years with additions to the ecosystem like Span<T>). This makes it hard to justify coding in F# for infrastructure libraries (which is what I often do).
Lack of expressions is the main C# deficiency that will never get resolved. The other big advantage of F# is that it can be very easy to understand: file ordering means that you can read through from start to end to understand the code.
Ordinarily in a mixed codebase, the F# comes nearer the start, with C# depending on F#. That's because C# has lots of glue code to connect to the outside world (xaml, cshtml, EF...) and this is less straightforward to migrate to F#. The only problems with mixing languages is when you want F# in the middle of some project where it depends on some parts of the project and other parts of the project depend on it. But if you can identify something independent in a C# project and extract that out, you have already made the project simpler.
You can ignore async and use task. You can use async in the (very rare) cases when you don't want a hot task. You can also ignore Option and use ValueOption all the time. The struct types are new and have meant that F# does not have a performance deficit.
ValueOption is just better than Nullable<> since Nullable<> restricts to value types only. Resulting in Nullable composing terribly and requiring ad-hoc code everywhere.
Ordinarily in a mixed codebase, the F# comes nearer the start, with C# depending on F#. That's because C# has lots of glue code to connect to the outside world (xaml, cshtml, EF...) and this is less straightforward to migrate to F#. The only problems with mixing languages is when you want F# in the middle of some project where it depends on some parts of the project and other parts of the project depend on it. But if you can identify something independent in a C# project and extract that out, you have already made the project simpler.
You can ignore async and use task. You can use async in the (very rare) cases when you don't want a hot task. You can also ignore Option and use ValueOption all the time. The struct types are new and have meant that F# does not have a performance deficit.
ValueOption is just better than Nullable<> since Nullable<> restricts to value types only. Resulting in Nullable composing terribly and requiring ad-hoc code everywhere.
F# is basically a better C#