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#.
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#
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#
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`.
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.
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.
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
https://learn.microsoft.com/en-us/dotnet/core/install/linux-...
Welcome to 2025.
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...
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.
And they just have no plans to ever fix this??
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.
> 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.
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.
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.
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.
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
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.
> 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".
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.
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 was a Microsoft fanboy years ago but even I am completely uninterested these days.
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.
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.
- 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).
smoothdeveloper•4h ago
Worst case, let the "tried F# once/for real" ramblers unload their bag once more :)
adastra22•4h ago
“Wedded to the dotnet ecosystem.”
taberiand•3h ago
akkad33•3h ago
moron4hire•3h 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.
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•3h ago
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
adastra22•1h ago
I don’t want to use either though.
deathanatos•3h ago
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.)
ofrzeta•2h ago
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.
deathanatos•3h ago
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
bb88•3h ago
Maybe true for all companies but especially true for Microsoft (perhaps Google, Apple, etc. as well)
kstrauser•3h ago
CharlieDigital•3h ago
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/
hirvi74•2h ago
adastra22•1h ago