Why F#?

Any tips? What kind of workflows might benefit the most if I were to incorporate it (to learn..)?

It's the one programming language that changed how I think about programming.

I'm only talking about the version before type providers. Then it got messy.

Before that, we could (and I did) recompile fsi.exe to do some custom prompt manipulation. It was a slog, but it worked, but then Microsoft faded from my life. Still, that early version (I believe 2.0) F# is just magnificent.

My experience was that it was a surprisingly nice language with a surprisingly warty user experience: papercuts ranging from naming conventions and function call styles (`|> List.map` vs `.Select`), basic syntax (`foo.[0]` to lookup arrays), type system features (F# doesn't have covariance/contravariance even though C# does), IDE support (back then was only Visual Studio, whose support for F# was inferior to C#).

Ended up settling on Scala after that, as a language with its own Warts, but one that somehow managed to feel a more cohesive than F# did despite having largely the same featureset and positioning.

F# was my first functional language and one that changed how I look at programming, but at the same time I'm happy to not actually have to use it for serious programming!

hard pass

F# popularity is somewhere between CHILL, Clipper and Raku langs, that are probably as obscure as F# for typical software dev.

The flagship editor is Visual Studio, not vs code.

I know this isn't a common rant, but I hate so-called functional language still bowing to the "infix mathematical operator special case" dogma, when those are just binary (variadic in Lisp) functions.

Always found it pretty appealing, otherwise. And no ";;"!

I don't have much experience with Scala, but I think the two languages are pretty comparable in their respective ecosystems. The biggest difference I'm aware of is that Scala has typeclasses and F# does not.

    using System.Linq;
    using System;

    var names = new string[] {"Peter", "Julia", "Xi" };
    names.Select(name => $"Hello, {name}").ToList().ForEach(greeting =>   Console.WriteLine($"{greeting}! Enjoy your C#"));

F# making you unemployable is debateable, but I don't see what makes F# any less employable than most other FP languages. They have some niche applications that make it useful rarely, but when they're useful its a terrific tool for the job. F#'s ability to interop with the rest of the dotnet ecosystem positions it better than most functional languages for business usecases.

https://fsharp.org/use/desktop-apps/

Array lookup in modern F# is just `foo[0]`.

Subtyping is much less common in F# than in C#, so the need for covariance/contravariance is correspondingly lower. Personally, I've never needed it.

F# support in Visual Studio is now excellent. You can also develop F# in VS Code.

I am all for FP, immutable, and modern languages. But then where are the jobs and which companies care if you write good code?

Now everyone wants languages which are easy to use with AI, while reducing workforce and "increased productivity". I have been programming for 20 years and know 4-5 languages, in India it was worse but in EU at-least I can make a sustainable living by writing Java / TypeScript. I cannot even find jobs with Kotlin + TypeScript which pay well, forget getting jobs in Elixir / Clojure / F# (there maybe a handful of opportunities if I will relocate for around 70K/year). That is why I have mostly given up on learning niche languages.

...I mean: pipes, immutability, transparent mega-parallelism... helloooo?

I tried F# some years ago (after I was fired from a shop that decided they will go all-in on Java and F# and dropping everything else overnight) and I was not impressed. I mean the language is really nice but the C# baggage and runtime was just a bit much. And I was not left convinced that immutability alone is worth the switch. I suppose we can call F# an FP gateway drug?

Now arguably you get a runtime and some baggage from the Erlang runtime (the BEAM VM, where Elixir also runs), but the guarantees and features you get are invaluable, and have proven themselves many times over the last literal three decades.

I don't know if I would say 'well'. For simple GUIs it's OK but, for non-trivial GUIs I would use the approach to write the GUI frontend code in C# and have it call the F# 'backend'. If for no other reason than that the support and documentation for doing GUIs in C# is much better.

How about mobile?

Never tried, but I'm guessing more or less the same story as above. I would probably start by looking into .Net MAUI for that.

And how does it compare to e.g. Scala?

The biggest difference is that Scala is a much bigger and more of a multi-paradigm language. F# feels smaller and more focused and on its ML roots and functional programming. Not saying that Scala is less 'functional' than F#, but Scala supports you writing your code in a much more OOP way if you want. Yes you can (and sometimes have to) do OOP in F#, but it doesn't feel natural.

They all seem to try and shield you from the fact that you are much better placed if coming from C# (which everyone seems to refer to as .net these days) and have a solid understanding of the .net class library.

All the main web frameworks sit on top of asp.net and pretty much all official documentation for that is in c#

Such a shame because I learnt so much about types from trying to crack f# for real world application. fsharpforfunandprofit taught me heaps which I apply to other languages, but I don't want to become a c# developer which comes with all the years of changing best practices to be able to really be productive in f#.

Sorry if I am coming across as bitter but I just can't see learning f# in isolation from c# which is an absolute shame.

All the good stuff has been pirated from F# land by now: First-class functions, pattern matching, expression-bodied members, async functional composition, records, immutable collections, optional types, etc.

I'm quite employable.

There are a few drawbacks, depending on your perspective:

- compilation is slower than c# and hot reload isn't supported (it's in progress)

- there are very few opportunities to use it professionally

- hiring devs can be challenging

Being a hosted language always requires certain compromises (something that was also apparent in Scala). I used to do Scala professionally in its early days, but for me it felt it added just as much complexity as it addressed. I focused on Clojure back then (on the FP side at least), and I do think that F# probably brings more to the table than Scala. (if one is not constrained to Java, that is)

The tooling story is not great, but I've almost never seen great tooling for a language that's not super popular. I'm guessing what you get today with Rider is more or less as good as what VS has to offer.

I'm kinda wondering if anyone here with decent C#/.net experience can give their version of the answer?

---

The article really didn't answer its own question. It basically says "How" instead of "Why"...

...Which as someone who's spent over 20 years in C#, and tends to advocate for "functional" style, leaves me with more questions than answers!

Or: Is it more like the Swift / Objective C ecosystem where Swift, Objective C, and even straight C can co-exist in the same library?

In a mixed C# and F# codebase, generally when do you favor C# versus F#?

Coming from a C# background, what are the areas where F# is a better language?

Any success stories for F#, especially if it co-exists with C#? Any horror stories?

For F#, projects are needed to make full applications or libraries. Otherwise, you can simply write F# scripts with .fsx and execute them via 'dotnet fsi {SomeScript.fsx}'.

(obviously you can also specify dotnet fsi as shebang and integrate these scripts into general scripting on Unix systems - it's very productive)

I've always looked at F# with envy as it is a hosted ML that will have extremely battle tested bindings to the important day to day stuff via C# (Darklang's stories of struggling with postgres and AWS when using OCaml was a good cautionary tale on the risks of using less common langs as a startup)

Never had a chance to try out Scala but am a seasoned Clojurian, as an outsider it seemed Scala suffered a little from being not opinionated enough so the ML family has been more appealing to tinker with even though Scala supports type classes out the box and will also have great ecosystem support via the JVM

The biggest advantage of F# is its gradual typing and full type inference which allows to massively reduce the amount of text required to describe application or domain logic. It is also extremely composable and I find doing async in F# somewhat nicer than in C# too. F# also has better nullability (or, rather, lack of thereof) assurances and, in my opinion, better UX for records.

From the article, it looks like it's mostly dynamically typed. Or is it inferred? Or is it something else?

Like, if I write

    let hello value =
      print value
    
    hello "world"
    hello 2

To me, that'd be a point that might steer me away from the language. Deducible types seem vital to larger and long lived projects.

And don't get me wrong, I love the idea of Gleam, a lot (Rust syntax, strong static typing, what's not to love?). But my PL early adopter days are over.

