[LunicLynx]

My knowledge on functional languages is limited, but as I understand it, it’s possible to formulate expressions that are basically NP problems? And hence impossible to speed up?

So is it a F# issue or inherent to functional programming?

[NanoCoaster]

AFAIK it was a much more down-to-earth thing. The implementation of computation expressions in F# compiled down to lots of function objects that were not very GC-friendly. Or something like that. To be honest, I never looked that deeply at it :)

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.

[throw234234234]

F# has since gotten Functional State machines which make many computation expressions more efficient (https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0...). Been there a while.

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).