> Try teaching someone C# nowadays. Completely impossible. Really, I wish they would've given F# just a tenth of the love that C# got over the years
If they actually put effort in F#, it would have reached "unteachable" state already :)
If they actually put effort in F#, it would have reached "unteachable" state already :)
I would've loved an F# that found a way to improve on the performance issues, especially when using computation expressions. That and, either, a deeper integration of .NETs native OOP subtyping, or some form of OCaml-like module system, would have been enough to make it an almost perfect language for my tastes.
Obviously, these are big, and maybe impossible, issues. But Microsoft as a whole never really dedicated enough resources to find out. I feel for the people still working on it, their work is definitely appreciated :)
So is it a F# issue or inherent to functional programming?
Looking at it, the MS docs contain something about this exact topic, so maybe it's better nowadays: https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
Sadly, I haven't used F# for years at this point so I can't speak to the current state.
I actually think F# has received some "love" over the recent years contrary to some on this forum; that feature being an example. My view, maybe unpopular but in the age of AI maybe less so, is there is a diminishing returns to language features anyway w.r.t complexity and the use cases that new feature will actually apply for. F# in my mind and many other languages now for that matter is pretty much there or are almost there; the languages are converging. When I used F# I liked how it unified features and tried to keep things simple. Features didn't feel "tacked on" mostly with some later exceptions.
Last time I used F# a few libraries started adopting this for their CE's (e.g. IcedTasks library, etc).