FWIW, I managed to learn Clojure without knowing anything from Java/JVM before diving into it. I did have plenty of JS experience which made ClojureScript easier to pick up I suppose, but Java works more or less the same as every other Algol-like and/or OOP language out there so if you have any previous experience with something like that, basic Java is trivial to pick up even accidentally.

1: C# Library with interfaces and/or abstract base classes

2: F# library with implementations of those interfaces and base classes

3: C# program (console, web service, GUI, ect) that specifies the implementations in Dependency Injection

Or is there a simpler way for C# and F# to co-exist in the same project (dll or exe)?

For F# , you need some basic C# knowledge For Clojure, you need some basic Java knowledge For Elixir, you need some basic Erlang knowledge

I like all 3 languages but usually each vm have a primary language, and each hosted language eventually become hosted on that primary language not the vm

I understand that for many task simple, to medium complexity, you might not need that, but it seem as you try to be more advanced you hit the wall of having to learn you host vm primary language

Given

  let hello value =
      printfn "%A" value
    
  hello "world"
  hello 2

When mixing, you often write business logic as self-contained F# libraries with a C#-friendly API; and use C# to integrate them with whatever imperative, reflection-heavy and DI-heavy frameworks .NET is promoting the current year, since those are filled with interop edge cases for F# anyway.

