I think your initial complaint is just from not understanding F#. I highly reccomend F# for fun and profit.

https://en.wikibooks.org/wiki/F_Sharp_Programming/Sets_and_Maps

C# Interop, these are fair complaints I think. However I think it is often C# which is playing catch-up, not the other way around. I always drag my feet when going back to C# because many features which are extremely convenient in F# are like pulling teeth in C#. I have yet to run across something in C# that I missed in F#, but I tend to use F# for smaller projects.

Completeness is a complaint I have also had.

Readability is going to be a problem going from functional to oop as well. This will always be true no matter what. You can’t get new language features without this issue, let alone an entire paradigm. So while I concede that it’s an issue, it’s a necessary issue. This also may mean that F# isn’t for everyone, much like how Scala isn’t for everyone.

Type Flexibility, I totally and wholly disagree. I’d love to see what you’re doing because it sounds like you’re working against the grain.

(Responding as a Scala user, since the languages have a lot in common)

Just cloning the whole thing would have been painfully slow since the array could grow into the tens of thousands, but I didn’t know how to easily wrap it in a copy on write container such that I could avoid that overhead. I ended up pushing some of my output logic into the processing actor so the message contents were pre-computed without additional overhead.

Was going to suggest lenses for this, then saw them mentioned further down.

there are plenty of times where I need to just swap the order of arguments to make pieces compose easily, which requires a pretty verbose lambda in comparison to the rest of a very terse language.

Not sure if this is what you’re talking about but remember |> and friends.

For example, I’d realized I had re-created lenses to ease some of my unwrapping problems, but if I hadn’t just been browsing around for tools I never would have known such a pattern existed! Sometimes the patterns are esoteric enough that the language maintainers probably expect most users to implement these because they aren’t used often enough in every application domain. There might be more general forms of the patterns that could help, but keeping everything single-purpose and simple had other major benefits. I had a few experiences where I wanted to do something that I thought would be obvious and found that while it’s totally possible, it’s non-trivial to understand and use (computation expressions). Other times I’d realized that building a reusable pattern was more work that it’s worth if the snippet is small and clear enough to see in a few unrelated places. To keep my code simple I probably relied more on copying code than I would have if the components I was copying were bigger. This was just super tough to find a good tradeoff since I wasn’t yet acquainted with the level of abstraction that F# provides.

I think there’s just a larger space of very generic libraries that are possible in functional languages. At first you end up implementing your own specialized versions and that’s ok - it really demonstrates the value of a library if you can use it to replace a large amount of code. As you get more experienced and more comfortable with what’s out there, you become more able to write the library version first.

@jcs: The correct link is http://www.colinbellmore.work/post/fsharp-pain/.