For my domains personally the static math functions are still clunky to me in C#, and the forced compiler time inlining can really help some algorithms with massive perf gains (experienced firsthand) especially with some of the newer .NET features (e.g. ref's). IMO to me the nicest thing is the terse syntax, and that I need less IDE as a result. There just seems to be less refactoring tools required to get started and onboard people.

I think the abandonware thing is expected. But I think this is the cost of a language that is a child's to a main ecosystem and doesn't just apply to F#. Unless its specific to FP/the F# domain it will be written in C# or whatever the common language is for that platform. Ironically the language with the least features is the one to write in (LCD) so it targets the most people. Why would I just target one language on the platform when I can target all languages? Especially if I'm paying a team to write the library. Most bang for buck so to speak.

Hence most things in these side languages are either wrappers to make them more idiomatic and/or pattern libraries that are specific to the extra value add the language has and usually don't need to change much once implemented. I think that's fine and pragmatic, why reinvent something that works?

On top of your answer and the other, I still think Discriminated Unions are still a big hole in c#. I know they are supposedly working on it, but until they officially release it I'm not believing them.

It's easy enough to do DUs, they are working on it, but they are just syntactic sugar for abstract class/subclass

for instance, as an example for this https://fsharpforfunandprofit.com/posts/designing-for-correc... where a C# solution is suggested and done with DUs in F#, I wrote the equivalent DU solution in C#... https://gist.github.com/keithn/ceeeed5f7eb567e1b2333747065d1...

Only thing you don't have is exhaustive checking, which I personally don't think is much of a problem pragmatically.

Exhaustive checking and locking down the base type if you don't want anyone else to extend it beyond your choices of subtypes, unless there's a way I don't know about to lock down extending to inside your binary while letting others ask for any types that references it.

There's a secondary benefit though if they allow DUs of Structs where you can have it be on the stack as a single value based on the size of the largest subtype that could be incredibly useful when you are worried about performance. Inheritance does not do that.

I too miss discriminated unions in C#.

But even more often, I find myself wishing C# blocks were expressions.

In F#, I could do this:

  let x =
      let z = whatever
      ...
      value

and z is inside a local scope.

So in C#, I want to do:

  var x =
  {
      var z = whatever;
      ...
      value
  };

Maybe it's just me.

Nah it isn't just you. I probably use this more in my Rust experience then F# but when I remember it is there it is incredibly valuable.

I'm finding switch expressions filling that gap a lot lately. I've also picked up at some point a bad habit in "borrowing" JS' ugly IIFE pattern in C#.

    var x = (() =>
    {
      var z = whatever;
      ...
      return value;
    })();

It is not the most performant way to write that code and if the contents start to get long, refactoring to its own method starts to feel more likely, but in one-off cases, it seems fine for how ugly it is.

... or units of measure

This is a surprising gap for most non-ML type systems from what I’ve gathered. I don’t understand the gap, tbh. Most of us aren’t slinging primitive values with no particular domain in mind, it’s weird that we have to encode most of the domain in naming conventions and docs.

while I like it, it doesn't actually seem that useful.... and given I work on IoT systems measuring all kinds of things in all kinds of units, it isn't at all useful for that. Kind of cool for when you are using F# as a calculator though

I haven't found them useful in my experience either, but they seem to have a real indispensable utility in some cases like algebra for simulations. At least, that is what I gathered from Matthew Crews who has the "FastFSharp" channel on YouTube and a Twitter account with the same name. (He employs mutability heavily for performance, so not what I think of as an average F# developer.)

I found both Linq expressions and F# computation expressions to be limited (as in: subsets of corresponding languages exclude too much) for the few purposes I tried them on.

Yes you get abandonware but in other fast moving language you get so out of date that you might as well have been abandoned. Unless you're spending a lot of time upgrading.

The abandonware is the problem i have with all the niche languages I enjoy using. If you go down the communities "hot path" there are usually well maintained stuff. But the second you want to go off the path you find a lot of libraries not maintained for a few years. I like to think "oh the library is just complete", but you then use them in your project and get crashes. And i don't think i'm good enough yet at the language to go in and fix the problems.

Passing functions in C# is the worst experience though, and not having partial application really forces you into DI hell, which is the worse part of large software in C# IMO. Dependency Injection frameworks are soul killing