You really want to avoid a language sandwich though (e.g. C#/F#/C#), because you'll keep wishing to remove the middle layer. Sadly, the addition of source generators make this mistake even more appealing.

Maybe that's just research, and I'm glad that Microsoft hasn't killed F# (I do work there, but I don't write F# at work.)

With regards to your example, the print/printfn (equivalent of Write/WriteLine) functions are a bit funny in F#. They don't actually take bound string values directly. You need to specify the type (which could be a string, a number, obj, etc)

https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

I certainly wish I were doing f# professionally, but I only ever found 1 job listing for it, and that was in vienna while I am located like 200km away from it :(

Speaking of elm: I really like elmish for the frontend, when I need to make a dynamic page in the first place. Maybe that could be to your interest? (It transpiles to react under the hood via fable, which you can webpack into a drop in bundle. But I digress)

- Typelevel libraries: modern and more welcoming take on ScalaZ ideas, rich and mature, extensible libraries that are written in "tagless final" style.

- ZIO: concrete "super monad" with 3 type parameters, shuns the Haskell baggage and category theory lingo but pretty much the same concepts, compile-time autowiring dependency injection, a bit less mature.

- Kyo: new effects system on the block, pushing Scala 3's type system to the limit to stack effects using an "auto-flattening" monad (sorry if I butchered the description).

- Li Haoyi's own ecosystem that sticks to the standard library and JVM built-in mechanisms whenever possible, focused on Python style expressiveness, only more functional and with stronger types.

- I'd skip Akka/Pekko libraries but it's still an interesting piece of software if you need actor based, stateful cluster sharding.

Martin Odersky and the LAMP are focused on "capabilities" and we should eventually see something like direct-style algebraic effects, or like Kyo but without monads.

Also we have much better build systems than before (Scala-CLI, Mill, sbt has improved a lot too), binary backwards compatibility since Scala 3, and a very capable LSP backend if you don't like IntelliJ IDEA.

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

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

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

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

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

* It’s easier to attract smart developers to an F# project than to a [mainstream language] project. This was one of my driving beliefs when I introduced F# seven years ago. https://www.paulgraham.com/pypar.html. This is probably just as true for languages like Elixir, Clojure, ... But F# is what we went with.

Small Software Shop Context

* We operated in a small market where customers eventually dictated our tech stack (.NET & React). In that market, F# was a major advantage—it allowed junior developers to build apps that "just worked" with minimal regressions. Even with mediocre code quality, I felt confident that we could refactor safely at any time.

* I constantly had to justify F# to clients, which was exhausting. We always delivered decent results, so it worked out, but my partners were never as confident in defending F#.

Bootstrapping a SaaS Company

* F# has been invaluable for shipping features quickly and taking shortcuts when needed.

* Three years in, our codebase is large and contains its fair share of messy parts. But we can still develop new features at high speed with minimal regressions. Refactoring is relatively safe and straightforward.

* Compilation speed is the Achilles’ heel. If you don’t monitor it, the compiler slows down to the point where it impacts productivity. Earlier this year, waiting over a minute for feedback after a small change became unbearable. A lot of our "clean-up" work focuses on optimizing compilation times. We're still learning, but we’re optimistic that we can restructure the project to significantly improve build performance.

EDIT: maybe one more point. I see a lot of C# vs F# popping up here. Yes, C# has all the features that F# has. But do not underestimate how well designed F# is. It is an extremely simple language to learn compared to C#. There is a very limited amount of keywords to learn. And they compose extremely well. If you learned F# 7 years ago, took a break, and came back today, you'd simply write the same boring code that you would have written 7 years ago. And along the way you'd find out that some things have gotten a bit nicer over time.

As an Elixir programmer, this does not resonate. Basically the only thing I've ever felt I needed to understand Erlang for was ets, but let's be honest, that's not really proper Erlang but just the terrible ets query syntax. And all this requires is "ability to read enough erlang term syntax to be able to understand the ets manual". I don't think I could write a single line of correct Erlang by heart.

I feel like that's different in F#, where you still need to know lots of .NET internals which are all documented in C#y terms with C# examples etc. Elixir wraps pretty much all good Erlang/OTP internals in nice Elixiry modules, which solves that quite nicely.

Elixir has its warts but this really isn't one of them.

It seemed that I had to learn C# in order to use F# properly and it seemed that porting it to C# was the saner option. I went with Rust after all and it seems to have been the right choice.

If we go by the joke in gp, this is you.

* Network effect, or lack thereof. Very few people use it. * Its nature is contrary to the ecosystem. The CLR is fundamentally resistant to the paradigms that F# creates.

Wonderful little language - one of my favorites - and we owe a lot to it for the great features that C# has. But it just hasn't picked up the critical mass it needs.

    var post = await _postService.getById(id);

    let getPostById id = async {
        let! post = blogPostService.getPostById id
        return post
    }

    let post = getPostById 42 |> Async.RunSynchronously

1. Do all logic in ML-syntax, then pass data into a computation block and handle I/O operations as the last part of your function, then return unit OR

2. Return a C#-style Task<> and handle all I/O in C#

Either way, ML-style languages don't seem like they're designed for the kind of commercial CRUD-style applications that 90% of us find ourselves paid to do.

For me, it's Erlang. I just really like its horn clause syntax, it's so clean and readable. I know a common complaint is lack of piping (and even though you can implement it trivially, the order of arguments for some functions makes it of dubious use) but it's a small price to pay.

> I mean the language is really nice but the C# baggage and runtime was just a bit much

This was my experience with F#. Frankly, I've never been happy with my experience with CLI on Linux, and the toolchain inherits a lot of baggage from its C# heritage. Microsoft's toolchains have a very distinct workflow to them. F# has some interesting aspects to it like active patterns (something I wish was more common in the ML-family), but tbh I'm more than happy with ocaml.

https://fsprojects.github.io/FSharp.Data/library/CsvProvider...

  string[] names = ["Peter", "Julia", "Xi"];

  var names = ["Peter", "Julia", "Xi"];

  ["Peter", "Julia", "Xi"].Select(name => $"Hello, {name}").ToList().ForEach(greeting =>   Console.WriteLine($"{greeting}! Enjoy your C#"));

Being a stranger to Microsoft technologies, F# was the least likely to be chosen, but easily became the first choice. Haskell's purity made it hard to adopt (for me), Ocaml's ecosystem is subpar (there wasn't even a clear choice for a library to interact with postgresql, I couldn't install the latest version due to its reliance on an obscure tool whose name I forgot and didn't get help on the forum), and Scala is seems complex....

F# was surprisingly easy to get started with. The community is mis-managed by a corporate-minded approach (requiring people to become member of the F# software foundation to get access to the official slack!), but its members are friendly, smart and ready to help. The ecosystem is great with access to all the dotnet libraries (some complain there's a mismatch as most of those are developed for use with C#, but I rarely got in trouble for using them).

There are also great libs and frameworks available. Like https://github.com/SchlenkR/FsHttp to easily interact with http servers, to the point that I find it easier to use than a dedicated library. Or https://github.com/CaptnCodr/Fli , to run commands. And last but not least, https://www.websharper.com/ is the best web framework I have encountered across all ecosystems. Their reactive approach to web ui really allows me to develop complex interfaces in a maintainable way.

This became a longer message than I thought, probably due to my enthousiasm for the language. For complete transparency, the situation is not perfect, and in my experience the tooling is not the best.

If you want more info, I blogged about it a couple of months ago: https://www.asfaload.com/blog/consider-fsharp/

I’m not a dabbler in exotic languages, so this definition of “popular” was puzzling. I’ve literally never seen that operator before. Maybe I need to get out more.

the F# equivalent is

`let! post = _postService.getById id`

With which language are you comparing with?

Because there's afaik csproj and maybe .sln

and both of them are let's be frank - foundational for almost all projects that arent just hello world.

Otherwise you end up with some cmakes or something similar that want to achieve something similar

    <source>(5,1): error CS9176: There is no target type for the collection expression.

It seems reasonable to have it default to Array if it's ambiguous, maybe there's a downside I'm not aware of.

Also, FSharp.Core (which most F# code leans heavily on) is not OOP at all.

F# promotes object programming, doesn't proscribe mutability, encourages function and data approach.

It offers simple access to the different paradigms, with some opinionated choices (e.g. preventing leaning on OOP beyond an arbitrary stretch, like no "protected", only explicit interface implementation, etc.).

F# is just a better language. Simpler, more concise, more readable with stronger type safety. I will never go back to writing C# as I'm finding it too frustrating at times and unproductive.

I think if I ever have time for another go I would learn enough to be proficient in c# before diving back in.

The controller handler is also the same. It will be marked with `async` keyword in C# and `task` CE in F#

Having used Haskell in production for a bit now, I don't even notice its purity. Most functions are in some kind of I/O context making it similar as other languages, except with the option of running without I/O capabilities for functions that shouldn't need it.

It just takes time to defeat the 40+ years of c and c++ dominance.

Another thing that was hard to grasp for me were the special operators like =<<, ., $, etc. I was using Xmonad, but those operators create a barrier to understanding exactly what happened in the file.

In the end, F# was in my (personal) experience much more approachable, and it let me learn the functional concepts along the way.

https://3dpack.ing

Here's a rust ray tracer compiled to web assembly written in F#

https://ncave.github.io/fable-raytracer/

source: https://github.com/ncave/fable-raytracer?tab=readme-ov-file

F# feels kind of similar to Python in this regard, where there might be more than one way to do it, but there is community and ecosystem consensus on what is the right way.

I think a lot of credit should go to Don Syme for this; he seems to have a very clear vision of what F# should and should not be, and the combination of features ends up being very tasteful and well composed.

    let names = ["Peter", "Julia", "Xi"];
    names
        .map(|name| format!("Hello, {name}"))
        .iter()
        .for_each(|greeting| println!("{greeting}! Enjoy your Rust"));

Here's an example: as I said in my original message, I was a complete stranger to the dotnet ecosystem, and I learned the F# language at the same time. And I decided to develop the app as a library project to be used by the web app. I completely missed the prevalence of the async approach in the dotnet, and all my code was synchronous. One day, about half-way in the project, I realised I needed to switch to async code. Had this happened in a dynamically typed project, it would have been hell for me. Maybe it's me that can't grasp a project well enough, but I need the type-guardrails to find my way in large refactorings. And with the strong types, large refactorings can be done confidently. They don't replace tests, but make the refactoring process much more smooth.

The app is open source and its code is at: https://gitlab.com/myowndb/myowndb It doesn't have a lot of users, not the least due to lack of marketing and polishing the user experience. But I am satisfied of what I learned developing it!

C# and F# both work fine with Rider or VS Code on Mac or Linux.

F# on the JVM would be great though!

I wrote a tutorial about how to get up and running with web dev in F# that might be of interest: https://functionalsoftware.se/posts/building-a-rest-api-in-g...

However, the best functional programming language is, of course, Elixir. :D

https://fsharpforfunandprofit.com/posts/dependencies/

FWIW you can do it exactly the same way you do it in C#; it’s not “wrong”, it might just feel a bit out of place.

Plus, I'm not going to be downloading, configuring, or running any separate code at runtime. The project is the project, it's going to process some files, communicate with some services, and communicate with the UI, if any.

If I need to consume a service, it should be defined such that I manifest the interface module (perhaps via WCF) and then connect to it progressively from stub to ever greater functionality in test to final implementation. Trying to write a program to do all that at runtime is not sensible, IMO.

Metaprogramming via reflection, however, was useful for exploring the vast .NET framework, and I used those to great effect, especially in exploring .NET's various UI frameworks (WinForms and Silverlight), but never to create code at runtime via the emit functionality. No, that's my job: to emit code that is tested and works and is comprehensible.

But they still miss the computation expressions, which open interesting possibilities like https://github.com/CaptnCodr/Fli and https://github.com/fsprojects/FsHttp

laughs in clojure

    %w{Peter Julia Xi}.map{"Hello, #{it}"}.each{puts "#{it}! Enjoy your Ruby"}

That is, each language will have its strong and weak points, but so far on "fluency" I’m not aware of anything that really beat Ruby far beyond as Ruby does compared to other mainstream programming languages.

My current work needs nothing the .NET environment provides that I can't use python's standard libraries to get done, or bash and C if I need to.

But I'm lucky to no longer be in a corporate environment, so I don't need to consume commercial services, which was much easier using WCF within .NET. Back in my previous life, constructing n-tiered services on top of SqlServer using WCF was slick, indeed.

To any who are interested in how to construct such n-tiered applications simply but securely and precisely, I highly suggest Juval Lowy's IDesign system. He had three specific videos that I watched three or four times each until I understood his distillation of his vast expertise. Of course, Mr. Lowy is one of the co-designers of WCF, which was an excellent bit of tech.

[0]: https://gleam.run/

- Hot updates.

- Full distributed system support.

– Low-level process manipulation.

- Named processes.

- Advanced supervision strategies.

- Behaviours other than GenServer.

- Type-safe distributed messaging.

- And several other things that I value in BEAM and OTP.

I can't justify trading the full power of BEAM and OTP for static typing. To be fair, though, I've written a lot of code in both statically and dynamically typed languages, and static typing isn't something I value much (to the point that you might say I don't care about it at all :D).

Otherwise, I am happy with OCaml, but F# has also a place in this world.

Pro tip: don't write F# like you would write C# - then you might as well write C#. Take the time to learn the functional primitives.

For the specific case of C# use of await it is unfortunate that C# didn't design this feature with F# interop in mind so it does require extra steps. F# did add the task builder to help with this so the 'await' is replaced with a 'let!' within a task builder block.

  let getById(id:int) : Task<string> = failwith "never"
  let doWork(post:string) : unit = failwith "never"
  let doThing() = task { 
    let! post = getById(42); 
    doWork(post); }

  let getPostById1(id:int) : Async<string> = async { return! getById(id) |> Async.AwaitTask }
  let getPostById2(id:int) : Async<string> = getById(id) |> Async.AwaitTask 
  let getPostById3 : int -> Async<string> = getById >> Async.AwaitTask

I like Erlang a lot, too. Both are great languages.

The author of the original comment, however, does not know this nor tried verifying whether F# actually works seamlessly with this nowadays (it does).

Writing asynchronous code in F# involves less syntax noise than in C#. None of that boilerplate is required, F# should not be written that way at all.

For those who have already done functional programming, they wont take more than 2 days to start getting productive. For those who have written a lot of code, it will take them ~2 weeks to pick up functional thinking.

Anyone who is still uncomfortable with F# after 1 month - well that's a strong signal that the dev isn't a fast learner.

Additionally, I've never had anyone reject our job offer because we do F#. I'm sure a whole bunch of people might only be looking for python or javascript jobs, but that's fine because I'm not looking for them. I always have more people who I want to hire but I can't due to budget constraints.

Source: direct experience - I run a pure F# company with a team size of ~80.

It is controlled by Microsoft. It's not going on my Linux or BSD boxes.

I know how they work, and I want nothing to do with them.

Oh, and every language with line comments (so most of them) has significant whitespace.

I assume you are implying that too many choices could confuse a junior developer, which I agree with. However, I don't think this is a concern in the bigger picture when talking about the space of all languages.

For that matter, you don't even need the interfaces if you wouldn't have had them in a C#-only solution. Just define the class in F# and use it directly from C#.

You still need a separate assembly for F#, but that doesn't imply dependency injection - again, just reference it and use it.

Is there something about that that has bothered you? Working in Scala codebases, I've found the best ones to work in are the ones that embrace Scala's multiparadigm nature. When programmers try to solve every problem with OO, they end up adding more and more layers to get the job done. When programmers try to solve every problem with FP, they end up resorting to sophisticated techniques that are unapproachable for other engineers. I think the simple parts of OO and the simple parts of FP go much, much further together than simple OO or simple FP can go by themselves. Have you seen something different?

One caveat though: it seems FP matches my way of thinking. As an example, I always liked recursion, while some others saw it as complexifying things.

Try fsharp as fsx scripts to avoid boilerplate (see blog post linked in other comment) and you'll rapidly feel if you like it or not.

https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

In the interim, MS demonstrates how C# 8.0+ can fake it pretty well with recursive pattern matching: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

Not the same I know, and I would love me a true ADT in C#.

Edit (a formal proposal): https://github.com/dotnet/csharplang/blob/18a527bcc1f0bdaf54...

Personally, I'm just annoyed by never-ending cycle of ".NET is bad because {reason x}", "When was this the case?", "10 years ago", "So?".

Like in the example above, chances are you just won't see new F# code do this.

It will just use task { ... } normally.

It has been "stuck" at Stage 2 for a while, though.

Funny how preferences and priorities vary among devs, I need my static type system! :-) But note even in static type systems there are variations. I'm talking about an hindley milner type system with its type inference like the one in fsharp

