[firlefans]

I personally found F# to be a decent alternative to Elm for small browser apps with Fable, Elmish/Feliz, Feliz.Plotly etc. You can generate typed interfaces for any libs you're missing which have a typescript interface using ts2fable, that's the kind of pragmatic tooling you need if you're veering off the well-trodden path in commercial development. Ionide in VSCode is excellent (though not perfect) and the compilation times are decent. In terms of community (which is not unimportant when it's that small) even the compiler gitter folks were super helpful when I had some reflection questions. Overall I'd use it again for small browser apps, for backend I guess it depends on your company and domain.

[verinus]

while I love F# too I think what hinders adoption is:

- training in FP: for an enterprise on the most crucial points is imho recruiting

- tooling: while the tooling is ok for F# (though not ReSharper grade by far!) it is still lacking

what I often see as refactoring is not that supported in F#/FP languages is the functional equivalent to spaghetti code, where function call after function call is piped without following SOLID principles/ Clean Code style.

[firlefans]

I don't think you can apply the same principles to OO and FP but in terms of refactoring, my experience is that pure functional code is a joy to test and maintain. Small pure functions (again functions can only be pure functions, otherwise you're really talking about procedures), are by their nature easy to test, compose, cache, parallelise and pipeline. If that sounds bad to you, then fair enough.

[truculent]

> what I often see as refactoring is not that supported in F#/FP languages

Could you elaborate on this please? I have found easy, confident refactoring to be one of the biggest benefits of using this family of languages.