[myu701]

Look - I don't have anything deep to say here. I can only say that between 'records' and 'with-expressions' now in C#, I as a hobbyist F# developer feel like I'm being shaken down by the mafia.

C# designers: "Hey, nice language features you have there. I'll just borrow them for a bit ok, it'll be fine..."

Later, C# programmers: "why would I learn F#, C# does all the same stuff!" (even though it doesn't)

Edit: I admit being both glad that C# is gradually migrating to the ML-style coding which will make F# more mainstream, and nervous that C# will get close enough to kill F# adoption yet too far away to actually get all the benefits of F#.

Some examples of this include the Hindley-Milner type system, partial application, discriminated unions, and all of the compile-time goodness the F# compiler gives and the C# compiler ignores.

[kungato]

Well F# obviosly never gained enough momentum and C# has to grow somewhere so why not in this direction. All "big" languages are gaining more and more functional and declarative features each version. I always remember this chat by Simon PJ, the "father" of Haskell about convergence of languages in features https://m.youtube.com/watch?v=iSmkqocn0oQ

[myu701]

> Well F# obviosly never gained enough momentum

As a member of the F# Evangelism Strike Force (to use an n-gate ism), I want to argue this point but there is not enough info to determine what 'enough momentum' means.

I can produce, without leaving F#: libraries, cli apps, windows services, windows desktop apps, websites (asp.net core + giraffe), web apps, SPAs (SAFE stack), and more. If I target .NET Core, I can run my F# in windows land, linux land, and anywhere else .net core has been ported. What features does C# offer that F# doesn't, aside from being more familiar to lots of MS devs? Even I started my dev journey with C# on Windows Mobile 5 via .Net Compact Framework.

Cons: The F# tooling is just worse than C# tooling. Compare the 20-year old language with support since Visual Studio 2003 .NET to the one that has for some reason focused on the VSCode + Ionide plugins rather than the tooling that VS users run into and even I can't really argue that C# has better tooling. Biggest weakness of F# is all the wonkiness when it comes to common tasks like making, running, building, publishing codebases. The use case of something common like 'make me a new blank app, I want it to use paket for dependencies and to spit out an alpine docker image with .net core sdk at the end' should be 1 command, then triggerable from the VS Debug/F5 button. It just isn't that yet.

> C# has to grow somewhere why not this direction

I'd rather C# lean more FP than lean more OOP, sure, but _does_ C# have to grow somewhere? Can't a language spec be declared good enough / maintenance mode at some point so the programmers can focus their learnings on fuller understanding of the spec itself, as well as improving the implementations and tooling around a language?

[kungato]

A language could be declaered good enough but none of the popular languages are there. They all had plenty of "bad but popular" design decisions at the beginning and now they are trying to compensate. What I hate is the constant repeating of everything. I'd rather one language have everything crammed in and we get to choose what we want and what we don't want. No "good" (my opinion) language will ever have only "one way of doing things" so why not just add everything and get over with it. In any case, all the "big" languages seem to be racing to "add everything" anyways.

IMHO my biggest issue with languages like F# and Haskell is like you mentioned the lack of tooling. I can even get over the fact that the ecosystem is smaller but the lack of ergonomics (things are harder to do, there's more friction in the dev process) always sends me back to C#. I wish F# tried to get into Roslyn instead of having their own compiler. I get the prestige and practicality of doing your own thing but I think it costed them a lot of missed out features and polish. I'm not that familiar with F#. It very well could be the language is too different to reuse almost anything from the semantic part of Roslyn but there's still so much else there they could get for free

[pjmlp]

It is called Go.

[thelazydogsback]

F#'s strengths are also some of its weaknesses. Re: H-M type system (a) the lack of decls makes code nice to look at when writing, but coming back to it a year later or w/someone else's code, it can be hard to follow. (b) Sometimes the errors are still quite baroque! And the tooling (esp. 3rd party) isn't as prevalent.

Partial application can be one of those write-only code constructs unless used in very simple/canonical patterns. I'd also like to have a Scala like "hole" syntax with positional args -- this is also need to alleviate the need to write a (fun -> ...) when calling methods on object in a |> pipeline. And speaking of pipeline, they look nice, until you want to debug through them. (Need something like Ozcode's LINQ debugger for pipelines.)

F# also (last I checked) doesn't do the level of optimizations I'd like to see, such as removal of tuple creation between fn's when there never actually stored, etc.

Although I understand the rational for the Curried form for fn types, it seems a bit pedantic to present things this way by default -- seeing (int -> string) -> Foo -> (bar list -> baz -> qux) is IMHO harder to look at than the standard presentation. Although C# really needs seq and post-fix types -- "IEnumerable<Foo>" is an eye-sore compared to "Foo seq".

But it's hard to go back to any lang w/o DU's...

[LandR]

C# takes the nice features of F# and implements in a slightly worse way.

[Koshkin]

Well obviously '#' in C# and F# stands for two different things.

[kqr]

If anything, these new things added to C# only make me want to use F# to a greater degree. The reasoning is simple: clearly these things are good (or at least acceptable) ideas since C# adopts them, but C# makes it more complicated to use them.

Put another way: if I'm going to use these features anyway (hint: now that they're in C#, I am) why wouldn't I do it in the language designed around them, rather than the one where they are bolted on?

When C# didn't have these features, there was ironically more reason to use C# because then these idioms could be argued to not be accepted by the community to the same degree.

[jayd16]

But there's clean interop with C#, right? If it helps C#/.NET libraries get made, I think its a positive thing for C# and F#.

[Multicomp]

There is. I have done F#/C# interop before.