Elixir made me more productive and gave me back my love for programming, and I work with it professionally for 9 years now. But the lack of static typing is getting so irritating that I started upping my efforts to get [even] better at Rust lately.

So I agree. It's one of the very top drawbacks of Elixir.

I don't think being whitespace-significant is a "hard pass" dealbreaker, but as someone who's not a fan of it, I'd say this only goes a small way towards alleviating that - like most "choose your preferred syntax" designs. Even if you're a lone-wolf developer, you're gonna end up reading a lot of example code and other material that's in the ugly whitespace-sensitive style, given that:

> The verbose syntax is not as commonly used ... The default syntax is the lightweight syntax.

And most people in practice are not lone-wolf devs, and so the existence of this syntax helps them even less.

Last time I tried C++ with Copilot it was terrible.

But .NET's CLR doesn't seem especially shitty. It's not awesome, I don't feel that RIIR urge when I work with C# and I probably wouldn't with F# either but it's fine, it's like Java again, or maybe Go or Python. It's fine. I don't hate it and that's enough.

How so?

> Oh, and every language with line comments (so most of them) has significant whitespace.

Technically true, but that's not what people mean by "significant whitespace" in this context. So you're being pedantic rather than saying anything meaningful.

But you made me think. The ultimate nightmare would be significant trailing whitespace - the spaces and/or tabs after all the visible characters change the meaning of the line.

