Earlier quoted context omitted.
The very first advantage listed is actually a disadvantage for 95% of developers. “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
Why F# could be the next mainstream programming language (2024)
11–20 of 99 posts
Re: Why F# could be the next mainstream programming language (2024)
#12Earlier quoted context omitted.
The very first advantage listed is actually a disadvantage for 95% of developers. “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
Maybe true for all companies but especially true for Microsoft (perhaps Google, Apple, etc. as well)
Re: Why F# could be the next mainstream programming language (2024)
#13C# was Microsoft’s response to Java, was F# their response to Scala and Clojure?
Re: Why F# could be the next mainstream programming language (2024)
#14Kotlin 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
Re: Why F# could be the next mainstream programming language (2024)
#15Earlier quoted context omitted.
The very first advantage listed is actually a disadvantage for 95% of developers. “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
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
Re: Why F# could be the next mainstream programming language (2024)
#16Not 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
https://learn.microsoft.com/en-us/dotnet/core/install/linux-...
Welcome to 2025.
Re: Why F# could be the next mainstream programming language (2024)
#17Re: Why F# could be the next mainstream programming language (2024)
#18Not 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
Re: Why F# could be the next mainstream programming language (2024)
#19And they just have no plans to ever fix this??
Re: Why F# could be the next mainstream programming language (2024)
#20Wishful thinking, me thinks. How good are the AI coding agents at coding 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.