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.
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.
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.
It's true that it's easier to write and arguably harder to read code when types are not specified, or at least it's handy for public interfaces between modules. Luckily this is easy to do and often done:
It's the same deal with Haskell, you don't HAVE to specify the types of your code but it can help check your assumptions as to what the compiler is inferring. I've frankly found that a more frequent issue in Haskell because of pervasive use of Monads and other higher-order constructs.
We currently have remote developers from the UK, Germany, and São Paulo. (We do wantjunior hires to be in the office, though, to facilitate mentoring.)
We do a solid amount of pair programming, but remote pairing via ScreenHero is pretty sweet. :)