We even do the frontend in it using Fable and Elmish, which is to say: we basically write our frontends in Elm, but the platform is .NET.

In this case, I would move it to the very end if we are concerned about the underlying data shifting when the collection is actually enumerated.

Forgetting to materialize LINQ results can cause a lot of trouble, oftentimes in ways that happily evade detection while a debugger is attached.

(Yes, I'm familiar with the rich ecosystem around helping devs not write crummy C. I worked at Coverity at one point. If anything, that gave me enormous fear and respect of the hoops you have to jump through to be reasonably sure C code isn't completely broken.)

It baffles me that there are languages with non-profit foundations and are financially backed by multiple corporations which still have bad build systems. It is the most important investment you can make into a programming language.

[0] https://survey.stackoverflow.co/2024/technology#most-popular...

I’m not sure what you mean by this. You can fulfill the IEnumerable contract without allowing multiple enumerations, but that doesn’t really have to do with the data shifting around. Doing ToList can be an expensive and unnecessary allocation

Even if is slower, the runtime model is incredibly resilient and it’s cheap to scale up and down, easy to hot update, and generally does asynchronous work extremely well across a lot of different processes.

F# has really good async ergonomics but it doesn’t have the same task/processing flexibility and Websockets are kind of a pain compared to elixir or even erlang

It really isn't, not anymore. F# now evolves conservatively, just trying to remove warts and keep up with C# interop.

And even then some C# features were considered too complex/powerful to implement (e.g. variance, scoped refs) or implemented in weaker, incompatible ways when C#'s design is considered messy (e.g. F#'s non-nullable constraints disallow value-types, which breaks for some generic methods written in C#, sadly even part of the System libs).

The default F# autoformatter is bundled/supported by VS Code, VS and Rider [0].

[0]: https://fsprojects.github.io/fantomas/docs/end-users/StyleGu...

You mark your functions and non-functions as such, so the compiler can get your back.

Well I don’t know what issue you have with whitespace, but the usual complaint is that programs with small typos are syntactically valid but logically incorrect. This is why CoffeeScript became so disliked. A static type checker makes this scenario much less likely since it won’t compile.

I would also add that F# has some indentation rules (“offside rules”) and tabs are disallowed, further shrinking the input space.

For mobile we have FuncUI (on top of Avalonia) and Fabulous (on top of Avalonia, Xamarin and Maui). Most of these frameworks use Elm architecture, but some do not. For example I use Oxpecker.Solid which has reactive architecture.

Can't help with Scala comparison, but at least DeepSeek V3 prefers F# for UI https://whatisbetter.ai/result/F%23-vs-Scala-9eaede00c7e4485...

`task` targets the .NET TPL instead, which is also what C#'s await/async and all of .NET *Async methods use.

While the `async` implementation still offers some benefits over `task` (cold vs. hot starts [0]), my advice is - if you're doing backend code on .NET, you should use task. The tigher integration with the .NET ecosystem & runtime results in better exception stack traces, easier debugging and faster performance.

[0] https://github.com/TheAngryByrd/IcedTasks?tab=readme-ov-file...

C++ intersected the mass of C programmers with the new OO fad, and kept all of C's warts. Had Stroustrup made C++ better, he wouldn't have an army of adopters who already knew C. Maybe merit will win out in the long run [1]? I'm not hopeful.

Java needed to be close enough to C++, and C# to Java. And Brendan Eich joined Netscape to "put Scheme in the browser".

[1] https://www.theregister.com/2025/03/02/c_creator_calls_for_a...

For example, C# may have cribbed the language features, but F# is expression based and immutable by default. Try using the same features in this context and the whole game changes.

This is a practical side of F# that doesn’t get enough spotlight — but one I’m using daily.

[0]: https://news.ycombinator.com/item?id=42636791

Even if you never write a single line, it’s a fantastic illustrative language.

For example I refer to https://fsharpforfunandprofit.com/ all the time for functional programming ideas.

F# has many theoretical qualities, which make it fun if you like these things, but it also has some fundamental flaws, which is why it's not getting a wide professional adoption.

- the build system was a mess last I checked (slow, peculiar)

- syntax is not c-like or python-like (a big deal for a lot of people)

- you can't hire developers who know it (and certainly the few are not cheap)

- the community is a bit weird/obsessed/evangelizing (a turn off in a professional environment)

- it's clearly a second class citizen in the .net world (when stuff breaks, good luck getting support)

On the other hand

- it has discriminated unions

- units

- etc.

but do you need this stuff (not want: need)? most people don't.

A few years ago on here I had an interesting conversation with someone who wasn't going to use rescript for something because they didn't like how it handled object types. I can't remember ever using an object type in rescript; we all just convert js objects to record type in the extern binding. But that's not information easily available to someone who has never used the language.

Same thing here I think. If you don't already have familiarity with this paradigm, it's hard to imagine what using an IO monad for side effects is like. It's not easy to tell how hard it'll be to learn it, how much it may affect the rest of your code, etc. It's easy to imagine someone (shit even me a few years ago) going "eh I'll take the language with the big easy escape hatches just in case."

Also, basic object initialization in C# has turned into a nightmare with recent versions. You need a flowchart to select among the 18 syntax options which suite your current needs.

With F# (and other newer languages), record fields are either `T` or `T option`. No need to worry about whether the value needs to be computed in a constructor and then remain immutable, whether it needs to be initialized by an object initializer and/or a constructor or not, whether it needs to remain interior-ly mutable throughout the life of the record, and so on. (Although as I recall you do still need to consider null values assigned to non-nullable references in your F# code that consumes C#.)

These days I'd just do such a task more-or-less imperatively in Haskell, and I would be well guided by the types in doing so. But I also feel like you have to make a few such mistakes if you want to get a good intuition and taste for when it's good do things purely and when imperatively.

  let bar = 
      if foo then  
         7  
      else  
         11

  let bar = 
      try
        // code that might throw
        7
      with ex ->
        11

Whereas in C# you have to do like

  int bar;

  if (foo) {
     bar = 7;
  } else {
     bar = 11;
  }

Except that most C# developers do

  int bar = 0; // or some other default value`

This doesn't seem like a big deal given these examples. But it becomes a much bigger deal when the if/else grows super large, becomes nested, etc.

Even in a VM? Why not?

I only used F# at its command line, fsi.exe, to give me commandline access to .NET for exploration, testing, and munging data. Over time, I built up quite a library of usable functions that I'd have the fsi.exe program pre-load when I kicked it off, leaving me at the prompt with all .NET namespaces and my code ready and accessible.

Once you get access to your database's data, it's easy to write queries against it and then play with the data. I could then port the F# processing bits that worked into my C# projects as necessary, but it was far easier to do it that way than to write the logic deep within complex multi-project solution files, where the various classes are spread throughout the projects' files.

I also just really enjoyed using F#.

ahhh, Its April Fools?

JK, I love F#. Please get over the hump and be a big language.

IMO its generally more readable as well to non-dev than C# and to dev's outside the Java/C# ecosystem (e.g. Node, Go, etc). I've shown F# code back in the day to non-tech stakeholders and they typically understand it (e.g. data modelling).

it is functional (value) programming first. there are tools to hook in the object jvm stuff but this is not the natural grain of the language.

clojure is pretty much all values and functions (and some macroes).

+ some concurrency stuff

there is no class, there is no inheritance, you don't even have information hiding (no private etc.). you have protocols and multimethods.

(well technically there is private because java but it is not obvious to use and not what you expect, you will very rarely see that in clojure codebases)

honestly it is a nice small yet powerful language, with not too many kludges. my personal coding is either clojure or rust (which has way more kludges, but better than the other stuff in the typed fast compiled world at least for me).

The equivalent C# to your F# would be

  task { return! _postService.getById(id) }

To make C# comparable to your F# code (tasks are not the same so not quite true) you would need to define a method around it, and find a way if you want to run the resulting Task synchronously to do that safely.

  public async Task<Post> GetPostById(id) => await blogPostService.getPostById(id);

  // This is not entirely eq - since tasks are hot
  this.GetPostById(42).Result

Separately installed software? Not a bit of it.

The basic decision making logic needs to be very simple and easy to follow by scientists and people who aren't day-to-day software engineers: Basically, input some data, such as sensor readings, run it through an algorithm that makes decisions, and then output the decisions.

names.ForEach(name=>Console.WriteLine($"Hello, {name}! Enjoy your C#"));

This is a good observation.

As someone who writes a lot of Lisp, I'm inclined to agree as the amount of people that have never written any Lisp yet immediately reject it over syntax over fears that it somehow hampers development is a (to me) surprisingly large number of people.

If I recall correctly, one of the motivating factors for Rescript was to reduce the perceived/real distance between Reason and JS in order to attract more JS devs, as Reason was so heavily associated with OCaml.

In both languages these patterns make up for the absence of typeclasses to express things like a functor, applicative, monad, comonad, etc.

[1]https://ecma-international.org/wp-content/uploads/ECMA-334_7...

If I am developing something in my spare time I also like to use something I can earn money with so I can hone and maintain my earning skills. Maybe sounds like min maxing.

If I would be in a situation where I can develop software just out of pleasure or pure curiosity, I would use just whatever language I deem interesting.

Compared with C/C++, Java, C#, Javascript, Python, Typescript, PHP, all the rest can be considered niche.

    > Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year?

Also, in the same results, just above Rust, I see:

    > PowerShell 13.8%

But the moment you search Rust on LinkedIn, you can see the truth.

static typing: 2 + "2" does not compile/parse (e.g. Python vs mypy, Typescript vs JS)

this is a very simplistic example, but should get you to feel the difference.

I like F#, Haskell, Elixir but not Rust.

   %w[Peter Julia Xi].map { |name| "Hello, #{name}" }.each { |greeting| puts "#{greeting}! Enjoy your Crystal" }

>Crystal is a general-purpose, object-oriented programming language. With syntax inspired by Ruby, it's a compiled language with static type-checking.

But this time, one can probably say that Crystal will lake the benefits of ecosystem that only a large popular language enjoy.

I guess on that side F#, relying on .Net, is closer to Kotlin with Java ecosystem.

- hiring devs can be challenging

Those drawbacks are huge, IMO.

On the other hand, "strong typing" isn't as quite as standardized in type systems terminology, but broadly speaking, it tends to be used to describe things like how "sound" a type system is (which is a well-defined concept in type systems theory), whether or not implicit type coercions can occur in the language, or other things that roughly translate to whether or not its possible for things to get misused as the wrong type without an explicit error occurring. Two examples that are commonly cited are JavaScript[0], with its sometimes confusion implicit conversions to allow things like adding an empty object and an empty array and getting the number 0 as the result (but not if added in the other order!) and C, with it being possible to interpret a value as whatever the equivalent underlying bytes would represent in an arbitrary type depending on the context its used.

[0]: I normally don't like to link to videos, but this famous comedic talk demonstrating a few of these JavaScript quirks is so thoroughly entertaining to watch again every few years that I feel like it's worth it so that those who haven't seen it before get a chance: https://www.destroyallsoftware.com/talks/wat

    > I'm completely convinced that F# (along with Scala, Haskell, and OCaml) adoption has stalled due to having ridiculously bad build systems.

    > Hell, 80% of the reason I choose Rust over C++ for embedded work is because of the build system.

My guess is that it's much longer than for the equivalent Java apps.

> What is wrong with CMake for C++?

It doesn't manage dependencies.

Even intellij has no idea sometimes about what the hell is going on. It throws up compile errors when there none.

F# makes mutable code harder to do, so you tend to write immutable code by default.

Possibly `eval $(opam env)` is something that should just go in your ~/.zshrc

The OCaml folks have done some work recently to improve the onboarding documentation, which I think is going in a positive direction

e.g. https://ocaml.org/docs/installing-ocaml (the eval as a one-off post install command)

And then guiding people to use 'switches' https://ocaml.org/docs/opam-switch-introduction, which I totally missed when I started with the language.

> Local switches are automatically selected based on the current working directory.

[0] https://learn.microsoft.com/en-us/aspnet/core/signalr/hubs?v...

[1] https://azure.microsoft.com/en-us/products/signalr-service

    > Anyone who is still uncomfortable with F# after 1 month - well that's a strong signal that the dev isn't a fast learner.

For myself, I feel that I have "full" command of C# as a programming language, but also how to structure projects, how to isolate modules, how to decouple code, how to set up a build system from scratch for C#, how do deploy and scale applications built with C#, what the strengths and weaknesses are, etc. My definition of "comfort" would entail a broader understanding of not just the syntax, but of the runtime ecosystem in which that code operates.

I just gave a talk about how we use F# at REN: https://vimeo.com/1070647821

At the same time, a lot of the cool features (list comprehension, pattern matching, immutable records) have slowly trickled into c#, giving even less incentive to switch